What is the Strangler Fig Pattern?
Context and problem
Any sufficiently old codebase eventually starts to contain legacy code. Architecture, performance, comments, and more begin to degrade the moment after they are written.
Some parts of the codebase last longer than other parts, but inevitably new coding standards emerge to reduce technical debt. Then you have to rework a large application, with zero downtime, making a “new way” of working without breaking anything in your release or development.
The Strangler Fig Pattern is one effective way to solve this problem.
What is the Strangler Fig Pattern?
The Strangler Fig pattern aims to incrementally re-write small parts of your codebase, until after a few months/years, you have strangled all your old codebase and it can be totally removed.
The rough flow is:
- add a new part to your system that isn’t used yet
- switch on the new part of the code — normally with a feature flag so it coexists with the old code
- finally, remove the old code.
This pattern helps to minimize risk from the migration and spread the development effort over time. With the façade safely routing users to the correct application, you can add functionality to the new system at whatever pace you like, while ensuring the legacy application continues to function. Over time, as features are migrated to the new system, the legacy system is eventually “strangled” and is no longer necessary. Once this process is complete, the legacy system can safely be retired.
Issues and considerations
- Consider how to handle services and data stores that are potentially used by both new and legacy systems. Make sure both can access these resources side-by-side.
- Structure new applications and services in a way that they can easily be intercepted and replaced in future strangler fig migrations.
- At some point, when the migration is complete, the strangler fig façade will either go away or evolve into an adaptor for legacy clients.
- Make sure the façade keeps up with the migration.
- Make sure the façade doesn’t become a single point of failure or a performance bottleneck.
Benefits of the Strangler Fig pattern
Aside from helping you avoid all the issues we’ve already discussed, it also:
- reduces your risk when you need to update things
- starts to immediately give you some benefits piece by piece
- allows you to push your changes in small modular pieces, easier to release
- ensures zero downtime
- is generally more agile
- makes your rollbacks easier
- allows you to spread your development on the codebase over a longer period of time if you have multiple priorities.
When to use this pattern
Use this pattern when gradually migrating a back-end application to a new architecture.
This pattern may not be suitable:
- When requests to the back-end system cannot be intercepted.
- For smaller systems where the complexity of wholesale replacement is low.
Thanks for reading.
#NeverEndingImprovement
references:
