You have a system/application that has been designed in a monolithic architecture and has been living for a long time, but you think that this architecture no longer meets your needs. So, after doing some research, you decided to move to a modern architecture and chose to switch to microservices architecture. You have two options now: Either you will rewrite your application from scratch with the new architecture and update it in one go with the Big Bang approach, or you will gradually reduce the old system part with the Strangler Pattern and gradually increase the new system part. In this article, we will shortly look at the Big Bang approach and then go into the Strangler Pattern in detail.

Big Bang Transformation

Rewriting a monolithic application in microservices architecture and deploying it all at once with the Big Bang approach will incur a significant cost. Let’s say you don’t have a problem with the cost. However, with this approach, you will face many problems other than cost. You will rewrite the system all at once and deploy it all at once. Therefore, you must conduct a very good integrated testing process and ensure that all system components work synchronously without causing serious surprises. Moving dozens of modules that have been working for years -and perhaps they will never need any changes- to the new structure and hoping that they communicate properly with each other all at once is a big risk. If you have experts who know the whole system while upgrading the old system, you can try it, but having and keeping all these experts in the organization is also very difficult. You should also consider the risks of the system interruptions or completely stopping during the big bang transition process.

From the technology and new demand points; the transformation time for the big bang can sometimes be so long that even the technology you choose can become outdated. In this case, your technical debt will also increase, and it will be very difficult to close it. Additionally, most probably while developing the new system, you don’t want to accept new requests for the old system, and requests will have to wait until the new system goes live. This will result in a significant delay in new features.

You can eliminate many of the above risks with the Strangler Pattern. Let’s see what the Strangler Pattern is and how it is applied.

What is Strangler Pattern?

It is a design pattern that involves gradually transforming a chosen functionality from a monolithic architecture to microservices architecture, and over time, moving all functionalities from monolithic architecture to microservices architecture. Monolithic services and microservices coexist for a period of time, and when the microservices begin to work stably over time, the services in the monolithic application are strangled and removed. In this transformation process, new demands arising from business needs are also attempted to be addressed on the microservices architecture.

The design pattern is named after the Strangler Fig plant (https://en.wikipedia.org/wiki/Strangler_fig), which clings to trees and gradually descends from the top to the root using the tree’s resources, eventually killing the tree. The term “Strangler” was first used by Martin Fowler, and those interested can read this article on the subject.

You can start benefiting from the advantages of your newly established microservices architecture with the Strangler pattern. The ability for teams to independently manage their own pipelines and continuously deploy new features will be great features to gain.

Stages of the Strangler Pattern

The Strangler Pattern consists of four basic stages:

1- Identification (Identify)

• Analysis of the monolithic application.

• Identification of the Boundex Contexts of the entire application or the part you have targeted for transformation (Bounded Context is a subject under Domain Driven Design, but in short, we can say that they are structures in which Domain Models that are closely related to each other form a complete meaning).

• Selection of the most suitable, smallest, and easiest Bounded Context for transformation. This Bounded Context should be a stable area that does not get much change and is generally stable. It may seem like why we should update a stable structure first, but since microservices architecture is complex by nature, transforming a stable structure will ensure that this structure will not get new features much and will not change much during the transformation process. This will allow you to focus more on your new architecture.

2- Transformation (Transform)

• Creation and release of the identified Context as a microservice.

3- Co-existence (Co-exist)

• Since your applications still use old services and you cannot direct all traffic to the new microservice you have created, you will need to create a Facade class that performs this multiple routing and transfer traffic through this class. Since the old service and the new service both receive traffic at the same time, they will coexist for a while. In such architectures, facade classes are usually designed as API Gateways. One point to be aware of is that this API Gateway must be designed to not experience performance issues and to not be a single point of failure.

4- Elimination (Eliminate)

• Remove the old system/service that is no longer needed in your co-existing system, allowing the applications to call the new microservice.

The cycle above is repeated by selecting a new microservice for transformation.

Another name for the Strangler pattern is Transform, Co-existence, Elimination pattern. Of course, there are many more detailed topics in reality. In particular, many questions such as how the pipeline structure of newly created microservices will be, whether the data will be duplicated during coexistence or only kept on one side, etc., need to be answered.

Conclusion

Although converting your current monolithic application into a modern microservices application may sound good, this journey is quite challenging and should be well-designed. The Strangler Pattern will be very helpful on this journey. It may take a long time to see the first output in your Strangler structure, but after you have established your mechanism, creating a new microservices structure and deactivating your old system will become easier. With Strangler, your risk will decrease, and you may even be able to throw away a microservice that you thought you had transformed incorrectly and you can rebuild it. If you go with the Big Bang transformation, your chance of success is very low in this regard. Despite all this information, if you still say “I insist on the Big Bang”, I’m ending this article by saying “good luck, take it easy” 🙂