Microservice

Architecture Pattern
COMP 301 .Software Architectures and Tools
Week 9
Microservice Pattern
Description
• The microservices architecture pattern is quickly gaining ground
in the industry as a viable alternative to monolithic applications
and service-oriented architectures.
• Because this architecture pattern is still evolving, there’s a lot of
confusion in the industry about what this pattern is all about and
how it is implemented.
• Regardless of the topology or implementation style you
chose(disccussed later on) , there are several common core
concepts that apply to the general architecture pattern.
Separately Deployed Units
• Each component of the microservices architecture is
deployed as a separate unit, allowing for easier deployment
through an effective and streamlined delivery pipeline, increased
scalability, and a high degree of application and component
decoupling within your application.
Notion of a Service Component
• Service components contain:
1. one or more modules (e.g., Java classes)
that represent either a single-purpose
function (e.g., providing the weather for a
specific city or town) or
2. an independent portion of a large business
application(e.g., stock trade placement or
determining auto-insurance rates).

• Designing the right level of service

component granularity is one of the biggest
challenges within a microservices architecture.
• This challenge is discussed in more detail later on.
Distrubuted Architecture
• all the components within the architecture are fully decoupled
from one other and accessed through some sort of remote access
protocol (e.g., JMS, AMQP, REST, SOAP, RMI, etc.)
• The distributed nature of this architecture pattern is how it
achieves some of its superior scalability and deployment
characteristics.
Microservice Pattern
• One of the exciting things about the microservices architecture is
that it evolved from issues associated with other common
architecture patterns, rather than being created as a solution
waiting for a problem to occur.

• The microservices architecture style naturally evolved from two

main sources:
1. monolithic applications developed using the layered
architecture pattern
2. distributed applications developed through the service-
oriented architecture pattern.
Monolithic applications to a
Microservices
Architecture Style
• Microservices architecture style was prompted primarily through
the development of continuous delivery, the notion of a
Continuous deployment pipeline from development to
production which streamlines the deployment of applications.
• Monolithic applications typically consist of tightly coupled
components that are part of a single deployable unit, making it
cumbersome and difficult to change,
• test, and deploy the application.
• Hence the rise of the common “monthly deployment” cycles
typically found in most large IT shops.
• These factors commonly lead to brittle applications thatbreak
every time something new is deployed.
Monolithic applications to a
Microservices
Architecture Style
• The microservices architecture
pattern addresses these issues by
separating the application into
multiple deployable units:
• service components that can be
individually developed, tested,
and deployed independent of
other service components.
SOA to Microservices
• The other evolutionary path that lead to the microservices
architecture pattern is from issues found with applications
implementing the service-oriented architecture pattern (SOA).
• Remember the SOA pattern is very powerful and offers unparalleled
levels of abstraction, heterogeneous connectivity, service
orchestration, and the promise of aligning business goals with IT
capabilities
• On the other hand, it is nevertheless complex, expensive, ubiquitous,
difficult to understand and implement,and is usually overkill for most
applications
SOA to Microservices
• The microservices architecture style
addresses this complexity by simplifying
the notion of a service
• eliminating orchestration needs, and
simplifying connectivity and access to
service components.
Visually Compare 3
Architectural Patterns
Another Visual Comparison
Pattern Topologies
• While there are literally dozens of ways to implement a microservices
architecture pattern, three main topologies stand out as the most
common and popular:
• API REST-based topology
• Application REST-based topology
• the centralized messaging topology
API REST-based topology
• The API REST-based topology is useful for
websites that expose small, self-contained
individual services through some sort of
API(application programming interfaces)
• This topology consists of very fine-grained
service components (hence the name
microservices) that contain one or two
modules that perform specific business
functions independent from the rest of the
services.
• Examples of this topology include some of the
common single purpose cloud-based RESTful
web services found by Yahoo, Google, and
Amazon.
The application REST-based
topology
• The application REST-based topology differs from the API REST based approach in that
client requests are received through traditional web-based or fat-client business
application screens rather than through a simple API layer.

• The user-interface layer of the application is deployed as

a separate web application that remotely accesses separately
deployed service components(business functionality) through
simple REST-based interfaces.
• This topology is common for small to medium-sized
business applications that have a relatively low degree
of complexity.
Centralized Messaging Topology
• This topology is similar to the previous
application REST based topology except
that instead of using REST for remote
access,this topology uses a lightweight
centralized message broker(RabbitMQ,
ActiveMQ etc… ).
• The lightweight message broker found in this
topology does not perform any orchestration,
transformation, or complex routing; rather, it is
just a lightweight transport to access remote
service components.
• The centralized messaging topology is typically
found in larger business applications or
applications requiring more sophisticated control
over the transport layer between the user
interface and the service components.
Centralized Messaging Topology
• The benefits of this topology over the simple REST-based
topology are:
1. advanced queuing mechanisms,
2. asynchronous messaging,
3. monitoring, error handling,
4. and better overall load balancing and scalability
• The single point of failure and architectural bottleneck
issues usually associated with a centralized broker are addressed
through broker clustering and broker federation (splitting a
single broker instance into multiple broker instances to divide the
message throughput load based on functional areas of the
system).
Avoid Dependencies and
Orchestration
• One of the main challenges of the microservices architecture pattern is determining the
correct level of granularity for the service components.
• If service components are too coarse-grained you may not realize the benefits that
come with this architecture pattern(deployment, scalability(let us learn it) , testability,
and loose coupling.
• However, service components that are too fine-grained will lead to service
orchestration
• Requirements, which will quickly turn your lean microservices architecture into a
heavyweight service-oriented architecture, complete with all the complexity, confusion,
expense, and fluff typically found with SOA-based applications.
Scalability????
• In the context of software development, scalability is an
application’s ability to handle workload variation while
adding or removing users with minimal costs.
• Examples of increased workload are:
• Many users accessing the system simultaneously
• Expansion in storage capacity requirements
• Increased number of transactions being processed
Types of Scalability
• You can scale an application either horizontally or
vertically.
Horizontal software scalability
• You can scale software horizontally by
incorporating additional nodes into the
system to handle a higher load, as it will be
distributed across the machines.
• For instance, if an application starts
experiencing delays, you can scale out by
adding another server.
• Horizontal scalability is a better choice when
you can’t estimate how much load your
application will need to handle in the future.
• It’s also a go-to option for software that
needs to scale fast with no downtime.
Horizontal Scalability: Benefits
vs. Limitations
• Benefits:
• Resilience to failure. If one node fails, others will pick up the slack
• There is no downtime period during scaling as there is no need to
deactivate existing nodes while adding new ones
• Theoretically, the possibilities to scale horizontally are unlimited
• Limitations:
• Added complexity. You need to determine how the workload is
distributed among the nodes. You can use Kubernetes for load
management
• Higher costs. Adding new nodes costs more than upgrading existing
ones
• The overall software speed might be restricted by the speed of node
communication
Vertical software scalability

• Vertical scalability is about

adding more power to the
existing hardware.
• If with horizontal scalability you
would add another server to
handle an application’s load,
here you will update the existing
server by adding more
processing power, memory, etc.
• This scalability type works well
when you know the amount of
extra load that you need to
incorporate.
Vertical Scalability: Benefits vs.
Limitations
• Benefits:
• There is no need to change the configuration or an
application’s logic to adapt to the updated infrastructure
• Lower expenses, as it costs less to upgrade than to add
another machine
• Limitations:
• There is downtime during the upgrading process
• The upgraded machine still presents a single point of failure
• There is a limit on how much you can upgrade one device
Microservice Communication Patterns
Microservice Communication
Patterns
• A microservice architecture is all about communication.
• How should services communicate in any given business scenario?
• Should they call each other synchronously?
• Or should they communicate via asynchronous messaging?

this is not a black-or-white decision

1. Synchronous Calls
• The probably easiest communication pattern to implement is simply calling
another service synchronously, usually via REST.
• Service 1 calls Service 2 and waits until Service 2 is done processing the
request and returns a response.
• Service 1 can then process Service 2’s response in the same transaction
that triggered the communication.
• This pattern is easy to grasp since we are doing it all the time in any web
application out there.
Timeouts

• What if Service 2 needs very long to process the Service 1’s

request and Service 1 is tired of waiting?

• Service 1 will then probably have some sort of timeout

exception and roll back the current transaction.
• However, Service 2 doesn’t know that Service 1 rolled back the
transaction and might process the request after all,
• Perhaps resulting in inconsistent data between the two
services.
Strong Coupling
• Naturally, synchronous communication creates a strong
coupling between the services.
• Service 1 cannot work without Service 2 being available.
• To mitigate this, we have to work around communication failures
by implementing retry and / or fallback mechanisms.

Easy to Implement
• it’s synchronous communication! We’ve all done it
before. And thus we can do it again easily. Let’s just get
the latest version of our favorite HTTP client library and
implement it.
2. Simple Messaging
• Asynchronous messaging is the next option we take a look at.

• Service 1 fires a message to a message broker and forgets about

it.
• Service 2 subscribes to a topic is fed with all messages
belonging to that topic.
• The services don’t need to know each other at all, they just need
to know that there are messages of a certain type with a certain
payload.
• Let’s discuss messaging.
Automatic Retry

• Depending on the message broker, we get a retry

mechanism for free.
• If Service 2 is currently not available, the message
broker will try to deliver the message again until Service
2 finally gets it. “Guaranteed Delivery” is the magic
keyword.
Loose Coupling
• Along the same lines, messaging makes the services
loosely coupled since Service 2 doesn’t need to be
available at the time Service 1 sends the message.
Message Broker must not fail
• Using a message broker, we just introduced a piece of central
infrastructure that is needed by all services that want to
communicate asynchronously. If it fails, hell will break loose (and
all services cease functioning).

Pipeline contains
Schema
• It’s worthy to note that messages (even if they are JSON) define a
certain schema within the message broker.

• If the format of a message changes (and the change is not backwards

compatible), then all messages of that type must have been processed
by all subscribers before the new service versions can be deployed.

• This contradicts independent deployments, one of the main goals of

microservices. This can be mitigated by only allowing backward
compatible changes to message formats (which may not always be
Two-Phase Commit

• Another caveat is that we usually send messages as

part of our business logic and the business logic is
usually bound to a database transaction.
• If the database transaction rolls back, a message may
have already been sent to the message broker.
• This can be addressed by implementing two-phase
commit between the database transaction and the
message broker.
• However, two-phase commit may not be supported by
the database or the message broker and even if it is, it’s
often a pain to get working and even more so to test
reliably.
3. Transactional Messaging

• Instead of sending a message directly to the message

broker, we now store it in the service’s database first.
• Same on the receiving side: here the message gets
stored into the receiver service’s database before it is
being processed.
No Need for Two-Phase Commit

• Since we’re writing the message to a local database

table we can use the same transaction that our business
logic uses.
• If the business logic fails, the transaction is rolled back
and so is our message. We cannot accidentally send
messages any more when our local transaction has
been rolled back.
Message Broker may Fail

• Since we’re storing our messages in the local database

on the sending and the receiving side, the message
broker may fail anytime and the system will magically
heal itself once it’s back online.
• We can just send the messages again from our message
database table.
Complex Setup

• The setup is quite complex, since we need to store the messages

in the database of the sending and reviving services.

• Also, we need to implement jobs on both sides that poll the

database, looking for unprocessed messages and then process
them by

• sending them to the message broker (on the sending side) or

• calling the business logic that processes the message (on the receiving
side)
4. Zero-Payload Events

• The last scenario is similar to the messaging example, but we’re not
sending whole messages (i.e. big JSON objects) but instead only a
pointer to the payload.
• In this case, the message is more like an event. It signals that something
happened, for example that “the order with ID 4711 has been shipped”.
• Thus, the message itself only contains the type of the event
(“orderShipped”) and the ID of the order (4711).
• If Service 2 is interested in the “orderShipped” event, it can then
synchronously call Service 1 and ask for the order data.
When to use which Approach?
• There is no black-and-white decision between the communication
patterns described above.
• However, let’s try to find some indications on when we might use
which approach.
• We might want to use Synchronous Calls if:
• we want to query some data, because a query is not changing any state so we
don’t have to worry about distributed transactions and data consistency
across service boundaries
• the call is allowed to fail and we don’t need a sophisticated retry mechanism
When to use which Approach?
• We might want to use Simple Messaging if:
• we want to send state-changing commands
• the operation must be performed eventually, even if it fails
the first couple times
• we don’t care about potentially complex message structure
When to use which Approach?
• We might want to use Transactional Messaging if:
• we want to send state-changing commands only when the
local database transaction has been successful
• two-phase commit is not an option
• we don’t trust the message broker (actually, better look for
one you trust)
When to use which Approach?
• We might want to use Zero Payload Events if:
• we want to send state-changing commands
• we would otherwise have a very complex message structure
that is hard to maintain in a backwards-compatible way
Suggested Reading
• https://www.oreilly.com/library/view/building-microservices-2nd/978
1492034018/ch04.html