Strangler Pattern Overview

The microservice Strangler pattern is employed when teams migrate functionality from an old solution to one or more new implementations. While the pattern can be used for any old to new service migration, the diagram below depicts the common use case of migrating from a monolithic solution to a microservice implementation:

Depiction of the strangler pattern and progression over time during migration

The solution above starts with a single monolithic application. Step one is to implement a proxy (or context switch) that can separate requests by type (Y-Axis or Service Segmentation), or if attempting to evaluate the solution for efficacy against an existing implementation, the X-Axis by transaction volume.

The pattern progresses with the monolith growing increasingly smaller as newly implemented services begin to take requests previously bound for the monolith.

Finally, the proxy is removed once the service disaggregation is completed.

Benefits of Strangler

  • The Strangler pattern allows for graceful migration from a service to one or more replacement services.

  • If implemented properly, with the ability to “roll back”, the pattern allows relatively low risk in migrating to new service(s).

  • The pattern can be used for versioning of APIs.

  • Similar to versioning above, the pattern can be used for legacy interactions (the old service remains for solutions that aren’t or won’t be upgraded).

Drawbacks to Strangler

  • If implemented with a “new” or additional service – something in addition to a prior proxy or load balancer, the solution decreases availability through the multiplicative effect of failure.

  • Per above, additional (new) services will increase latency.

How to Use Strangler Pattern

  • Use the Strangler for versioning or migration to new services.

  • Employ within an existing proxy – either a software-based load balancer (such as Nginx) or a layer 7 capable load balancer/context switch (F5 or Netscaler).

  • If using an existing proxy is not possible, ensure the client is responsible for choosing the resource.

  • Keep rules updated as services are migrated.

  • Prune rules as no longer needed.

What to NEVER do with Strangler

Never employ a new service and increase the call depth with Strangler. Such a service is often called a “façade”. Your existing proxy or load balancer solutions likely give you this flexibility today.

Facade anti-pattern used with Strangler Microservice Pattern

Never allow the solution to become a bottleneck or a single point of failure. Always ensure that the solution is scalable along the X-axis for both availability and scalability.

X-Axis Approach

The X-Axis approach takes a percentage of calls for any unique service endpoint and splits them between the old service and the new service. This approach is useful to A/B test the solution for end-user efficacy, response time, availability, and cost of operations (cost per transaction). It also allows for graceful “dialing up” or “dialing down” of the transaction volume (say from 1% to 51%).

Y-Axis Approach

This is the traditional usage for Strangler. It takes a monolith servicing N unique capabilities and partitions them along either verb/service boundaries (e.g. checkout separated from everything else) or noun/resource boundaries (e.g. catalog related actions from customer data actions).

Best Approach

If time allows, implement both the X and Y approach. X gives you rollback as well as A/B testing and significantly reduces your risk while Y allows service disaggregation.

AKF Partners has helped hundreds of companies implement and improve microservice based architectures. Give us a call, we can help you with your transition.