NexTurn

NexTurn

Menu

PoV For Monolith To Microservices Migration

The traditional monolithic application is a single unit that contains all the functional components, including database operations, business logic, background processing, etc. They are all deployed together at the same time and running on the same servers. As the applications grow with new functionality, modules and code added to the same codebase, the entire ecosystem gets bloated which slows down the pace of evolution. We encounter issues as mentioned below:

  1. Increased turn-around time of addition of new functionality.
  2. Increased time for deployment.
  3. Scalability issues. Reduction in team’s productivity.
  4. Heavy release train as the entire application needs to be deployed even for a single change.

Microservice architecture style addresses these issues. Microservice architecture structures an application as a set of loosely coupled services. Every service is a separate application with its own framework, programming language, and database. They are all developed and deployed separately from other services. Companies that are expanding can grow their applications as their workload and requirements increase. Principle of Modernization


Modernization Patterns

1. STRANGLER PATTERN
Incrementally migrate functionality to the new system and rollback easily if required, move functionality over to new services architecture without changing existing systems. This approach will have minimal impact on the existing system during Modernization

2. ANTI-CORRUPTION LAYER
Isolate different subsystems by placing an anti-corruption layer between them. This layer translates communications between the two systems, allowing one system to remain unchanged while the other can avoid compromising its design and technological approach.

3. BRANCH BY ABSTRACTION
Make improvements to the current codebase, allowing applications to coexist alongside each other without creating too much disruption in the same code version.

4. PARALLEL RUN
Both the implementations are called out, allowing us to compare the results to check their equivalency. This method could be used to verify the new implementation along with its operations within acceptable nonfunctional parameters.

5. DECORATING COLLABORATOR
Even though we have not changed the underlying Monolith, the Decorator shall make it appear that our Monolith is making calls to the services. Rather than changing the Monolith, we keep the Monolith functionality and build some form of a wrapper/facade to change the returning data to the requester

Modernization Considerations

Re-writing monolithic applications to microservices needs very careful planning and execution. Rather going with a Big Bang approach, you must follow a piece meal approach.

You must use Strangler pattern as an over-arching strategy for Modernization. Cross-cutting modules are an ideal choice for initial Modernization, which could be achieved with minimal changes across connecting modules by following ‘Anti-Corruption Layer’.

Follow ‘Domain Driven Design’ to split microservices from monolith. This needs extensive discussion with the business experts and product owners to understand the atomicity of the functionality.

Follow any one of these patterns (‘SAGA’, ’CQRS’, ‘Schema based’ or ‘Database based’) on a scenario and case by case basis to perform Database segregation.

Parallel Run pattern helps us in reducing the turn-around time of Modernization by allowing the service to be executed real time and by comparing the results with the monolith module and deciding accordingly. Reverse Proxy helps in routing the requests between Monolith and Microservices, which can be updated real time.

DevSecOps processes with CI/CD implementation should be followed with test automation, security, and quality consideration at every step. Infrastructure needs to be setup for active monitoring of these services with autoscaling, fault-tolerance and auto-healing capabilities.

Use Case Example

Presenting a use case about Modernization of pricing engine for one of the clients in airline domain. The pricing engine has sub-domains like fares, rules, ticketing, routing, journey, subscription, and taxes. The application follows a monolithic architecture and is hosted in-house. In order to improvise the application on factors of reducing turn-around time of feature implementation, increase developer productivity and reduce deployment time, it has been decided to migrate the application to microservices architecture along with DevOps.

The Modernization was planned in multiple phases implementing Strangler pattern. Services are segregated following Single Service Data pattern to scale the domain specific data along with the services, and the data was migrated from DB2 to Redis & Neo4J instances following a segregated database pattern. API Gateway has been implemented to redirect the incoming requests to the microservices which were migrated to the public cloud.

Log Aggregation and trace log of requests/queries is collected through Splunk which is used for observability.

Conclusion

Modernization of application from Monolithic architecture to Microservice architecture requires careful analysis and various considerations as it needs to be done with a piece meal approach to ensure continuity of serviceability. In order to ensure its serviceability, we must invoke multiple patterns on a case-by-case analysis based on their implementation ability.

Back To Knowledge Center