The Strangler fig pattern is what you need to migrate monolithic application with legacy code to microservices

The name Strangler Fig Pattern actually comes from a collection of plants that grow by “strangling” their hosts. Martin Fowler tooks this idea and transform it to a design pattern. Let’s see how it works and how it can help us.

An illustration of a strangler fig tree (generated by Microsoft Bing AI)

Context

Any sufficiently old codebase eventually starts to contain legacy code. Inevitably new coding standards emerge to reduce technical debt and we end up rewriting the application. The strangler fig pattern is an effective way to solve this problem.

What is Strangler Fig pattern?

The best way to explain it is with this following figure.

Strangler Fig pattern steps (source: strangler fig header)

In this picture, the tree (fig 1) represents the monolithic application with all the legacy code, and the fig tree (fig 4) represents new microservices we want.

Like the real fig tree, this design pattern aims to incrementally re-write small parts of your codebase, until after a few months/years, you have strangled all your old codebase and it can be totally removed.

Here is how it works technically:

1. Identify a functionnality or a logical chunk of the codebase that makes sense to update and deploy as a singular unit.
2. Create a facade (a proxy layer) between this chunk and the rest of the codebase. The facade should be able to target either the monolithic application, either the new microservices we are implementing.
3. Implement the new functionnality in the new system, and replace the link between the facade and the legacy code by a new link from the facade to the new microservice.
4. Repeatedly migrate functionality until the entire chunk has been effectively migrated to the microservice and the code from the monolithic has been removed.

Globally it would look like this:

Strangler Fig pattern migration steps

Let’s see how it works a bit deeper with these schemas:

Intial state

Step 1: Make a facade between the rest of the application and the legacy code you want to migrate

Step 2: Rewrite a new version of functionnality A through the new microservice

Step 3: Change the link with the facade to target the microservice, and remove Functionnality A in legacy code

Step 4: Increment the process to do the same for functionnality B

Step 5: Migrate functionnality C in another microservice (Y) with the same process / Remove useless functionnality D

Final state

From this perspective we can say that this Strangler Fig pattern can be also used to move legacy code to different microservices.

Benefits and considerations

Benefits

• Immediate benefits as we’re changing the code piece by piece.
• Allows you to push your changes in small modular pieces, easier to release.
• Reduces drastically migration risks as rollbacks are easier.
• Allows you to spread your development on the codebase over a longer period of time.

Warning points

• The Facade can be a source of SPOF (Single Point of Failure). Make sure it doesn’t happen.
• Some services and data stores can potentially be used by both new and legacy systems. Make sure both can access these resources side-by-side.
• Difficult to implement if the requests to the back-end system cannot be intercepted by a Facade.
• Not suited for smaller systems where the complexity of all code replacement is low.

I hope this article helped you having a better understanding of the Strangler Fig pattern and when it can be useful.