The strangler pattern is a technique from Dave Farley’s ‘Continuous Delivery’ for transforming a monolithic software system into a microservices-based architecture. It involves gradually replacing parts of a big monolithic software system with smaller microservices, thus "strangling" the monolith over time until it is completely replaced. The name ‘strangler pattern’ is derived from the strangler vine that grows on another tree, using it as physical support, while also stealing sunlight and nutrients from it, which eventually kills the host plant.
Step by Step
Here are the steps to transform a monolithic software system to a microservices-based architecture using the strangler pattern:
- Identify the boundaries: The first step is to identify the distinct boundaries within the monolith system that can be broken down into separate microservices. This could be done based on business capabilities, functional domains, or technical dependencies.
- Define the interfaces: Once the boundaries have been identified, the next step is to define the interfaces between the microservices and the monolith. This involves specifying the data that will be exchanged between the microservices and the monolith and the APIs that will be used for communication. (tip: employ techniques from Domain Driven Design to guide this process)
- Implement the microservices: With the interfaces defined, the next step is to start implementing the microservices one by one. This involves creating a new service that implements a small part of the functionality of the monolith and defining the API that will be used for communication.
the strangler vine
- Route traffic to the microservices: The next step is to route traffic to them once the microservices have been implemented. This could be done by gradually modifying the routing rules of the monolith to send traffic to the microservices instead of the monolith.
- Decommission the monolith: As more and more traffic is routed to the microservices, the monolith becomes less critical. Eventually, when microservices have replaced all the functionality of the monolith, the monolith can be decommissioned.
The strangler pattern is a gradual and iterative process; it is important to start small and focus on the most critical parts of the monolith first. Over time, more and more functionality can be migrated to microservices until the monolith is no longer needed.
Monolith to Microservice using the strangler pattern
The Ship of Theseus
The story of the Ship of Theseus is a philosophical paradox that raises the question of identity over time. The story goes that the Athenians preserved the ship of Theseus in a dock as a memorial to their hero. As the years passed, the planks of the ship began to rot and were replaced one by one until no original plank remained. The question then arises: is the ship that remains still the ship of Theseus, or is it a new ship entirely?
Similarly, the strangler pattern involves gradually replacing parts of a monolithic software system with microservices until the original system has been fully replaced. The question then arises: is the resulting system still the same system as the original monolith, or is it a new system entirely?
In both cases, the identity of the original entity is called into question due to the gradual replacement of its constituent parts. In the case of the strangler pattern, the resulting system is still functionally the same as the original monolith, but it has been restructured into a new architecture.
AI Ship of Theseus
Conclusion
Ultimately, the Ship of Theseus story and the strangler pattern illustrate the challenges of the gradual replacement of parts of a larger system (monolith/ship). Both cases raise questions about continuity and change. The strangler pattern is the best way to de-risk an otherwise extremely risky replacement operation of a monolith. When you carefully plan what parts of the monolith migrate in which order you can safely enjoy a transformation what would otherwise caused much heartache and stress.
