Practical Monolith Decomposition & the Strangler-Fig Pattern
Harnessing the power of microservices without the Big Bang refactor
Microservices: What’s the Payoff?
Over the last decade or so, microservice architecture has been bandied about as the next great thing in software architecture. With its modularity, scalability, and natural fit into distributed systems, it’s very easy for developers to get excited about creating microservice-based architectures and all too easy for them to overlook the investment, challenges, and ongoing work associated with migrating an existing monolithic application to this new architecture.
When it comes down to it, as painful as it may be to continue maintaining your monolith, it is even more painful to pursue a “Big Bang” refactor — that is, a complete or near-complete rewrite from the ground up with a new architecture. This approach can be as expensive as it is risky, not to mention it can be nearly impossible to pitch to stakeholders who would need to foot the bill for the rewrite along with the maintenance of the monolith in the meantime.
In order to better plan a practical approach to decomposing the monolith, it’s important to understand the actual payoff of a microservice architecture: what do we gain by doing this work? There are many valid answers to this question, but my opinionated stance is that the single biggest advantage of a microservice architecture is the concept of independent deployability.
Independent Deployability
A godsend for developers, stakeholders, and end-users alike, independent deployability means that different parts of a system can be updated and deployed independently without affecting the entire application. This allows for faster and more frequent updates, as each microservice can be tested and deployed separately. This is in stark contrast to monolithic applications, where changes to one part of the system can have a ripple effect on other parts of the application, which necessitates more exhaustive testing and highly coordinated deployments.
The great fruits of independent deployability are increased velocity and agility. Velocity is increased due to the different parts of the system having well-defined and managed interaction points (a prerequisite for independent deployability), meaning developers can work in parallel and on different features with minimal logistical overhead.
With deployments being uninhibited and velocity increased, greater flexibility follows naturally. This is the ability to update and deploy individual microservices, which allows companies to respond quickly to changing market conditions and customer needs to release new features and updates in a more timely manner, keeping the business ahead of the competition.
Wrangling the Monolith with Strangler-Fig
Understanding that independent deployability is a good thing doesn’t do much good without a plan to achieve it. The good news is that it doesn’t require rebuilding the entire application at once — it can and should be done incrementally and methodically. Enter, the Strangler-Fig pattern.
The Strangler-Fig Pattern
The Strangler-Fig pattern is named after the strangler fig tree, which grows around a host tree, eventually enveloping and replacing it. In the same way, the Strangler-Fig pattern involves gradually extracting functionality from the monolithic application and building new microservices around it. Over time, the microservices replace the monolithic application, which becomes a thin shell that communicates with the microservices.
This gives a straightforward strategy for replacing the monolith piece by piece. In simple terms, the process looks like this:
- Identify a logical chunk of the codebase that makes sense to update and deploy as a singular unit.
- Create a proxy layer between this chunk and the rest of the codebase — this is often an API gateway that diverts specific to the new microservice while sending the others through to the monolith.
- Incrementally migrate this chunk’s functionality into the new microservice, updating the proxy layer in the process to continue handing off more and more requests to the microservice.
- Repeatedly migrate functionality until the entire chunk has been effectively migrated to the microservice and retire the code from the monolith.
From the above process, you can slowly extract the highest payoff functionality until you have a fully-fledged microservice, getting you the best return on your initial time investment. Additionally, you prioritize the greatest return by starting with parts of the codebase that have the greatest need for frequent updates and/or enhanced scalability. Repeating this process over time yields a full microservice application.
The Payoff
The ultimate goal of this process is to reduce friction at all points in the software development lifecycle for your project. By working iteratively towards a more modular system — full-blown microservices or not—you can have a strategy to reap the rewards of an independently deployable system while only rewriting/refactoring as much as your team can comfortably take on.
Consider the high-level project payoffs:
- More and faster deployments.
- Simplified testing.
- Minimal contextual overhead due to smaller independent systems.
- Increased ability for features to be worked in parallel.
Also, the technical flexibility you give yourself:
- Ability to scale services up or down to meet demand and control costs.
- Simplified recovery processes.
- Fault tolerance that comes with distributed systems.
It’s hard to envision a monolithic project where these advantages would not be a boon. Using the Strangler-Fig pattern gives a practical way to methodically migrate your project to a structure that exhibits those characteristics, without requiring the massive rewrite that you might otherwise expect. If you’ve been considering how to migrate your monolith to microservices pragmatically, I hope this article has been of some help!
For a deep dive into similar topics, be sure to read the great microservice architecture books by Sam Newman:
