The Strangler Pattern
Webapper’s CEO Patrick Quinn recently appeared on the Founders Focus podcast, where he spent some time describing “The Strangler Pattern”. It’s a technique we fully embrace at Webapper in our quest to migrate applications to cloud native architectures. Since most of the systems we migrate are mature applications, we don’t find many that are not monolithic. That is, migrating to the cloud most likely means the application wasn’t cloud native in the first place and unlikely designed for the cloud. So the next phase of the application’s lifecycle is to become more cloud-enabled, and that’s where the strangler pattern comes into focus.
What Is The Strangler Pattern
“An alternative route is to gradually create a new system around the edges of the old,
letting it grow slowly over several years until the old system is strangled.”
-- Martin Fowler
First, a bit of history… The idea of the strangler pattern came from an enterprise software development pundit named Martin Fowler. Mr. Fowler writes books and articles about software development, including topics like refactoring enterprise software design patterns. In 2004, Fowler and his wife went on holiday in Australia, where he saw the strangler fig trees in the rainforest. These banyan-like trees seed in the upper branches of a tree and gradually work their way down the tree until they reach the soil. As they grow into wild, exciting shapes, they strangle and eventually kill the tree where they first started. As a developer who was always rewriting critical systems, he used the strangler fig analogy as a way to describe his work.
When To Use It
Nearly all microservice success stories originate from a monolith application that grew unmanageable and was broken up. So keep in mind the strangler fig — you seed functions into your application, gradually replacing and augmenting the original monolith. Perhaps our favorite example of this is good ol’ Amazon. It’s well documented that the meteoric rise of Amazon’s e-commerce strained their original monolithic design. In Working Backwards, which breaks down Amazon’s culture, leadership, and best practices, authors Bill Carr and Colin Bryar describe how the database layer became a huge bottleneck. Think about it — a system originally designed to sell books and music was suddenly selling kitchen appliances and t-shirts (there are no related ISBN or ISRC codes!). Amazon’s culture shifted to microservices and APIs, which decentralized much of the work causing bottlenecks. Not only did the shift in culture enable Amazon to move faster, but it also truly strangled the original monolith within a few years. Today, a much more nimble Amazon can deliver innovation with ease. If the busiest e-commerce site in the world can be strangled, then it’s worth considering for your monolith…
A growing number of developers argue that you shouldn’t start a new project with microservices. Many projects that start with a microservice system as base end up in serious trouble. Why? Because monoliths work best for simple applications, while microservices are useful with more complex systems. There’s a premium to microservice development: the cost of managing a suite of services, which can slow down a development team.
What You Get…
It’s worth considering the strangler pattern over a traditional rewrite to reduce your risk. The strangler can continually deliver value, and frequent updates enable monitoring incremental progress. Let’s break it down:
The strangler pattern enables incremental migration to a new system.
Without rewriting core functions, you can extend a system with discrete, self-contained microservices. Later, as using microservices becomes “the way”, the strangler can replace those core routines.
You can pause migration while still using new system components.
Cutting over systems doesn’t preclude using new system components. Since they’re inherently independent, users can use microservices without the core system.
You reduce risk during each incremental step since each step is reversible.
Microservices and the strangler pattern dovetail nicely with agile software development. You can focus on incremental development sprints to deliver value throughout the software lifecycle. In parallel to adding functionality, the core system can be strangled. Risk is reduced, projects are more predictable, and there’s less stress on delivery teams.
Understanding the Strangler Pattern
Many enterprises — Amazon, Netflix, Wix, Google — have switched from monolithic structure to microservices. And undoubtedly their original model didn’t contemplate the scale they eventually reached (who could!?). There had to be a way to transition to modern application development, and the strangler pattern makes incredible sense. If you’re facing a lift & shift migration or a more complex refactoring project, it’s wise to understand how the strangler pattern could fit your plan.