What is Strangler Pattern?
The Strangler design pattern gets its name from the strangler fig tree, which grows around an existing tree and eventually replaces it. Similarly, in software development, the Strangler pattern involves creating new functionalities alongside the existing legacy system. Over time, the new system “strangles” the old one as more and more of its functionality is replaced. Ref: https://martinfowler.com/bliki/StranglerFigApplication.html
The Strangler design pattern is used to gradually migrate from a legacy system to a new architecture without disrupting the existing system. This approach allows for digital transformation by introducing new features and back-end applications alongside the old ones, eventually “strangling” the legacy system as it becomes obsolete.
Stages in implementing Strangler Pattern
The pattern typically involves the following steps:
- Identify the functionality to be replaced: Start by identifying the components or features of the legacy system that need to be modernized.
- Build new services: Create new services or APIs replicating the identified functionalities.
- Route traffic through a facade: Use a facade or API gateway to route traffic to the legacy system or the new services based on certain conditions.
- Incrementally migrate: Gradually replace parts of the legacy system with the new services until the legacy system is entirely deprecated.
Leveraging MuleSoft
MuleSoft’s API-led approach is the fastest way to implement the pattern.
Step 1: Assess and Segment the Legacy System
Begin by analyzing the legacy system to identify the components that need to be modernized. For example, you might have an old monolithic application responsible for multiple business functions like order processing, customer management, and billing.
Step 2: Create System APIs
System APIs in MuleSoft are responsible for connecting to core systems of record. You should start by building System APIs that expose the necessary functionalities of the legacy system.
- Legacy System API: Create an API that exposes existing functionalities of the legacy system. This API will act as a wrapper around the legacy system, enabling controlled access.
# Legacy System API RAML
#%RAML 1.0
title: Legacy System API
baseUri: http://api.company.com/legacy
/orders:
get:
description: Fetch orders from the legacy system
responses:
200:
body:
application/json:
example: |
[
{ "orderId": 1, "item": "Laptop", "quantity": 1 },
{ "orderId": 2, "item": "Smartphone", "quantity": 3 }
]
Step 3: Introduce Process APIs
Process APIs are used to orchestrate and shape data across different systems. You can create a Process API that combines the functionalities of the legacy system with new services, providing a unified interface.
- Order Processing API: This API could orchestrate order-related operations by interacting with the Legacy System API and any new microservices that replace parts of the legacy system.
# RAML specification for Order Processing API
#%RAML 1.0
title: Order Processing API
baseUri: http://api.company.com/order-processing
/orders:
post:
description: Create a new order
body:
application/json:
example: |
{ "item": "Tablet", "quantity": 2 }
responses:
201:
body:
application/json:
example: |
{ "orderId": 3, "status": "Created" }Step 4: Implement Experience APIs
Experience APIs are designed to meet the needs of specific consumers, such as mobile apps or web applications. These APIs consume the Process APIs and expose data in a format suitable for the end-user.
- Customer Experience API: A tailored API for customer-facing applications, abstracting the complexity of underlying systems.
# RAML specification for Customer Experience API
#%RAML 1.0
title: Customer Experience API
baseUri: http://api.company.com/customer
/customers/{customerId}/orders:
get:
description: Get orders for a customer
responses:
200:
body:
application/json:
example: |
[
{ "orderId": 1, "item": "Laptop", "quantity": 1 },
{ "orderId": 3, "item": "Tablet", "quantity": 2 }
]
Step 5: Gradual Migration and Traffic Redirection
With the APIs in place, you can gradually migrate functionalities:
- Redirect traffic: Initially, all requests are directed to the Legacy System API. As you build new services, start routing specific requests to the new services through the Process and Experience APIs.
- Monitor and optimize: Monitor the performance and reliability of the new APIs. Optimize as needed and incrementally redirect more traffic away from the legacy system.
- Retire the legacy system: Once all functionalities are fully replicated and tested in the new system, you can gradually retire the legacy system.
Step 6: Continuous Integration and Deployment
MuleSoft facilitates continuous integration and deployment (CI/CD) through Anypoint Platform. By integrating with tools like Jenkins, Git, and Maven, you can automate the deployment process, ensuring that new services are deployed quickly and reliably.
Step 7: Monitoring and Management
Use MuleSoft’s Anypoint Monitoring to track the performance of your APIs and ensure they meet SLAs. This helps in identifying bottlenecks, ensuring that the migration is smooth and that the new system is functioning correctly.
Conclusion
Implementing the Strangler design pattern with MuleSoft allows for a seamless and controlled migration from legacy systems to modern, scalable APIs. By following the steps outlined above, you can ensure that your migration is incremental, reducing risks while modernizing your architecture effectively.
MuleSoft’s API-led connectivity and robust tooling make it an ideal platform for executing the Strangler pattern, helping you achieve a modern, agile, and resilient system without the need for a disruptive “big bang” approach.
