Strangler Pattern

Photo by David Clode on Unsplash

It is a strategy to incrementally modernize micro-service architecture. The advantages of this pattern are that you reduce the risk of heavy migration of a complex application in the one-shot, at the same time, the clients don’t get affected or in-fact remain unaffected by this change. It is typically suited for a large complex legacy/monolith applications.

Steps to Strangle

• Analyze the monolith application
• Analyze the functional area that needs to be migrated and identify the bounded context that will be owned by the new microservice(s)
• Plan the strangler facade that will help to route the traffic to the old or new system according to a configuration setting
• Plan the deployment of the microservice(s) that will progressively fulfill the functionality of the legacy application. This step is very important as planning to deploy multiple microservices at the same time end up creating more mess than expected. For example, if you have a CQRS pipeline, you can fulfill the command pipeline (persist data to both legacy and microservice datastore) in one release and plan query pipeline which might have more integration points to other services to another release.
• Roll out the incremental development as planned in the previous step, replacing the functionality incrementally.
• When the functionality is completely operating on the new microservice, you can remove the facade and the legacy components.

Word of Caution

• You have to conduct a thorough system analysis to identify the affected areas to avoid finding the same during the active development phase.
• Always plan to have an incremental release to production monthly or once in 2 months, instead of planning a big release involving multiple microservices after say 6 months.
• Make sure the stranger facade doesn't become a single point of failure or performance bottleneck.