A global logistics company is migrating its highly coupled, monolithic freight management application to AWS. The application processes millions of real-time shipment updates, generates complex reports, and has stringent uptime requirements (99.99%). The company wants to break down the monolith into microservices over time, but needs to first establish a robust, highly available, and scalable environment in AWS. They also require a mechanism to ensure transactional consistency across distributed services during the refactoring process. Which design approach should the Solutions Architect recommend to facilitate this transition?
- ARe-host the monolith to a single large EC2 instance and use Elastic Load Balancing for high availability.
- BRe-platform the application by migrating the database to Amazon Aurora Serverless and containerizing the monolith into Amazon ECS.
- CUse AWS Step Functions to orchestrate the entire monolithic application's business logic as a series of serverless functions.
- DImplement the Strangler Fig Pattern by incrementally extracting services and using a messaging queue (e.g., Amazon SQS) for inter-service communication and eventual consistency.
Show answer & explanationAnswer & explanation
Correct answer: D. Implement the Strangler Fig Pattern by incrementally extracting services and using a messaging queue (e.g., Amazon SQS) for inter-service communication and eventual consistency.
The Strangler Fig Pattern enables gradual refactoring of a monolith by incrementally replacing functionalities with new services. Using a messaging queue like Amazon SQS provides asynchronous communication, buffering, and helps achieve eventual consistency across distributed services, which is crucial during the transition to microservices from a monolithic application with high transactional volume.
Why the other options are wrong
- A. Re-hosting to a single large EC2 instance does not address the need for microservices, gradual refactoring, or transactional consistency across distributed services.
- B. Re-platforming to Aurora Serverless and ECS is a good step, but it doesn't inherently solve the problem of breaking down the monolith or ensuring transactional consistency across newly separated services without an architectural pattern like Strangler Fig.
- C. Orchestrating an entire monolithic application's business logic with Step Functions would be a complete re-architecture, not a gradual transition, and might not be suitable for real-time, high-transaction loads without significant redesign.
Strangler Fig Pattern with Messaging
The Strangler Fig Pattern facilitates gradual migration from a monolithic application to microservices by incrementally replacing components. Integrating messaging queues (like Amazon SQS) enables asynchronous communication between the old and new services, helping manage eventual consistency and decoupling during the transition.
- Gradual, low-risk refactoring of monoliths
- Messaging queues (SQS) enable asynchronous communication
- Helps achieve eventual consistency in distributed systems
- Allows for concurrent operation of old and new components
Memory trick: Strangler Fig + SQS: Smoothly break apart the monolith.