With the adoption of micro-services, a lot of us are looking at ways to migrate existing monoliths into microservice architecture. There are multiple patterns which can be used depending on the need and scenarios. In this post, let us see how we can use strangler fig pattern to extract out microservices from an existing monolith. It is recommended to break the below transition into multiple releases. This will allow to take appropriate remediation steps when things are not going as planned.
Let’s take an example and see how the below mentioned steps can help in carving out analytics service from a monolith.
The above figure shows the monolith in existing state i.e. before any decomposition. All the external and internal(obviously) calls are sent to the existing analytics service.
Step 1 – Introduce a proxy for the purpose of redirecting analytics service calls. This would also help us weigh in the latency added by introducing an additional network hop.
In the same cycle(release), a very basic(or empty) implementation of the new analytics service can also be deployed. At this moment, it will just exist as a separate service/container and would not be getting any requests.
Step 2 – This can be further broken down into following steps.
2a. COPY the implementation from the existing analytics service over to the new service. The main point to note here is the copy part. Do not MOVE the code until we decide to retire the older implementation.
2b. Add configuration in the proxy to start redirecting analytics call to the new service instead of the old implementation. Change internal analytics calls to point to the proxy instead of the existing implementation. This is required to be able to switch back to the old version if there are issues with the new implementation without having to deploy the monolith again. This can be achieved using feature toggles pattern.
Step 3 – In case, the request to the new implementation returns a failure response, redirect it to the old implementation. This too can be done via proxy configuration.
Step 4 – After the new implementation is performing as per expectations and all the relevant tests/metrics turn out to be satisfactory, the old implementation can be removed altogether.
