Design Patterns for App refactoring to microservices

The article covers the 2 patterns for the migration from the existing app the micro service

1. Strangler pattern
2. Anti-Corruption pattern

Strangler Patterns

Incrementally migrate a legacy system by gradually replacing specific pieces of functionality with new applications and services. As features from the legacy system are replaced, the new system eventually replaces all of the old system's features, strangling the old system and allowing you to decommission it.

Context and problem :

The legacy system are not only difficult to manage even adding the new feature, adopting the new technology is difficult.

To over the come this and to make the legacy application to Microservice based, we can use the strangler pattern

Solution :

Incrementally replace specific pieces of functionality with new applications and services. Create a façade that intercepts requests going to the backend legacy system. The façade routes these requests either to the legacy application or the new services. Existing features can be migrated to the new system gradually, and consumers can continue using the same interface, unaware that any migration has taken place.

This pattern helps to minimize risk from the migration, and spread the development effort over time. With the façade safely routing users to the correct application, you can add functionality to the new system at whatever pace you like, while ensuring the legacy application continues to function. Over time, as features are migrated to the new system, the legacy system is eventually "strangled" and is no longer necessary. Once this process is complete, the legacy system can safely be retired.

Issues and considerations

·       Consider how to handle services and data stores that are potentially used by both new and legacy systems. Make sure both can access these resources side-by-side.

·       Structure new applications and services in a way that they can easily be intercepted and replaced in future strangler fig migrations.

·       At some point, when the migration is complete, the strangler façade will either go away or evolve into an adaptor for legacy clients.

·       Make sure the façade keeps up with the migration.

·       Make sure the façade doesn't become a single point of failure or a performance bottleneck.

 Anti-Corruption Layer Pattern

There are certain scenarios where the micros services are need to be connected with the Legacy system, Anti Corruption layer will help us to build the communication channel between the Microservices and Legacy application

Context and problem

what and how the communication between the legacy and new application being build

Solution

Isolate the different subsystems by placing an anti-corruption layer between them. This layer translates communications between the two systems, allowing one system to remain unchanged while the other can avoid compromising its design and technological approach

Anti-Corruption design layer

Where will be our anti-corruption layer fits in? below are approach which we can take a look

Design option – 1

When we have the scenario where we cannot make any changes to the monolith application, façade will connect and interact with the monolith 

Design Option – 2                                                                                                               

If the monolith will permit to write a wrapper method to interact with the external world then below design pattern can be used

Design Option – 3

If monolith interact with the multiple system/services, then move the entire Anticorruption layer to monolith 

Issue and Consideration

·       The anti-corruption layer may add latency to calls made between the two systems.

·       The anti-corruption layer adds an additional service that must be managed and maintained.

·       We should have the strategy in place to manage the scalability of the monolith .

·       Consider whether you need more than one anti-corruption layer. You may want to decompose functionality into multiple services using different technologies or languages, or there may be other reasons to partition the anti-corruption layer.

·       Make sure transaction and data consistency are maintained and can be monitored.

·       If the anti-corruption layer is part of an application migration strategy, consider whether it will be permanent, or will be retired after all legacy functionality has been migrated