Strangler Pattern

In this article, let's talk about the Strangler pattern. This pattern will help you migrate your Legacy Aplicashines to the “new rails” smoothly. 

Problem and context

As your system evolves, your tools, hosting technology, and system architecture may become obsolete. The complexity of adding new features can be disproportionate. Sometimes it is easier to move to a new service and write new features there. However, if you write 2 services in parallel (old and new), users may have a question about which service to use for which requests.

Solution

Gradually replace functionality with new apps and services. Create facade, which will redirect to the necessary services and will be a single entry point for your client's aplikations. Existing functionality should be transferred to the new service gradually, and new features should be developed only in the new service.

Strangler helps minimize the risk of migrating to a new service and distribute development effort and time. With a facade that redirects to the right service, you can migrate old features to a new service at the right pace without worrying that a component will fall off. Over time, when you move all the functionality to the new service, the old system will be “strangled” and no longer needed. 

Problems and issues in implementation

• Consider how to handle services and data stores that will be used by both new and legacy services. Make sure that both systems have access to these resources at the same time.
• Structure the new applications and services so that they can be easily replaced in the same way when the pattern is applied to them in the future.
• At some point when the migration is complete, the strangler fig facade will either be removed or turned into an adapter for legacy clients.
• Make sure the facade keeps up with the migration.
• Make sure the facade does not become a single point of failure or performance bottleneck.

Use Pattern when:

Use this pattern when gradually migrating a back-end application to a new architecture.

Don't use Pattern When:

• When requests to the back-end system cannot be “intercepted”.
• For small systems where the complexity of full migration to a new service is insignificant