From Monolith to Microservices in AWS: Three Migration Patterns

Inspired by Monolith to Microservices, this example explains monolith-to-microservices patterns on AWS.

Takahiro Iwasa

2024-01-28

3 min read

Inspired by Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith, this article maps three monolith-to-microservices migration patterns to AWS services.

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.

Strangler Fig with ALB

Implementing with SQS

For message-driven applications, a Lambda function can inspect each message and send it to an SQS queue consumed by either the monolith or a new microservice.

Strangler Fig with 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.

Parallel Run Pattern

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 lets you respond to changes in the source data and keep systems synchronized while both operate during a migration.

Change Data Capture Pattern

Conclusion

Mapping Strangler Fig, Parallel Run, and Change Data Capture onto AWS services showed how each pattern covers a different piece of a monolith-to-microservices migration.

These three patterns address different phases of the same migration rather than competing with each other: Strangler Fig handles the routing problem of gradually shifting traffic away from the monolith using ALB path-based routing or SQS, Parallel Run addresses the trust problem of verifying a new service’s output before cutting over, and CDC addresses the data problem of keeping both sides consistent while they coexist.

The author’s own caution about CDC is worth taking seriously — of the three, it’s the one where the implementation details tend to surface the most operational surprises, so it’s worth reaching for DMS or DynamoDB Streams only after the simpler patterns have proven insufficient on their own.

Back to posts