Monolith to Microservices in AWS - Splitting Monolith Patterns
I really enjoyed Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith about three years ago. This book shows you pros and cons of monolith and microservices and it was good impression not to treat microservices as a silver bullet.
In this post, let me describe how to adopt within AWS a part of the patterns described in the book.
Strangler Fig Application
Strangler Fig Application pattern allows you to move functionality step by step to your new microservices without having to make any changes to your existing applications.
Using ALB
Once you have completed migration, requests can be redirected to the new microservices using Application Load Balancer.
If you want to redirect only specific routes, you can use path-based routing.
docs.aws.amazon.com
You can use path conditions to define rules that route requests based on the URL in the request (also known as path-based routing).
Using SQS
If you have message processing applications, you can have lambda analyze message contents and queue them to process by either monolith or microservices.
Parallel Run
Parallel Run pattern allows you to call both monolith and microservices and store the results respectively. This approach is useful when the migration has big changes and risks to your application, enabling comparison of the results later.
Change Data Capture
Change Data Capture pattern is not recommended by the book author, saying the following:
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.
Although I strongly agree with that opinion, AWS offers the CDC feature with Database Migration Service.
docs.aws.amazon.com
You can create an AWS DMS task that captures ongoing changes from the source data store.
Using the CDC pattern, we can reactively deal with data changes made in source datastores.
