The Strangler Pattern Approach and How it Works

Transitioning from one system to another can be a complicated task, and it’s not always easy to decide which approach to embrace. You don’t necessarily want to take your systems offline while they’re rewritten, but at the same time, it isn’t easy to undertake a rewrite without some disruption to your operation.

However, if you’re transitioning from monolithic legacy systems to a microservices approach, there is one transitional software architecture that could minimize this kind of disruption. It’s called the strangler pattern (or strangler fig pattern), and it works by replacing system elements in increments.

Let’s take a look at what the strangler method is, how it got its name, and the benefits and drawbacks of using this architecture to switch from monolith to microservices.

What is the strangler pattern (aka the strangler fig pattern)?

Image source

The strangler is one of the more popular microservices architecture patterns. It’s useful for transforming monolithic applications to microservices without disrupting ongoing work too much.

The alternative term, “strangler fig” pattern, was coined by Martin Fowler in the 2000s after he observed the growth of strangler figs in the rainforests of Queensland. 

Strangler fig seeds root in the high branches of large trees. From there, they grow down to the forest floor in intricate and beautiful vine patterns (hence this architecture pattern sometimes also being called the “vine pattern”). They’re an awe-inspiring sight, despite the fact that they ultimately kill (by strangling) their host.

Strangler figs struck Fowler as a good metaphor for rewriting important systems without immediately deleting and/or overwriting the original.

Strangler patterns are very useful when switching from monolithic applications to microservices. Rather than immediately “killing” the original monolith, a strangler approach replaces parts of this with microservices over a period of time. 

Just like its namesake, the strangler architecture will eventually entirely replace the “host”. Yet before this happens, users benefit from a blended format, in which they can access legacy files and systems while increasingly gaining the advantages of microservices.

The strangler pattern works in three stages:

1. Transform. New microservice components are “fitted” to the legacy system.
2. Co-exist. Monolithic and microservice elements exist side by side during this transitional phase.
3. Eliminate. Once the microservice architecture is well established, the original monolith is deleted.

Ultimately, a strangler approach allows businesses to transition from monolithic to microservice-based operations incrementally, without the disruption and risk of an immediate and complete rewrite.

Benefits and drawbacks of a strangler pattern approach to software systems

Like most things, a strangler pattern approach comes with advantages and disadvantages.

The benefits of a strangler pattern approach

1. Incremental migration. A complete rewrite of a system is risky, time-consuming, and disruptive, but a strangler approach gets rid of a lot of this disruption by working in increments. As well as giving users plenty of time to adjust, gradual implementation also gives developers more time and scope to spot and solve issues before they become problematic.
2. A smooth transition. Additionally, the coexistence phase makes the transition from monolith systems to microservices easier for everyone concerned. Users can still access aspects of the legacy system until they’re used to the alternative, and ongoing operations aren’t disrupted by the migration.
3. Flexibility. A strangler pattern also allows businesses to restructure their systems according to business priorities rather than in a rigidly predefined manner.  

The drawbacks of a strangler pattern approach

1. Syncing issues. It’s not always easy to seamlessly integrate old and new data. Strangler migrations need careful management to make sure data syncs in a functional and consistent way.
2. Dependency conflicts. Dependency management is a big part of any strangler pattern migration. It’s not uncommon for dependency conflicts to arise between old and new elements, and these can be tricky to resolve.
3. Complexity. Mingling microservices with monoliths is rarely completely straightforward. Working with strangler pattern migrations can be complex and requires a lot of careful management.  

The strangler pattern is one route to microservices architecture

For businesses looking to transition to microservices, the strangler fig pattern is a good way to migrate from monolithic architecture to something more modern and flexible—but it’s not the only option out there.

There are plenty of software architecture design patterns available for transforming systems. The strangler method is just one of these—albeit a useful and popular choice with many upsides.

For example, using a strangler pattern can minimize disruption by replacing legacy systems in increments. There’s no need to shut down operations while the system is rewritten, and it allows businesses a lot of flexibility in their migration.

That being said, there are also various disadvantages to counterbalance these, which may lead businesses to pick another architectural design pattern in its stead. For example, the strangler method can be complex, and it’s not uncommon for new and old systems to experience conflicts.

Irrespective, switching to a microservices approach can bring many benefits to your business. If you’re thinking of upgrading from a monolithic legacy system to a more modern microservices-based approach, get in touch and see how OpenLegacy can help.