Upgrading Your Architecture: Learn How to Use the Microservice Strangler Pattern

Introduction

The article explains one of the Decomposition Patterns known as the Strangler Pattern. The Strangler Pattern is an approach to migrating the Monolith system incrementally to Microservices. Strangle = Re-factor

The article covers,

1. What is Strangler Pattern with a Use-Case?
2. Implementation

Strangler Pattern

The Strangler Pattern is a pattern of migrating the legacy Monoliths to Microservices. This pattern was invented by Martin Fowler. Every architecture is different, some of them are modular and some of them are not and it’s not easy to navigate through the monolith. That’s why we need the common pattern where the Monoliths need to be transformed into Modular Monoliths first then into Microservices and this is exactly what Strangler Pattern is used for. Consider an Electricity Provider application where there are various modules like Billing, Customer Profile, Electricity Consumption details, Plan details, etc. The first image represents the Monolith.

Modular Monolith

Modular Monoliths are a pre-requisite if we are adopting the Strangler Pattern. The first step is to create the modules in the Monolithic application so that it is easier to take out the modules and spawn a new Microservice for that specific module. As in the Modular Monolith image, It’s easier to take out the modules like Billing, Consumption, and Plans as each module is singular, and spawning a new Microservice is easy.

Implementation

How do we select the component for refactoring to a separate service, well the easiest approach is to identify the simple component which is easy to re-factor or the component which receives less traffic as compared to other modules. In our Use-case Moving / Reference are a few such modules, by Moving it means the customer who wants to transfer it service from one location to another, second is Reference when one customer wants to refer any another customer to the electricity provider, this is the safe approach. Sometimes a decision has to be taken if any module is receiving the most number of requests then that specific component needs to be refactored as well on a priority basis.

As of now our application end-to-end looks like this,

Now we have decided to pick the Moving component to spawn it to a separate Microservice. The state of architecture now is,

Since the Moving Component is converted into a Microservice, all the requests intended to the Moving component will be routed to the ‘Moving’ Microservice via the ‘HTTP’ call or by producing an event through the Monolith, as ‘Moving’ is strangled to a new Microservice.

Similarly, other components can be taken out of the Monolithic Architecture and converted to separate microservices with the same approach.

After revamping all the components to separate Microservices, the complete architecture looks similar to

Summary

The strangler pattern has some pros and cons,

Pros

• Easier to incorporate new requirements as new service
• The two-step approach makes it easier to spawn Microservice, monolith to modular monolith.
• Safe approach as old services keeps running with the new refactored services.

Cons

• Not easy to modularize the application, if components are tightly coupled, a lot of development time is required and increased testing effort as well.
• A rollback plan should be handy, in case if something goes wrong while refactoring. In my experience, the production environment/scenarios are completely different.
• Increased Infrastructure cost.