What are Microservices?

Microservices are an architectural approach to develop software applications as a collection

of small, independent services that communicate with each other over a network.
Instead of building a monolithic application where all the functionality is tightly integrated
into a single codebase, microservices break down the application into smaller, loosely
coupled services.

Microservices is a service-oriented architecture pattern wherein applications are built as a

collection of various smallest independent service units. It is a software engineering approach
that focuses on decomposing an application into single-function modules with well-defined
interfaces. These modules can be independently deployed and operated by small teams that
own the entire lifecycle of the service.

Microservice is a small, loosely coupled distributed service. Each microservice is designed to

perform a specific business function and can be developed, deployed, and scaled
independently.
It allows you to take a large application and decompose or break it into easily manageable
small components with narrowly defined responsibilities.
It is considered the building block of modern applications. Microservices can be written in a
variety of programming languages, and frameworks, and each service acts as a mini-
application on its own.

How do Microservices work?

Microservices work by breaking down a complex application into smaller, independent
pieces that communicate and work together, providing flexibility, scalability, and easier
maintenance, much like constructing a city from modular, interconnected components.

Let’s understand how microservices work:

 Modular Structure:
o Microservices architecture breaks down large, monolithic
applications into smaller, independent services.
o Each service is a self-contained module with a specific
business capability or function.
 o This modular structure promotes flexibility, ease of
development, and simplified maintenance.
 Independent Functions:
o Each microservice is designed to handle a specific business
function or feature.
o For example, one service may manage user authentication,
while another handles product catalog functions.
o This independence allows for specialized development and
maintenance of each service.
 Communication:
o Microservices communicate with each other through well-
defined Application Programming Interfaces (APIs).
o APIs serve as the interfaces through which services exchange
information and requests.
o This standardized communication enables interoperability and
flexibility in integrating services.
 Flexibility:
o Microservices architecture supports the use of diverse
technologies for each service.
o This means that different programming languages,
frameworks, and databases can be chosen based on the specific
requirements of each microservice.
o Teams have the flexibility to use the best tools for their
respective functions.
 Independence and Updates:
o Microservices operate independently, allowing for updates or
modifications to one service without affecting the entire
system.
o This decoupling of services reduces the risk of system-wide
disruptions during updates, making it easier to implement
changes and improvements.
 o Also Microservices contribute to system resilience by ensuring
that if one service encounters issues or failures, it does not
bring down the entire system.
 Scalability:
o Microservices offer scalability by allowing the addition of
instances of specific services.
o If a particular function requires more resources, additional
instances of that microservice can be deployed to handle
increased demand.
o This scalability is crucial for adapting to varying workloads.
 Continuous Improvement:
o The modular nature of microservices facilitates continuous
improvement.
o Development teams can independently work on and release
updates for their respective services.
o This agility enables the system to evolve rapidly and respond
to changing requirements or user needs.

What are the main components of Microservices Architecture?

Microservices architecture comprises several components that work together to create a
modular, scalable, and independently deployable system.
The main components of microservices include:
 Microservices: These are the individual, self-contained services that encapsulate
specific business capabilities. Each microservice focuses on a distinct function or
feature.
 API Gateway: The API (Application Programming Interface) Gateway is a
central entry point for external clients to interact with the microservices. It
manages requests, handles authentication, and routes requests to the appropriate
microservices.
 Service Registry and Discovery: This component keeps track of the locations
and network addresses of all microservices in the system. Service discovery
ensures that services can locate and communicate with each other dynamically.
 Load Balancer: Load balancers distribute incoming network traffic across
multiple instances of microservices. This ensures that the workload is evenly
distributed, optimizing resource utilization and preventing any single service from
becoming a bottleneck.
 Containerization: Containers, such as Docker, encapsulate microservices and
their dependencies. Tools, like Kubernetes, manage the deployment, scaling, and
operation of containers, ensuring efficient resource utilization.
 Event Bus/Message Broker: An event bus or message broker facilitates
communication and coordination between microservices. It allows services to
publish and subscribe to events, enabling asynchronous communication and
decoupling.
 Centralized Logging and Monitoring: Centralized logging and monitoring tools
help track the performance and health of microservices. They provide insights into
system behaviour, detect issues, and aid in troubleshooting.
 Database per Microservice: Each microservice typically has its own database,
ensuring data autonomy. This allows services to independently manage and scale
their data storage according to their specific requirements.
 Caching: Caching mechanisms can be implemented to improve performance by
storing frequently accessed data closer to the microservices. This reduces the need
to repeatedly fetch the same data from databases.
 Fault Tolerance and Resilience Components: Implementing components for
fault tolerance, such as circuit breakers and retry mechanisms, ensures that the
system can gracefully handle failures in microservices and recover without
impacting overall functionality.
What is a monolithic architecture?

A monolithic architecture is a traditional model of a software program, which is built as a

unified unit that is self-contained and independent from other applications. The word
“monolith” is often attributed to something large and glacial. A monolithic architecture is a
singular, large computing network with one code base that couples all of the business
concerns together. To make a change to this sort of application requires updating the entire
stack by accessing the code base and building and deploying an updated version of the
service-side interface. This makes updates restrictive and time-consuming.

Monoliths can be convenient early on in a project's life for ease of code management,
cognitive overhead, and deployment. This allows everything in the monolith to be released at
once.

Advantages of a monolithic architecture

Organizations can benefit from either a monolithic or microservices architecture, depending

on a number of different factors. When developing using a monolithic architecture, the
primary advantage is fast development speed due to the simplicity of having an application
based on one code base. The advantages of a monolithic architecture include:
Easy deployment – One executable file or directory makes deployment easier.
Development – When an application is built with one code base, it is easier to develop.
Performance – In a centralized code base and repository, one API can often perform the
same function that numerous APIs perform with microservices.
Simplified testing – Since a monolithic application is a single, centralized unit, end-to-end
testing can be performed faster than with a distributed application.
Easy debugging – With all code located in one place, it’s easier to follow a request and find
an issue.

Disadvantages of a monolithic architecture

Making a small change in a single function requires compiling and testing the entire platform,
which goes against the agile approach today’s developers favor. The disadvantages of a
monolith include:
Slower development speed – A large, monolithic application makes development more
complex and slower.
Scalability – You can’t scale individual components.
Reliability – If there’s an error in any module, it could affect the entire application’s
availability.
Barrier to technology adoption – Any changes in the framework or language affects the
entire application, making changes often expensive and time-consuming.
Lack of flexibility – A monolith is constrained by the technologies already used in the
monolith.
Deployment – A small change to a monolithic application requires the redeployment of the
entire monolith.

What are microservices?

A microservices architecture, also simply known as microservices, is an architectural method
that relies on a series of independently deployable services. These services have their own
business logic and database with a specific goal. Updating, testing, deployment, and scaling
occur within each service. Microservices decouple major business, domain-specific concerns
into separate, independent code bases. Microservices don’t reduce complexity, but they make
any complexity visible and more manageable by separating tasks into smaller processes that
function independently of each other and contribute to the overall whole.
Advantages of microservices
Microservices are by no means a silver bullet, but they solve a number of problems for
growing software and companies. Since a microservices architecture consists of units that run
independently, each service can be developed, updated, deployed, and scaled without
affecting the other services. Software updates can be performed more frequently, with
improved reliability, uptime, and performance. In short, the advantages of microservices are:
Agility – Promote agile ways of working with small teams that deploy frequently.
Flexible scaling – If a microservice reaches its load capacity, new instances of that service
can rapidly be deployed to the accompanying cluster to help relieve pressure. We are now
multi-tenanant and stateless with customers spread across multiple instances. Now we can
support much larger instance sizes.
Continuous deployment – We now have frequent and faster release cycles. Before we would
push out updates once a week and now we can do so about two to three times a day.
Highly maintainable and testable – Teams can experiment with new features and roll back
if something doesn’t work. This makes it easier to update code and accelerates time-to-
market for new features. Plus, it is easy to isolate and fix faults and bugs in individual
services.
Independently deployable – Since microservices are individual units they allow for fast and
easy independent deployment of individual features.
Technology flexibility – Microservice architectures allow teams the freedom to select the
tools they desire.
High reliability – You can deploy changes for a specific service, without the threat of
bringing down the entire application.
Happier teams – The teams who work with microservices are a lot happier, since they are
more autonomous and can build and deploy themselves without waiting weeks for a pull
request to be approved.

Disadvantages of microservices
When we moved from a small number of monolithic codebases to many more distributed
systems and services powering our products, unintended complexity arose. We initially
struggled to add new capabilities with the same velocity and confidence as we had done in
the past. Microservices can add increased complexity that leads to development sprawl, or
rapid and unmanaged growth. It can be challenging to determine how different components
relate to each other, who owns a particular software component, or how to avoid interfering
with dependent components.
With Vertigo, we built a common functionality that would power our existing products and
future products we acquire and build. If you are a single product company, microservices
may not be [Link] disadvantages of microservices can include:
Development sprawl – Microservices add more complexity compared to a monolith
architecture, since there are more services in more places created by multiple teams. If
development sprawl(extention) isn’t properly managed, it results in slower development
speed and poor operational performance.
Exponential infrastructure costs – Each new microservice can have its own cost for test
suite, deployment playbooks, hosting infrastructure, monitoring tools, and more.
Added organizational overhead – Teams need to add another level of communication and
collaboration to coordinate updates and interfaces.
Debugging challenges – Each microservice has its own set of logs, which makes debugging
more complicated. Plus, a single business process can run across multiple machines, further
complicating debugging.
Lack of standardization – Without a common platform, there can be a proliferation of
languages, logging standards, and monitoring.
Lack of clear ownership – As more services are introduced, so are the number of teams
running those services. Over time it becomes difficult to know the available services a team
can leverage and who to contact for support.

Microservices vs. Monolithic Architecture

Aspect Microservice Architecture Monolithic Architecture

Architecture Multi-tier architecture Single-tier architecture

Large, all components tightly

Small, loosely coupled components
Size coupled

Individual services can be deployed

Deployed as a single unit
Deployment independently

Horizontal scaling can be

Easier to scale horizontally
Scalability challenging

Complex due to managing multiple

Development is simpler initially
Development services

Freedom to choose the best

Limited technology choices
Technology technology for each service

Individual services can fail without Entire application may fail if a

Fault Tolerance affecting others part fails

Requires more effort to manage Easier to maintain due to its

Maintenance multiple services simplicity

Flexibility More flexible as components can Less flexible as all components

be developed, deployed, and scaled are tightly coupled
Aspect Microservice Architecture Monolithic Architecture

independently

Communication may be slower due Communication between

Communication to network calls components is faster

What Is Service-Oriented Architecture (SOA)?

Service-oriented architecture (SOA) is a centralized architecture in which each component is
connected with each other to perform a service.
Service-oriented architecture (SOA) is an architectural style designed to build a distributed
system. It involves designing software applications that include multiple services that
communicate with each other using standardized interfaces.

Service-Oriented Architecture Definition

Service-oriented architecture (SOA) is a centralized architecture in which multiple services

communicate with each other to deliver a service using standardized interfaces. It’s
considered a coarse-grained architecture and is most useful for building large, complex
systems that require integration between services.
SOA stands in contrast to microservices, which is a different approach to designing a
software system. SOA’s centralized approach can be beneficial for large, complex systems
that require tight integration between services, while microservices’ scalability and flexibility
allows for rapid development and deployment of individual components.
Both architectures have their strengths and are suitable for different contexts, depending on
the project’s specific requirements and goals.

What Is Service-Oriented Architecture?

SOA is an enhanced version of monolithic architecture, and it solves various challenges that
come under software system design.

Monolithic architecture is a single-unit architecture and is like a container that hosts a number
of software components. Each of those components are tightly integrated into a single
system.

The issue with monolithic architecture is that the system components are all contained inside
a single container. SOA attempts to solve this issue with a container that is broken down in
smaller chunks. It involves designing a software application as a collection of small,
independent and reusable services. Each component performs a specific function and can be
deployed, developed and maintained independently.
Suppose we have one software application that has four features. All four features are
developed as different components, but they’re all connected with each other. Each
component is then responsible for a small task. and these small tasks together deliver a
particular feature.

Advantages of Service Oriented Architecture

SOA is useful when you have:

 Large complex enterprise systems that require integration of multiple legacy

applications and databases.
 Large distributed systems in which different components are located on different
locations.
 Systems that experience spikes in demand.
 Require flexibility, reusability, scalability and interoperability in your architecture.

Components of Service-Oriented Architecture

Service oriented architecture contains three building blocks: service provider, service
repository and service requester.

1. Service Provider
The service provider focuses on the services that are being offered, such as security,
availability, what to charge and more. This role also determines the service category and if
there need to be any trading agreements. It defines a well-defined interface that allows
consumers to interact with the service without needing to know the underlying
implementation details. It abstracts the complexity and presents a standardized interface.

2. Service Repository
The service repository facilitates the discovery and identification of services, making it easier
for service requesters to find and access the appropriate services they require. It serves as a
central catalog or registry that maintains and manages information about all available services
within the SOA ecosystem.

3. Service Requester
The service requester locates entries in the broker registry and then binds them to the service
provider. This enables seamless communication and data exchange between different services
within the SOA environment. The service requester can access services from various
providers, promoting a more modular and distributed approach to software development.

Difference between Service-oriented architecture and Microservice architecture

Service-Oriented Architecture (SOA)

 Definition: SOA is a design paradigm and architectural pattern that allows different
services to communicate over a network, enabling interoperability among diverse
applications.
 Granularity: Coarse-grained services, often encompassing larger business functions.
 Communication: Typically relies on an Enterprise Service Bus (ESB) for
communication, using protocols like SOAP and XML.
  Deployment: Centralized; services are often deployed on a single platform or server.
 Data Management: Commonly utilizes a shared database among services, which can
create tight coupling.
 Scalability: Primarily vertical scaling (adding resources to a single machine).
 Technology Stack: Usually more homogeneous; services tend to use similar
technologies.
 Governance: Strong governance model; often involves strict control over service
interactions.
 Development Speed: Slower due to complexity and interdependencies between
services.
 Testing: More complex, as multiple services are often interdependent.
 Use Case: Well-suited for enterprise-level applications where service reuse and
integration are crucial.

Microservices Architecture

 Definition: Microservices is an architectural style that structures an application as a

collection of small, independent services, each responsible for a specific business
capability.
 Granularity: Fine-grained services, focusing on single, specific tasks.
 Communication: Uses lightweight protocols (e.g., HTTP/REST, gRPC) for
communication, avoiding the need for an ESB.
 Deployment: Decentralized; services can be deployed independently, often in
containers (e.g., Docker).
 Data Management: Each service typically has its own database, promoting loose
coupling.
 Scalability: Horizontal scaling (adding more instances of services) is common.
 Technology Stack: Heterogeneous; services can use different languages and
frameworks based on specific needs.
 Governance: Loose governance, allowing teams to operate independently and make
technology choices.
 Development Speed: Faster development cycles; teams can work on services
concurrently.
 Testing: Easier, as services can be tested in isolation.
 Use Case: Ideal for agile, cloud-native applications that require rapid deployment and
frequent updates
Cloud-native microservices

Cloud-native microservices are an architectural approach that focuses on developing

applications as a collection of loosely coupled services, each of which can be developed,
deployed, and scaled independently. This approach aligns well with modern development
practices and is particularly effective in DevOps environments. Here’s a breakdown of the
role of microservices in DevOps:

1. Independent Deployment
Microservices can be deployed independently, allowing teams to release new features or fixes
without waiting for the entire application to be ready. This accelerates the delivery pipeline
and fosters a culture of continuous integration and continuous deployment (CI/CD).

2. Scalability
Each microservice can be scaled independently based on demand. This allows organizations
to optimize resource utilization and respond to varying loads more effectively than
monolithic architectures.

3. Improved Fault Isolation

In a microservices architecture, if one service fails, it doesn’t necessarily bring down the
entire application. This isolation enhances overall system resilience and enables faster
recovery.

4. Diverse Technology Stacks

Microservices allow teams to use different programming languages and technologies suited
to specific service requirements. This flexibility can lead to better performance and more
efficient development.

5. Enhanced Collaboration
Microservices encourage cross-functional teams to work on different services simultaneously.
This aligns well with DevOps principles, promoting collaboration between development and
operations teams.

6. Faster Feedback Loops

With smaller, independently deployable units, teams can receive feedback more quickly from
users. This facilitates rapid iterations and adjustments, aligning with Agile and DevOps
methodologies.

7. Automation and Tooling

DevOps practices heavily rely on automation. Microservices can be integrated with various
continuous integration and continuous deployment (CI/CD) tools and container orchestration
platforms (like Kubernetes), streamlining the deployment and management processes.

8. Monitoring and Observability

Microservices architecture encourages the use of centralized logging and monitoring
solutions. This helps teams track the performance of individual services, enabling quicker
identification and resolution of issues.
9. Security
Microservices can implement security measures at the service level, allowing teams to tailor
security practices to specific services. This fine-grained control enhances overall application
security.