The Strangler Fig application is based on the analogy of a creeper strangling the tree around which it is wrapped. 

The idea is to use the structure of a web application—the fact that web applications are built from individual URIs that functionally map to different aspects of the business domain—to split the application into different functional domains and replace those domains with a new microservices-based implementation one domain at a time. 

This creates two separate applications that live side by side in the same URI space. Over time, the newly refactored application “throttles” or replaces the original application, until eventually, you can completely shut down the monolithic application. So the steps of the Strangler Fig pattern are transformed, co-existed, and eliminated:

Transformation – Create a parallel new website (for example, in IBM Cloud or your existing environment) based on more modern approaches.

Co-exist – Leave the existing site where it is for a while. Redirect the current site to the new one so that the feature is implemented gradually.

Eliminate – Remove the old feature from the existing site (or simply stop maintaining it) as traffic is redirected from that part of the old site.

Refactor the monolith or rebuild it from scratch?

Rewriting a large monolithic application from scratch is a big effort and comes with a lot of risks.

The Strangler Pattern reduces the above risk. Instead of rewriting the entire application, you replace the functionality step by step. The business value of new features is delivered much faster. If you follow the Single Responsibility Principle and write loosely coupled code, you will greatly simplify future refactoring.

How do you choose which components to throttle/refactor first?

If you are following the Strangler pattern for the first time and are new to this design pattern, playing it safe and choosing a simple component is not a bad choice. This will ensure you gather practical knowledge and acclimate yourself to the challenges and best practices before you choke on a complex component.

If there is a component that has good test coverage and less technical debt associated with it, starting with that component can give teams a lot of confidence during the migration process.

If there are components that are better suited for the cloud and have scalability requirements, start with one of those components.

If there is a component that has frequent business requirements and therefore needs to be deployed much more regularly, you can start with that component. This ensures that you don’t have to redeploy the entire monolithic application on a regular basis. Splitting into a separate process allows you to scale and deploy your application independently.

When does the pattern work and when doesn’t it?

Of course, you can’t assume that the pattern will apply to every situation. There are several prerequisites that must be met for this approach to be successful:

1. Web or API-based monolith: 

This is the first requirement. The whole point of the Strangler Fig Application pattern is that you need to have a way to easily move back and forth between the new and old functionality. If you’re working with a web application, then the URL structure of that application gives you a framework for choosing which parts of the system are implemented in which way. On the other hand, thick client applications or similar native mobile applications are not as suitable for this approach as they may not have the structure that allows you to divide the application in the same way.

2. Standardized URL structure (actual URL usage): 

Although all web applications follow certain standards imposed by the structure of the web (such as the use of HTTP and HTML), there are many different application architectures that can be used for implementation. those web applications. However, there is still a lot of room within this approach. For example, if there is an intermediate layer below the server requests (as with portal access), you may have a problem if you use URLs to split the application; switching and routing decisions are not made at the browser level, but deeper in the application, which is more complex.

3. Meta UI: 

When the UI is a “meta” UI (e.g. when it’s based on a business process or constructed on the fly), the approach will still work, but the piece is bigger and has to be implemented all at once. This is because you need to rework either the entire generation framework or at least all those places that interact with your current non-microservices business model.

How not to apply a pattern?

Just as there are times when the pattern works, there are also times when it doesn’t—or at least isn’t easily applied. These cases include:

Don’t apply it one page at a time: The smallest piece is one microservice. You want to avoid having two different methods of accessing the data at the same time to avoid consistency issues.

Don’t Apply All At Once: If you’re doing the whole application at once, you’re not actually applying the Strangler pattern, are you?

Conclusion

Transforming your existing legacy monolithic application to cloud-native microservices is a nice end goal, but the journey is challenging and must be well designed and planned. In this article, we have discussed a design pattern called “Strangler Pattern” that can help you in this journey. Teams can continue to deliver business value by doing all greenfield development as part of new services and gradually migrating from monolith to microservices. However, keep in mind 

that strangling a monolith is not a quick process and may take some time.

You may get in touch with us at info@bigsteptech.com for any technical requirements. Let’s create the future together!