A large enterprise has a mission-critical application hosted on-premises that uses a proprietary messaging queue system. The enterprise wants to migrate this application to AWS, but a hard dependency on the existing messaging queue makes a direct 'lift-and-shift' impossible without significant downtime. The solutions architect needs to design a strategy that allows for a phased migration, where parts of the application can run in AWS while still communicating with the on-premises messaging queue, minimizing disruption. Which approach should be recommended?
- AImplement AWS Direct Connect between on-premises and AWS, and establish a hybrid messaging solution using AWS MQ with cross-premises connectivity to the on-premises queue.
- BRehost the entire application, including the messaging queue, to Amazon EC2 instances in a single migration wave.
- CRefactor the application to replace the proprietary messaging queue with Amazon SQS and Amazon SNS, then migrate the refactored components.
- DUse AWS Database Migration Service (DMS) to replicate the messaging queue data to Amazon Kinesis, and then migrate application components to use Kinesis.
Show answer & explanationAnswer & explanation
Correct answer: A. Implement AWS Direct Connect between on-premises and AWS, and establish a hybrid messaging solution using AWS MQ with cross-premises connectivity to the on-premises queue.
Establishing AWS Direct Connect provides a low-latency, dedicated connection to AWS. A hybrid messaging solution, potentially using AWS MQ (which supports open-source message brokers like ActiveMQ and RabbitMQ) with cross-premises connectivity, allows AWS components to communicate with the on-premises proprietary queue during a phased migration. This minimizes disruption and avoids a full refactor upfront.
Why the other options are wrong
- B. Rehosting the entire application at once, especially with a hard dependency, risks significant downtime and doesn't allow for phased migration or leveraging cloud-native messaging.
- C. Refactoring to SQS/SNS is a good long-term goal but is a significant architectural change that would be disruptive if done all at once. The requirement is for a phased migration minimizing disruption, which implies not immediately refactoring the core messaging component.
- D. AWS DMS is for databases, not messaging queues. Amazon Kinesis is a streaming data service, not a direct replacement for a traditional messaging queue in a lift-and-shift scenario, and would also require refactoring.
Hybrid Messaging
An architecture where messaging components exist both on-premises and in the cloud, allowing applications in both environments to communicate.
- Enables phased migration of applications.
- Requires robust network connectivity (e.g., Direct Connect).
- Can use message brokers like AWS MQ or self-managed solutions.
Memory trick: Direct Connect bridges, Hybrid MQ speaks both languages.