From Monolith to Microservices in AWS: Patterns for Seamless Migration
Inspired by Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith, this example explains about Monolith to Microservices in AWS.
Strangler Fig Application
The Strangler Fig Application pattern enables you to migrate functionality incrementally to microservices without requiring disruptive changes to your existing application.
Instead of rewriting the entire monolith in one go, you gradually create new microservices around the existing system. Over time, these services take over the monolith’s responsibilities, allowing for its eventual decommission.
Implementing with AWS ALB
Using an Application Load Balancer (ALB), you can route requests to either the monolith or new microservices. ALB’s path-based routing feature facilitates this routing.
Implementing with SQS
For message processing applications, AWS Lambda can analyze message contents and then enqueue them for processing by the monolith or microservices via SQS.
Parallel Run
The Parallel Run pattern allows you to call both the monolith and microservices simultaneously and store their results separately.
This approach is especially useful for high-risk migrations or major system changes, as it provides a safety net to compare outputs before making the final transition.
Change Data Capture (CDC)
The Change Data Capture (CDC) pattern is another migration strategy, though it comes with significant challenges. As noted by the book’s author:
In general, I try to keep the use of this pattern to a minimum because of the challenges around some of the implementations of this pattern.
AWS supports the CDC pattern via Database Migration Service (DMS) and DynamoDB Streams.
This pattern enables you to reactively handle data changes in source databases, making it ideal for synchronizing data during migration.
