Design Patterns for Microservice Architecture – Strangler

If we want to use Microservice Architecture in a brownfield project, we need to migrate legacy or existing Monolithic applications to Microservices. Moving an existing, large, in-production Monolithic applications to Microservices is quite challenging as it may disrupt the application’s availability.

One solution is to use the Strangler pattern. Strangler pattern means incrementally migrating a Monolithic application to Microservice Architecture by gradually replacing specific functionality with new Microservices. Also, new functionalities are only added in Microservices, bypassing the legacy Monolithic application. A Facade (API Gateway) is then configured to route the requests between the legacy Monolith and Microservices. Once the functionality is migrated from the Monolith to Microservices, the Facade then intercepts the client request and route to the new Microservices. Once all the legacy monolith’s functionalities are migrated, the legacy Monolithic application is “strangled,” i.e., decommissioned.

Pros

• Safe migration of Monolithic application to Microservices.
• The migration and new functionality development can go in parallel.
• The migration process can have its own pace.

Cons

• Sharing Data Store between the existing Monolith and new Microservices becomes challenging.
• Adding a Facade (API Gateway) will increase the system latency.
• End-to-end testing becomes difficult.

When to use Strangler

• Incremental migration of a large Backend Monolithic application to Microservices.

When not to use Strangler

• If the Backend Monolith is small, then wholesale replacement is a better option.
• If the client request to the legacy Monolithic application cannot be intercepted.

Enabling Technology

Backend application frameworks with API Gateway.