Strangler Microservice Design Pattern
Problem Statement:
Working on the Monolith Application and the legacy codebase has multiple challenges and issues, some of them are as follows:
Ø Violation of “S” in S.O.L.I.D design principle, which single responsibility pattern.
Ø Single team working on large codebase.
Ø Lack of unit test cases covering whole business logic end to end.
Ø More code coupling between the services.
Ø Less scalability, extensibility and code reusability.
Ø System operation issue (if Module X is failing, who is the owner ?)
Ø Slow development and deployment cycle.
Suppose there is an ecommerce application (monolith) having multiple components embedded with it like Product, Payments, Shipment, Order etc. Three different teams are working on same codebase on multiple components within same application, there is great possibility if a team working on order introduce issue and push it on a environment using CI/CD pipeline, which can block Payment and Shipment team to be blocked to test their flow end to end.
Now the only solution left to solve this issue is to align the Order team to look in to the issue on top priority and fix the same to unblock another team. This can be a time-consuming task including debugging, preparing a hotfix, writing unit test cases to meet code coverage and deploy the hotfix on the environment. Imagine a situation when the developer who worked on that individual piece of code is not available and some other developer need to work on it, here we can have more chances of regression as that person won’t be aware of edge cases of this scenario.
As and when the application grows with the enhancements and features, the codebase will be large and difficult to maintain and also it is not easy to decouple the components in to smaller pieces in one go at this point of time and two seperate versions of the system cannot be run to handle this.
Solution:
Strangler design pattern help legacy applications to migrate incrementally in to smaller individual components and services. Suppose a new independent requirement comes where a new controller (“ShipmentLocationController”) need to be added with few http operations for shipment service. This time rather than adding the code in the existing legacy application codebase, a new microservice can be created with this new capability. Facade can be created in the existing legacy codebase which can intercept requests coming to it and decide whether to re-route it to the new microservice (ShipmentLocationController) and or to pass it within the legacy application. It will look like below:
If you see above image, Shipment service has been moved out of legacy application and decision need to taken by Ecommerce Strangler facade for re-routing of the incoming request. It will look like below if we keep on moving the legacy code using Strangler pattern
As we see from above daigram (1.4), Facade goes away as soon as Migration is completed or it should be compelted in some adapter to communicate with legacy consumers if needed. Also we need to be sure that facade should be up untill migraton is complete because here Facade is Single point of contact or orchestrator. With this migrated modern application, we can have one to one mapping of team and the services. If one service is down or having some issues, other teams will not be blocked like we discussed problem with legacy application.
