Context
A monolithic application is created as a single logical executable unit with 3 parts usually – a database, a client side UI and a server-side application. Any alterations/updates mean that a developer must build and deploy a new version/release of the server-side application which contains the domain specific logic.
On the other hand, a microservice delivers a business-oriented API which encapsulates a code business functionality. The same service can be re-used in multiple business contexts across multiple business channels and in multiple digital touchpoints. It is based on the principle of loose coupling.
Traditional software development methodologies (waterfall, agile, etc.) usually result in monolithic deployment products. But having watched the transformation journey of SAP, we are all aware of the various lurking issues of this traditional approach – limited re-use, limited scalability, limited operational agility, etc.).
With the advent of HANA cloud in conjugation with YaaS microservices ecosystem, we are moving towards creating products and not projects. But what about the existing legacy systems? Is the next step to re-engineer the legacy applications into microservices? If yes, then what could be the way forward?
There are quite obviously two ways to application modernization – the Big Bang re-write and the new concept of Strangulation. In the Big Bang rewrite we would focus on rewriting the entire application into micro-services based application from scratch. This is extremely risky and there could always be functionality and business context hidden in the legacy application that people have forgotten about and might be missed.
On the other hand Strangulation aims to phase one thing out for something better, cheaper and scalable.
Strangler Application
The concept is to gradually create a new system around the edges of the old one and letting it grow slowly until the old system is strangled. This pattern considers the fact that businesses never actually live in a greenfield world. The Strangler pattern helps us manage the refactoring of a monolithic application in stages.
There are 3 steps to strangulation:
- Transform – Create a parallel microservice which provides a modular functionality from the legacy application.
- Co-exist – Leave the existing module in the legacy application as-is. Incrementally redirect the traffic from the legacy module to the newly created microservice.
- Eliminate – Once the traffic is completely redirected to the microservice, eliminate the legacy module.
The best thing about this methodology is it creates incremental value much faster much safer than one big migration. It also has the incremental approach which means that if at any point of time, you see that the newly created microservice faults, you can change direction. Turn existing modules within the legacy to standalone microservices, starting with the least complex module in the legacy system. Each time a module is converted, the monolith shrinks/strangulates. Once enough modules have been refactored, the monolith either disappears entirely or is small enough to be just another service. The glue code or the anti-corruption layer is very essential during this transformation and it prevents the new service from being corrupted by the legacy application’s concepts. During the development phase, it forms the integration layer between the monolith and the microservices.
Always split the refactoring:
- Backend refactoring to microservices – this includes added business context and functionality
- Front end refactoring to accommodate the microservices – includes providing new user experiences and custom experiences
Over time the number of microservices will grow, and the agility and velocity of your development team will increase.
Using strangler pattern
Pre-requisites in the monolithic application for using this re-structuring pattern is:
- Web- or API-based monolith
- Standardized URL structure (true use of URLs)
The strangler pattern should not be applied one page at a time – business process module creation is very important. The smallest level is a single independent microservice.
This new and upcoming development methodology has not been whole-heartedly adopted yet by most software companies. But, there are a lot of references in this area from the ecommerce companies who have adopted this pattern for moving to micro services like Netflix, Amazon, etc.
An important aspect to consider while modernizing an old application or designing a new one – design to easily strangle in the future – modularize, separate the layers, make it scalable. After all, we are writing tomorrow’s legacy software today. So let’s make enable it to gracefully fade away tomorrow!
References
https://www.martinfowler.com/bliki/StranglerApplication.html
https://www.ibm.com/blogs/bluemix/2017/07/using-microservice-application-patterns/
https://www.nginx.com/blog/refactoring-a-monolith-into-microservices/
https://paulhammant.com/2013/07/14/legacy-application-strangulation-case-studies/
https://www.michielrook.nl/2016/11/strangler-pattern-practice/
- SAP Managed Tags:
