Strangler Fig pattern for Azure migration

 Strangler Fig pattern

In the ever-evolving landscape of cloud migration, the Strangler Fig pattern emerges as a powerful tool for orchestrating seamless transitions without disrupting existing operations. As an Azure Solution Architect, I've witnessed firsthand the effectiveness of this pattern in guiding organizations through complex migration journeys.

The Strangler Fig pattern, inspired by the gradual enveloping of a host tree by the roots of a strangler fig tree in nature, involves incrementally replacing components or services of an existing system with their cloud-native counterparts. This gradual approach minimizes risks, ensures continuous functionality, and allows for iterative improvements.

Strangler Fig tree

Consider a scenario where a monolithic application is being migrated to Azure microservices. Instead of a wholesale transition, the Strangler Fig pattern enables the introduction of microservices one at a time. Each new microservice takes on a specific function of the monolith, gradually replacing and augmenting the legacy system.

Like the Strangler Fig tree, One by one migrate without disturbing availability of the system

Another example could be the migration of on-premises databases to Azure SQL Database. Rather than a sudden shift, the Strangler Fig pattern facilitates a step-by-step migration, allowing data to be moved gradually. This ensures data integrity, minimal downtime, and real-time validation, providing a safety net for organizations navigating the complexities of data migration.

The Strangler Fig pattern aligns seamlessly with Azure's capabilities, allowing organizations to harness the scalability, flexibility, and efficiency of the cloud without jeopardizing the stability of their existing systems. As an architect committed to driving successful migrations, I advocate for the Strangler Fig pattern as a proven strategy to achieve a harmonious blend of legacy and modern technologies in the Azure ecosystem.

If you are looking for microservice pattern like Claimcheck & Bulkhead to optimum use of resources and cost when implementing microservices. Look at this article https://azurehelper.blogspot.com/2024/02/architecture-patterns-claimcheck.html

Architecture Patterns - Claimcheck & Bulkhead

 

Claim-Check pattern

Device message into Header-Body > Store body in DB > Send header as event > Subscriber/event receiver will access header > Header points to body/Actual message stored in DB.

A messaging-based architecture at some point must be able to send, receive, and manipulate large messages. Such messages may contain anything, including images (for example, x-ray scans), sound files (for example, call-center calls, video file contents), text documents (for example, Invoices), or any kind of binary data of arbitrary size.

Sending such large messages to the message bus directly is not recommended, because they require more resources and bandwidth to be consumed. Large messages can also slow down the entire solution, because messaging platforms are usually fine-tuned to handle huge quantities of small messages. Also, most messaging platforms have limits on message size, so you may need to work around these limits for large messages.

1. Send message
2. Store message on the data store
3. Enqueue the message's reference
4. Read the message's reference
5. Retrieve the message

Bulkhead pattern

Isolate resources to consume backend services

If a client needs to process 10,000 messages, but clients 2 and 3 only have 200 to process, you cannot afford to let client 1's overload delay clients 2 and 3. Instead, you can divide the microservices using autoload balancers or auto scale to ensure that all clients are served on time.

Note: Bulkhead is not a cost-effective solution but definitely the one if you are looking for the resilient solution. You can always use circuit breakers to check each service instance's performance and load to save the resources and cost.