End of life data center migration
The course is part of these learning paths
This course is a "live" scenario discussion where the Cloud Academy team tackle a migration project. Our customer needs to migrate out of their current data center by a certain date. They also would like to modernize their business applications.
Our brief in the exercise is to deliver:
- A target architecture that addresses the challenges described by the customer
- A migration plan detailing how to move the service to AWS with minimal interruption
- A recommendation on how to approach DR to achieve RPO of 24 hours and RTO of 4 hours
- An application optimization plan with a proposed enhancement roadmap
As a scenario, this series of lectures is recorded "live" and so is less structured than other Cloud Academy courses. As a cloud professional you often have to think and design quickly, so we have recorded some of the content this way to best emulate the type of conditions you might experience in the working environment. Watching the team approach this brief can help you define your own approaches and style to problem-solving.
This course discusses AWS services so it is best suited to students with some prior knowledge of AWS services.
We recommend completing the Fundamentals of AWS learning path before beginning this course.
If you have thoughts or suggestions for this course, please contact Cloud Academy at firstname.lastname@example.org.
22-01-2020: Duplicate lecture removed
- [Instructor] So let's do a structured walkthrough and to review the components of these stages. So our Quick Wins shifting storage of the data center into Amazon S3 migrating our app and the IPS/IDS service to EC2 instances migrating our Oracle database to Oracle RDS At Optimization stage is where we can reduce load on the web tier by implementing Elasticache and looking to reduce costs by shifting from Oracle to Amazon Aurora or Amazon PostGres. So I think our approach will be best delivered in three stages. First, Lift and Shift. And that's going to be the Quick Wins which results in minimal impact on the business. In stage two, we look to optimize and we're moving as many services and starting to use as many managed services as possible. And stage three is our transformation stage, where we're looking to re-engineer our core application because that's the only way we're gonna get this business more agility. Okay let's just look at our stages in the time boxes and what we call swim lanes. So for stage one, we're gonna use the single region VPC. We'll use VPN for connection back to the data center. For our data modules and storage, we'll use Amazon S3. It's the most cheap and reliable way of getting out of the data center quickly. We can use our Snobble to ship 80 terabytes at a time to get out a 160 terabytes shipped. And then use sync to just keep objects in sync. We can look to use Elastic files to replace secure FTP. And optimization, we can look to shift objects to reduce redundancy storage. And in stage three, we can look at it to rewrite ingestion to use the API gateway. For our core application in stage one, we just wanna lift and shift it. Maybe look to rewrite a Apache to remap URLs on the fly so we don't create any outage or issues for people using the system. In our optimization stage, we can look to use a Lambda function to map Elastic IP addresses to any of our order scale baston hosts or hosts. And then in our transformation stage, you're really looking to re-engineer their microservices using API gateway, AWS Lambda, getting rid of the Apache layer altogether and then using Elastic load balancer with paths, perhaps, to direct dynamic requests back via Elastic Beanstalk. In our connectivity state, VPN initially, and then we'll look at using DirectConnect + VPN. For our Data Access Tier, look at using Data Migration Service to shift our Oracle database's scheme or database and schemer to Oracle RDS. And then in our optimization phase, we look to use the data migration service to migrate off Oracle to Aurora or PostGres. For encryption in stage one, we'll just use CloudHSM which is a rented appliance but it does allow us to just shift the keys directly from the data center into AWS. And then, during our optimization or transformation stage, we'll look to shift the keys to use the KMS service. In security, we'll implement our IPS/IDS service using EC2 instances which we'll get from the marketplace. And long term we could look to rewrite that to use either a manged service or something that's perhaps a little bit easier to maintain. For our registration modules we really wanna rewrite those in our transformation phase to use DynamoDB. And we'll have modules with logic managed by Elastic Beanstalk. The payment gateway, again, is a transformation stage. So we can use DynamoDB with microservices using API gateway behind that. In our presentation layer, looking to optimize by implementing Elasticache. Probably Elasticache redis to reduce the load on their web tier. And then we can look to use microservices in a DynamoDB approach behind API gateway for offloading some of that traffic to the web service. Now the document manager and batch processing, we look to merge into one document processing service. Probably on DynamoDB and with a microservice approach managed by Elastic Beanstalk. Now in terms of time boxing these three swim lanes, for stage one, you know, we have a hard stop so we need to have or be out of the data center within six months basically. So we need to give ourselves a five month timeline for that. We've got one month either side of that hard stop to ensure that we've got everything in place. Now for stage two, within nine months we should be able to optimize the solution to provide better cost efficiency and ideally a better service. But then looking to that stage three transformation, we're gonna need 18 months to do this correctly. There's a lot of rewriting involved. We've only got one internal developer so both resources and the cost will be the constraints of this. So we're going to need to have the business understand what's required to support this project which is gonna come back to cost. So that's the plan we'll pitch back to the customer. So we have fixed the immediate problem and then we've got a road map for how we can give the business more agility. Yeah, let's take this to the executive and get a top down sign off.
Head of Content
Andrew is an AWS certified professional who is passionate about helping others learn how to use and gain benefit from AWS technologies. Andrew has worked for AWS and for AWS technology partners Ooyala and Adobe. His favorite Amazon leadership principle is "Customer Obsession" as everything AWS starts with the customer. Passions around work are cycling and surfing, and having a laugh about the lessons learnt trying to launch two daughters and a few start ups.