The Strangler Fig application pattern: incremental modernization to microservices

architecting   microservice architecture   refactoring to microservices  

---

In 2004, @martinfowler described how a hike in rain forest led him to realize that the Strangler Fig is a great metaphor for an effective way to modernize an application.

So what is the Strangler Fig application pattern and why use it to migrate a monolith to microservices?

What’s a Strangler Fig?

A Strangler Fig is a plant that is found in rain forests. It starts its life in the canopy of a tree, grows down to the ground and establishes roots. It then grows rapidly and can ultimately kill the tree by blocking sunlight.

In 2019, I was excited to find a Strangler Fig in Singapore’s botanical garden:

What’s the Strangler Fig application pattern?

The Strangler Fig is a metaphor for incrementally building a new application around the legacy application. The legacy application is the tree, and the new application is the Strangler Fig. Over time, functionality is migrated from the legacy application to the Strangler Fig application. The Strangler Fig application gradually increases in size while the legacy application shrinks. Moreover, new functionality can be implemented directly in the Strangler Fig application.

The Strangler Fig application is comprised of microservices

If you are migrating to a microservice architecture, then the legacy application is the monolith, and Strangler Fig application consists of services.

Why is the Strangler Fig application pattern better than a big bang rewrite?

An alternative way to modernize an application is the big bang rewrite, which is when you recreate the entire application from scratch. On the surface, the big bang rewrite seems like the most straightforward approach. Simply start a (possibly large) project to recreate the functionality of the existing application as a collection of microservices. And, once the new application is complete, you switch over to it.

So why use the Strangler Fig application pattern?

Strangler Fig application pattern: acknowledges that modernization is a process of discovery

The Strangler Fig application pattern reflects the fact that with legacy systems the true requirements are not always known. The original requirements might be lost. The application implements functionality that is no longer needed. As a result, modernizing a legacy system is often a process of discovery.

Strangler Fig application pattern: benefit from services immediately

Another key benefit of the Strangler Fig application pattern is that you benefit from microservices almost immediately, as soon as you have the first service. What’s more the benefits steadily increase over time as the number of services grows. Moreover, new features can be directly implemented as services.

In contrast, a big bang rewrite only delivers no value until the very the end when it’s completed. What’s more a big bang rewrite is chasing a moving target. And like any large project it’s likely to take far longer than planned, which pushes the benefits further into the future.

Strangler Fig application pattern: enables agility

Another benefit of the Strangler Pattern that is that you can dynamically adjust the order in which you migrate functionality to services based on the immediate needs of the business, e.g. quickly respond to competitive threats by writing new services and migrating critical functionality out of the monolith. The Strangler Fig application pattern also gives you the flexibility to pause the modernization if higher priority feature development need to be done.

The Strangler Fig application pattern = early and continuous feedback and learning

Another important benefit of the Strangler Fig application pattern is that it forces you to validate your approach to using microservices and quickly learn from your mistakes. That’s because very early in the modernization effort you are deploying microservices into production, starting with the first service. You are validating your architecture and design decisions in the crucible of production. Sadly, with a big bang rewrite you discover where you went wrong at the end. Oops!

For example, let’s imagine that you decided use a shared library that changed regularly as a result of feedback from users. After implementing just a few services, you would quickly discover the downsides of regularly having to update those services simultaneously. You would then be able to use a different approach before having baked it into 10s or 100s of services.

Moreover, you might even discover that microservices are not the right approach for your organization. Perhaps issues with your architecture are not the main reason why you are struggling to deliver software. Or perhaps, your organization is not ready to make the necessary changes to its culture and organization. The Strangler Fig application pattern enables you to learn this early on, before you’ve invested a lot of time and money.

Downsides of the Strangler Fig Application pattern

The Strangler Fig application pattern is not a silver bullet. One drawback is that, unlike a big bang rewrite, which ignores the existing code base, the Strangler Fig application pattern typically modifies the legacy application. For example, in order to extract a service from the legacy application, you’ll often need to decouple it from the rest of the legacy application. Also, you will typically need to change the legacy application invoke services or handle requests from them. If the legacy application uses ancient technology, then making these changes can be very difficult. Yet another reason to keep your applications’ technology stacks reasonably current.

In summary

The Strangler Fig application pattern has numerous advantages over the big bang rewrite:

• Acknowledges that modernization is a process of discovery
• Delivers value immediately
• Enables you to quickly respond to the needs of the business.
• Results in early, and continuous feedback and learning

One drawback is that you typically need to modify the legacy application, which can be difficult if it uses ancient technology.

To learn more

If you want to learn more then take a look at my presentation - Six principles for refactoring a monolith to microservices https://chrisrichardson.net/post/refactoring/2020/07/28/six-principles-for-refactoring-to-microservices.html - along with this page https://microservices.io/refactoring/index.html, which includes a good example.

Need help migrating to microservices?

I’m available to help your organization adopt microservices. I provide consulting and workshops.