Strangler fig pattern

The design patterns discussed so far in this guide apply to decomposing applications for greenfield projects. What about brownfield projects that involve big, monolithic applications? Applying the previous design patterns to them will be difficult, because breaking them into smaller pieces while they’re being used actively is a big task.

The strangler fig pattern is a popular design pattern that was introduced by Martin Fowler, who was inspired by a certain type of fig that seeds itself in the upper branches of trees. The existing tree initially becomes a support structure for the new fig. The fig then sends its roots to the ground, gradually enveloping the original tree and leaving only the new, self-supporting fig in its place.

This pattern is commonly used to incrementally transform a monolithic application into microservices by replacing a particular functionality with a new service. The goal is for the legacy and new, modernized versions to coexist. 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.

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.

AWS Migration Hub Refactor Spaces is the starting point for incremental application refactoring to microservices on AWS. Refactor Spaces provides an application that models the strangler fig pattern for incremental refactoring. A Refactor Spaces application orchestrates API Gateway, Network Load Balancer, and resource-based AWS Identity and Access Management (IAM) policies so that you can transparently add new services to an external HTTP endpoint.

The following table explains the advantages and disadvantages of using the strangler fig pattern.

Advantages

Disadvantages

Allows for graceful migration from a service to one or more replacement services. Keeps old services in play while refactoring to updated versions. Provides the ability to add new services and functionalities while refactoring older services. The pattern can be used for versioning of APIs. The pattern can be used for legacy interactions for solutions that aren’t or won’t be upgraded.

Isn’t suitable for small systems where the complexity is low and the size is small. Cannot be used in systems where requests to the backend system cannot be intercepted and routed. The proxy or facade layer can become a single point of failure or a performance bottleneck if it isn’t designed properly. 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 following illustration shows how a monolith can be split into microservices by applying the strangler fig pattern to an application architecture. 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. The key point to note here is that both the monolith and the microservices will live together for a period of time.