Strangler fig pattern
This pattern is commonly used to incrementally transform a monolithic application into microservices by replacing a particular functionality with a new service.
Goal
is for the legacy and new, modernized versions to coexist.
Works well when
you can intercept the calls at the perimeter of the monolith.
The new system is initially supported by, and wraps, the existing system. This support gives the new system time to grow and to potentially replace the old system entirely.
Steps
The process to transition from a monolithic application to microservices by implementing the strangler fig pattern consists of three steps: transform, coexist, and eliminate:
Transform
Identify and create modernized components either by porting or rewriting them in parallel with the legacy application.
Coexist
Keep the monolith application for rollback. Intercept outside system calls by incorporating an HTTP proxy (for example, Amazon API Gateway) at the perimeter of your monolith and redirect the traffic to the modernized version. This helps you implement functionality incrementally.
Eliminate
Retire the old functionality from the monolith as traffic is redirected away from the legacy monolith to the modernized service.
Advantages and disadvantages
| Advantages | Disadvantages |
|---|---|
| Allows for graceful migration from a service to one or more replacement services. | Isn’t suitable for small systems where the complexity is low and the size is small. |
| Keeps old services in play while refactoring to updated versions. | Cannot be used in systems where requests to the backend system cannot be intercepted and routed. |
| Provides the ability to add new services and functionalities while refactoring older services. | The proxy or facade layer can become a single point of failure or a performance bottleneck if it isn’t designed properly. |
| Thepattern can be used for versioning of APIs. | Requires a rollback plan for each refactored service to revert to the old way of doing things quickly and safely if things go wrong. |
| The pattern can be used for legacy interactions for solutions that aren’t or won’t be upgraded. |
The following illustration shows how a monolith can be split into microservices by applying the strangler fig pattern to an application architecture.
NOTE
The key point to note here is that both the monolith and the microservices will live together for a period of time.
- Both systems function in parallel, but you’ll start moving functionality outside the monolith code base and enhance it with new capabilities.
- These new capabilities give you the opportunity to architect microservices in a way that best suits your needs.
- You’ll continue stripping out capabilities from the monolith until it’s all replaced by microservices.
- At that point, you can eliminate the monolith application.
References
https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html https://martinfowler.com/bliki/StranglerFigApplication.html