Strangling the Legacy Monolith: Strangler Pattern

What it is ?

Its name is derived from ‘Strangler Fig’ tree. Their huge strangler vines grow by strangling and killing the tree that was their host.

Context and Problem

• System architectures that has become increasingly obsolete (brownfield application)
• The platform is so monolithic, full of legacy code with a high level of technical debt
• Implementing a new (greenfield) application but it’s not quite as clear how to implement them in an existing application
• Completely replacing a complex system can be a huge and quite risky. The release might land up behind the latest stack. It could lead to the application not behaving as it should or worse, breaking.

Strangler Pattern

Incrementally replace specific pieces of functionality with new applications and services. You need to have methodical approach to replace it piece by piece.

Martin Fowler describes this approach as Strangler Application pattern.

Implementation approach

Role of Facade layer

The design goal is to minimise the communication and dependencies between subsystems. Keeping a facade layer allows to transform and co-exist. Clients do not have to be aware of the actual implementation of the subsystem and are provided with a simpler interface to this subsystem. The interface can switch between new and old services.

Create a facade that intercepts requests going to the backend legacy system. The facade routes these requests either to the legacy application or the new services.

Moving parts

• Identify the bounded context in your application e.g In an airline application, flight booking would be one bounded context.
• Choose the smallest and least costly context to refactor. Rank your other bounded contexts in order of complexity from least complex (and potentially costly) to most complex.
• Plan out microservices within context
• Group screens together from UI, into a set of logical flows as user journeys. A Flow is a simple concept—it's a group of screens that connect from one to another to perform a single user task like booking a flight in a travel website.
• Size your chunk. Identify connections between flows or a group of flows. Choose whether to release an entire chunk at a time, or each chunk as a series of slivers. A Sliver is the smallest releasable unit that incorporates a microservice and the changes that surround the microservice to make it usable to the end user.

When does the pattern work ?

• Web or API-based monolith
• Standardised URL structure (true use of URLs)
• Meta UIs - When the UI is a “meta” UI (such as when it is business-process based and/or constructed on the fly)

How not to apply the pattern

• Don’t apply it one page at a time: The smallest sliver is a single microservice. You want to avoid having two different data access methods for your data at the same time to avoid consistency problems.
• Don’t apply it all at once: If you do your entire application at one time you’re not really applying the Strangler Pattern, are you?

Questions ?

nitinsinha1@gmail.com

Disclaimer

The images used in this blog's posts are found from different sources all over the Internet, and are assumed to be in public domain and are displayed under the fair use principle. I provide information on the image's source and author whenever possible, and I will link back to the owner's website wherever applicable.