Microservices

Monolithic Application

► A monolithic application is a single, self-contained software application that combines

all of its functionality into a single codebase
•Features
Monolithic applications are designed to handle multiple related tasks, such as a web server,
load balancer, catalog service, ordering system, payment function, and shipping
component.
•Codebase
All of the application's components are built on a single codebase, which is modified by
multiple teams within an organization.
•Deployment
Monolithic applications are deployed as a single unit, containing all the functionality that
those teams maintain.
•Maintenance
Monolithic applications can be easier to develop and deploy, but they can become difficult
to maintain and scale as the application's scope and performance demands increase.
•Updates
Any change to a monolith affects the entire application, so the whole system needs to be
redeployed with every update.
Monolithic Applications In A Data
Center
► an a traditional monolithic application run in a data center? Yes. A tenant can launch and use a
VM to run monolithic applications, exactly the way they run on a traditional server. However,
software engineers have pointed out that the monolithic approach has some disadvantages and an
alternate approach may be better for a cloud environment.
► In particular, monolithic applications cannot be replicated as quickly as cloud-native
applications.
► First, starting a VM has higher overhead than starting a container.
► Second, a monolithic design means all code must be downloaded when the ap- plication starts,
even if pieces are not used.
► copies of an application as needed and allowing the copies to expire when they complete. In the
case of online shopping, many users peruse a catalog without logging in, without making a
purchase or arranging shipping, and without filling out the experience questionnaire. For such
customers, the application only invokes the catalog search function; code for other functions
must be downloaded, but is not used.
The Microservices Approach

► The microservices approach to software, sometimes called a microservices

architecture, divides functionality into multiple, independent applications.
Each of the in- dependent applications is much smaller than a monolithic
program, and only handles one function. To perform a task, the independent
applications communicate over a network.
► The microservices approach can be used in two ways: to implement a new
application or to divide an existing monolithic application. We use the term
disaggregation to refer to the division of a monolithic application into
microservices.
Diagram12.2
The Advantages of Microservices

The advantages can be divided into two broad categories: advantages for software
development and ad- vantages for operations and maintenance.
Advantages For Software Development
The microservices approach offers several advantages for software development:
► Smaller scope and better modularity
► Smaller teams
► Less complexity
► Choice of programming language
► More extensive testing
► Smaller scope and better modularity: The microservices approach means
software engineers focus on one small piece of the problem at a time and
define clean interfaces The limited scope encourages better decomposition and
allows engineers to understand each piece completely. As a result, engineers
are less likely to make mistakes or over- look corner cases.
► Smaller teams: As the old saying goes, "too many cooks spoil the broth."
When a large number of software engineers attempt to build a large piece of
software, they must all agree on many details. Because a microservice can be
designed and implemented in- dependent of other microservices, each
microservice only requires a small development team, meaning that the
resulting code will be more uniform and less prone to errors.
► Less complexity: Complexity leads to errors, and the monolithic approach creates
complexity. For example, a monolithic design allows global variables to be shared among
all pieces of code. By contrast, the microservices approach eliminates global variables, and
requires designers to document the exact interfaces among pieces.
► Choice of programming language. When using the monolithic approach, all code must be
written in a single programming language. With the microservices approach, software
engineers can choose the best language for each service.
► More extensive testing. Testing and debugging form a key part of the software
development process. Unfortunately, testing a monolithic program poses a challenge
because the pieces can interact. Thus, many combinations of inputs must be used to
guarantee that interactions among the pieces do not result in errors. For the largest ap-
plications, the number of possible combinations is so large that engineers can only use
randomized testing. With the microservices approach, each service can be tested in-
dependently, allowing more extensive and thorough assessment.
Advantages For Operations And Maintenance

The microservices approach also offers operational advantages:

► Rapid deployment
► Improved fault isolation
► Better control of scaling
► Compatibility with containers and orchestration systems
► Independent upgrade of each service
► Rapid deployment. Because each service is small, the microservices approach means a
given microservice can be created, tested, and deployed rapidly. Thus, the
implementation of a microservice can be changed easily and quickly.
► Improved fault isolation. Dividing an application into multiple microservices makes
fault isolation easier. When a problem occurs, a manager can identify and test the
misbehaving microservice while allowing applications and other microservices to
continue normal operations.
► Better control of scaling. Each microservice can be scaled independently. In our trivial
example, the microservices are only used by one application. In practice, if mul- tiple
applications use a given service, the microservice can be scaled to handle the load
without scaling other services that are not heavily used.
► Compatibility with containers and orchestration systems. A key distinction between
the monolithic approach and the microservices approach arises from the under- lying
platforms needed. Because it is small and only performs one task, a microservice fits
best into the container paradigm. Furthermore, using containers means that mi-
croservices can be monitored, scaled, and load balanced by a conventional container
orchestration system, such as Kubernetes.
► Independent upgrade of each service. Once an improved version of a microservice
has been created, the new version can be introduced without stopping existing applica-
tions and without disturbing other microservices. Moreover, a manager can change a
microservice without needing to recompile and replace entire monolithic applications
that use the service.
The Potential Disadvantages Of
Microservices
Although it offers many advantages, the microservices approach also has potential
disadvantages, including:
► Cascading errors
► Duplication of functionality and overlap
► Management complexity
► Replication of data and transmission overhead
► Increased security attack surface
► Workforce training
► Cascading errors. One of the advantages of a monolithic application lies in the
property of being self-contained. If a function contains an error, the application may
fail, but other applications will continue. In the microservices approach, one microser-
vice can invoke another, which can invoke another, and so on. If one of the microser-
vices fails, the failure may affect many others as well as the applications that use them.
► Duplication of functionality and overlap. Interestingly, the ease with which mi-
croservices can be created invites software engineers to deploy many. For example,
some large enterprises report having hundreds of microservices deployed. When fune-
tionality is needed that differs slightly from an existing microservices, is often easier
create a completely new one than to modify the existing microservice.
► Management complexity. Each microspice Although orchestrado and managed
Manages make management more completing situation and automa Microservieelp,
with hundreds of microservices running simultaneously, it can be diff Cult for a
manager to understand their behaviors, interdependencies, and the interactions among
them.
► Replication of data and transmission overhead. Recall that the monolithic ap proach
allows functions to share global data, Although it can lead to problems, sharing proathe
advantage of efficiency, especially in cases where functions access large sets of has the
ae microservices approach requires each microservice to obtain a copy of the needed
data, either from a storage server or by being passed a copy when the microser vice is
invoked. More important, an application that invokes many microservices may
experience excessive overhead if each of the microservices needs to access the data
► Increase security attack surface. We use the term security attack surface to refer to
the points in a system that can be used to launch an attack. A monolithic application
represents a single attack point. By disaggregating an application into many indepen
dent pieces, the microservices approach creates multiple points that an attacker can try
to exploit.
► Workforce training. When following the monolithic approach, a software engineer
divides the code into modules that make the application easy to create and maintain. In
contrast, the microservices approach requires software engineers to consider the cost of
running each microservice as well as the communication costs incurred in accessing
data or passing it from one microservice to another. A software engineer must also
consider the question of granularity, as the next section explains. Thus, software en-
gineers need new skills to create software for microservices.
Differences between Monolithic and
Microservices

Aspect Monolithic Architecture Microservice Architecture

Architecture Single-tier architecture Multi-tier architecture

Large, all components tightly

Size Small, loosely coupled components
coupled

Individual services can be deployed

Deployment Deployed as a single unit
independently

Horizontal scaling can be

Scalability Easier to scale horizontally
challenging

Complex due to managing multiple

Development Development is simpler initially
services
 Freedom to choose the best
Technology Limited technology choices
technology for each service

Entire application may fail if a part Individual services can fail without
Fault Tolerance
fails affecting others

Easier to maintain due to its Requires more effort to manage

Maintenance
simplicity multiple services

More flexible as components can

Less flexible as all components are
Flexibility be developed, deployed, and scaled
tightly coupled
independently

Communicatio Communication between Communication may be slower due

n components is faster to network calls
Communication service among microservices
Communication protocols used among
Microservices

Synchronous Communication

Synchronous communication happens when a service sends a request and waits for a
response from another service before proceeding. It is a blocking operation.

Common Protocols for Synchronous Communication:

1. HTTP/HTTPS:
○ Widely used in REST APIs.
○ Standardized and interoperable.
○ Suitable for request-response communication.
○ Example: Service A sends an HTTP request to Service B and waits for a
response.
communication protocols used among
Microservices

gRPC:
● A high-performance RPC framework by Google.
● Uses HTTP/2 for transport, supporting multiplexing and low latency.
● Employs Protocol Buffers (Protobuf) for efficient serialization.
● Example: Service A invokes a remote method on Service B using gRPC.

SOAP (Simple Object Access Protocol):

● XML-based protocol for structured message exchange.
● Built on top of HTTP/HTTPS.
● Suitable for enterprise-grade, strict contract-based communication.
Communication protocols used among
Microservices

Asynchronous Communication

Asynchronous communication occurs when a service sends a message and continues

without waiting for a response. The receiving service processes the message at its own
pace. This pattern is non-blocking.

Common Protocols for Asynchronous Communication:

1. AMQP (Advanced Message Queuing Protocol):

○ A standard for message-oriented middleware.
○ Often used with message brokers like RabbitMQ.
○ Reliable message delivery with support for queues, topics, and
acknowledgments.
communication protocols used among
Microservices

Kafka Protocol:
● A distributed messaging system protocol used with Apache Kafka.
● Optimized for high-throughput, fault-tolerant, and durable event streaming.

MQTT (Message Queuing Telemetry Transport):

● Lightweight protocol designed for constrained environments.
● Commonly used in IoT applications and microservices with low-bandwidth needs.

HTTP/2 Streams or WebSockets:

● Can be used asynchronously for events or one-way notifications.
● Example: Service A streams data updates to Service B.
Comparison of Synchronous and
Asynchronous Communication Protocols
When to Use Synchronous vs. Asynchronous Protocols

● Synchronous Communication is suitable for:

○ Real-time interactions where a response is required immediately.
○ Service-to-service API calls with strict request-response logic.
● Asynchronous Communication is suitable for:
○ Scenarios where decoupling and scalability are priorities.
○ Event-driven architectures and background processing.
○ Tasks that do not require an immediate response (e.g., logging, notifications).
Service Mesh in Microservices

These microservices can work together, communicating with each other to make the whole
system function smoothly. If one piece breaks, you can fix or replace it without affecting
the entire structure. This approach makes your system flexible, scalable, and easier to
manage, just like building with Lego bricks instead of one huge block.

a service mesh is a dedicated infrastructure layer that handles communication between

microservices in a software application. It provides a set of tools and capabilities to
manage, secure, and monitor the interactions between different services. Essentially, it acts
as a communication fabric, enabling services to communicate with each other reliably and
efficiently, while also offering features like load balancing, service discovery, encryption,
and observability.
Service Mesh in Microservices explores how to manage communication between
microservices, which are small, independent parts of a software application. Imagine each
microservice as a worker in a factory, they need to talk to each other to get the job done. A
service mesh acts like a supervisor, helping them communicate efficiently and securely. It
handles tasks like load balancing, security, and monitoring, making sure everything runs
smoothly.
 ● A given Microservice won’t directly communicate with the other microservices.

● Rather all service-to-service communications will take places on-top of a software

component called service mesh (or side-car proxy).

● Service Mesh provides built-in support for some network functions such as

resiliency, service discovery etc.

● Service-mesh is language agnostic: Since the microservice to service mesh proxy

communication is always on top to standard protocols such as HTTP1.x/2.x, gRPC

etc., you can write your microservice from any technology and they will still work

with the service mesh.

Business Logic

The service implementation should contain the realization of the business functionalities of

a given service. This includes logic related to it’s business functions, computations,

integration with other services/systems(including legacy, proprietary and SaaS) or service

compositions, complex routing logics, mapping logic between different message types etc.
Primitive Network Functions

Although we offload most of the network functions to service mesh, a given service must

contain the basic high-level network interactions to connect with the service mesh/side-car

proxy. Hence, a given service implementation will have to use a given network

library(unlike the ESB world, where you just have to use a very simple abstraction)to

initiate network calls (to service mesh only). In most cases, microservices development

framework embed the required network libraries to be used for these functions.
Application Network Functions

There are application functionalities which tightly coupled to the network, such as circuit breaking,

timeouts, service discovery etc. Those are explicitly separated from the service code/business logic,

and service mesh facilitate those functionalities out of the box.

Service Mesh Control Plane

All service mesh proxies are centrally managed by a control pane. This is quite useful when

supporting service mesh capabilities such as access control, observability, service discovery etc.
Thank You