Number 4

Microservice Adoption for Existing Systems
A monolith refers to a traditional software application where all the functionality

resides in a single codebase. This model, while simple, can become increasingly
complex and difficult to manage as the application grows.
Microservices, on the other hand, break down the monolithic architecture into
smaller, independent services, each with its own codebase and responsibility. In
this model, different teams can work on different services, allowing for faster
development and deployment cycles.
Migrating an application from a monolithic architecture to a microservices
architecture can be complex and challenging, but the benefits often outweigh the
drawbacks. We’ll review these benefits, common strategies for migrating from
monolith to microservices, and touch on key challenges in the process and possible
solutions.
Although microservices reflect the small, independent team philosophy of DevOps,

most organizations have large mission-critical systems that are not architected
that way. These organizations need to decide whether to migrate their architectures
to microservice architectures, and which ones to migrate. Some of the things an
architect thinking of adopting a microservice architecture should ensure are the
following:
• Operational concerns are considered during requirements specification.
• The overarching structure of the system being developed should be a
collection of small, independent services.
• Each service should be distrustful of both clients and other required
services.
• Team roles have been defined and are understood.
• Services are required to be registered with a local registry/load
balancer.
• Services must renew their registration periodically.
• Services must provide SLAs for their clients.
• Services should aim to be stateless and be treated as transient.
• If a service has to maintain state, it should be maintained in external
persistent storage.
• Services have alternatives in case a service they depend on fails.
• Services have defensive checks to intercept erroneous input from
clients and output from other services.
• Uses of external services, environmental information, and third-party
software and libraries are localized (i.e., they require passage through a module
specific to that external service, environment information, or external software or
library).
However, adopting a microservice architecture will introduce new challenges. When
an application is composed of a large number of network-connected microservices,
there can be latency and other performance issues. Authentication and authorization
between services need to be carefully designed so that they do not add intolerable
overhead. Monitoring, debugging, and distributed tracing tools may need to be
modified to suit microservices. As mentioned earlier, end-to-end testing will be
expensive. Rarely can you rebuild your application from scratch without legacy
components or existing data.
Migrating from your current architecture to a microservice architecture
incrementally without data loss and interruption is a challenge. You may need to
build interim solutions during this migration. An architect should have a checklist
of things to consider when performing a migration.
Challenges of the Transition from Monolith to Micro-services Architecture
Data Management
In a monolithic system, all components typically share the same database. However,
in a microservices architecture, each service ideally has its own database to
ensure decoupling. This makes it necessary to overhaul the data architecture of an
application.
Solution: Implement a carefully planned data migration strategy that may involve
breaking down the monolithic database into smaller, service-specific databases.
Make use of database refactoring techniques and adopt data synchronization methods
where necessary. Consider implementing API endpoints to handle cross-service data
interactions, and look into techniques such as eventual consistency to manage data
across services.
Service Communication
In a monolithic system, components usually communicate through method calls within
the same codebase. When moving to a microservices architecture, you must determine
how services will interact with each other, as they are now separate entities
running in different environments.
Solution: Utilize well-defined APIs for service-to-service communication. Make use

of service orchestration or choreography patterns to manage complex interactions.
Protocols like HTTP/REST or messaging queues can be used for asynchronous
communication. Implement service discovery mechanisms to dynamically locate
services within the system.
Deployment and Monitoring

Deploying and monitoring a microservices-based application involves more complexity
compared to a monolithic one. Each microservice may have its own deployment
pipeline, and monitoring multiple services can be a challenge due to the
distributed nature of the system.
Solution: Use containerization technologies like Docker and orchestration tools
like Kubernetes to standardize deployment and scaling. Implement centralized
logging and monitoring solutions to keep track of the entire system’s health.
Automate as much of the deployment and monitoring processes as possible to reduce
manual error and increase efficiency.
Updating Legacy Systems

Many organizations that seek to transition to microservices are working with older,
legacy systems that might be poorly documented and hard to understand. The
transition could be risky if not managed properly.
Solution: Conduct a thorough codebase and documentation review to understand how
the legacy system functions. Make use of strategies like incremental refactoring
and the strangler pattern to gradually transition to a microservices architecture.
Where documentation is lacking, consider implementing reverse-engineering
techniques or an Anti Corruption Layer to understand legacy system functionality
and prevent unexpected behavior.
5 Strategies for Migrating from Monolith to Microservices
1. Incremental Refactoring
Incremental refactoring involves gradually transforming a monolithic system into a
microservices architecture. This strategy allows you to progressively decompose a
monolith into microservices, reducing the risk of business disruption.
With incremental refactoring, you can start by identifying the parts of the
monolith that are most suitable for becoming independent microservices. These could
be functionalities that are relatively isolated from the rest of the system or
those that would benefit most from the advantages offered by microservices, such as
scalability and speed of deployment.
2. Strangler Pattern
The strangler pattern is a strategy that involves gradually replacing parts of a
monolithic application with microservices while the monolith is still running. This
pattern is inspired by the strangler fig tree, which grows around other trees and
gradually replaces them.
The strangler pattern allows you to gradually introduce microservices into your
system without disrupting the functioning of the monolith. This approach helps
reduce risk and allows for a smoother transition process.
3. Decomposing by Business Capability

This strategy involves breaking down a monolith into microservices based on
business functionalities. This strategy aligns the technical components of your
system with your business objectives, making it easier to manage and evolve your
system in response to business needs.
When decomposing by business capability, it is important to ensure that each
microservice is responsible for a single business capability. This helps maintain
the independence of microservices and reduces the complexity of the system.
4. Anticorruption Layer (ACL)

The anticorruption layer (ACL) is a strategy used to ensure that the transition
from monolith to microservices does not corrupt the business logic of your system.
The ACL acts as a barrier between the monolith and the microservices, converting
data and requests between the two systems.
Using an ACL can help ensure that the transition process does not affect the
integrity of your system’s business logic. This is particularly important when
dealing with legacy systems, which often lack the necessary documentation to fully
understand their business logic.
5. Domain-Driven Design (DDD)

Domain-driven design (DDD) is a software development approach that focuses on
understanding the business domain and using this understanding to guide the design
and development of software. In the context of transitioning from monolith to
microservices, DDD can be used to identify the boundaries of microservices and to
ensure that the transition process aligns with business goals.
DDD involves creating a model of the business domain and using this model to design
the microservices. This approach helps ensure that each microservice corresponds to
a specific part of the business domain, which can help ensure that the
microservices architecture fully supports your business objectives.

Number 4

Uploaded by

Copyright:

Available Formats

Number 4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Number 4

Uploaded by

Copyright:

Available Formats

Microservice Adoption for Existing Systems

A monolith refers to a traditional software application where all the functionality

Although microservices reflect the small, independent team philosophy of DevOps,

Challenges of the Transition from Monolith to Micro-services Architecture

Solution: Utilize well-defined APIs for service-to-service communication. Make use

Deployment and Monitoring

Updating Legacy Systems

5 Strategies for Migrating from Monolith to Microservices

3. Decomposing by Business Capability

4. Anticorruption Layer (ACL)

5. Domain-Driven Design (DDD)

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.