Moving your infrastructure to AWS
Repurchasing, replatforming, and refactoring your infrastructure to AWS
This article is part of a series about how migrating and modernising your applications with AWS can help you hit your sustainability targets, as well as unlocking a range of business benefits. In this article we’re talking about your options for how you move your applications into AWS; click here to see our articles covering the design phase of a migration project, and how to modernise your applications once they are in the cloud.
If you’ve designed and planned things right, migrating your applications to a public cloud like AWS should be a liberating experience. You get to see your IT estate move into a best-in-class, secure, reliable, and efficient environment, and can start turning off your legacy hardware that’s been costing you money and electricity for so long. But what actually happens during a migration? In this blog, we’ll be looking at the different journeys that most of your applications will take to get into AWS. We’ll also be helping to make everything feel more real by sharing a fictionalised example of a business that’s migrating its estate into AWS.
Three outta seven ain’t bad!
At Claranet, our team actually has seven options for what to do with any given application when planning a migration – the “seven Rs”. However, in this blog we’re only talking about three of them: replatforming, repurchasing, and refactoring. The other four options – retiring, retaining, relocating, and rehosting –won’t deliver your organisation the same modernisation and sustainability benefits that you’d get from repurchasing, replatforming, or refactoring, so we’re choosing to focus on those three. You can see our previous blog in the series for a definition of the other four Rs.
So, what’s involved in the three Rs that we are interested in?
Replatforming: moving to PaaS in AWS
AWS provides a lot of PaaS services that you can take advantage of, which are guaranteed to be modern and green because AWS is the one running them. Examples of these include AWS Relational Database, or Amazon DynamoDB for NoSQL databases. Moving an application as-is from a virtual machine running on your servers to a container running in AWS is also a type of replatforming.
Replatforming keeps much of your application as-is, meaning that you won’t get the very best benefits of modernisation and sustainability. However, much of the heavy lifting, including backups, replication, automatic failover between regions, version upgrades, and so forth. And of course, you still get the benefits of performance, scalability, fault tolerance, availability, and energy efficiency that come from moving elements of your infrastructure to the cloud.
Typically, replatforming is best for applications that aren’t of vital strategic importance, or where there isn’t budget to investigate repurchasing or refactoring, but where there is still an opportunity to enjoy the benefits of cloud architecture.
Repurchasing: moving to a pre-built service
Repurchasing involves replacing your existing application with a service provided by a partner that runs their own solution on AWS. A good example would be replacing an existing ticketing system with ServiceNow.
Repurchasing is ideal for applications which:
- Are of strategic value to the business; for instance, they are revenue-generating or vital to your operation.
- Are based on legacy code or architecture, and so would be complex to move to the cloud without significant work.
- A supplier can provide for you, quicker or to a higher standard (or both) than you could manage yourself.
Repurchasing can give you a much more modern application instantly, with the security of knowing it will work with your new AWS estate. AWS runs a large marketplace of service providers who you can easily start working with – and because they are also running on AWS, you can be confident that using their services won’t inadvertently grow your carbon footprint again.
Refactoring: rebuilding your application in the cloud
If there isn’t a supplier who you can or want to repurchase your application from, then the gold standard is to rebuild your application to take advantage of AWS’ cloud-native capabilities. Refactoring can be as simple as using a service like Apps2Container to containerise your applications as they are, or involve a complete overhaul of the code and the way the app works.
Refactoring gives you the best opportunity to modernise and boost the sustainability of your apps. In addition to the benefits of AWS’ supporting infrastructure that you get from a replatforming exercise, your app can use cloud-native features to behave in new ways, including using serverless compute. If you’re considering refactoring, then it’s absolutely essential that you find and use expertise in the technologies involved, such as Fargate and Lambda.
What does this look like in the real world?
Just as the cloud needs physical hardware in order to function, the concepts and ideas we’re talking about need a basis in reality. And that brings us to Charlie Loud Migrations Ltd, a slightly-made-up-yet-incredibly-realistic business specialising in the tracking of migratory animals. Its cloud migration journey with Claranet shows you what migrating to AWS can look like in the real world.
In our last blog, CLM migrations had successfully designed and planned its migration. Now, we’ll go through the migration itself…
Charlie Loud, CTO and Founder of C. Loud Migrations, decides with their team to prioritise the migration of the business’ custom software application. Their rationale is that the servers hosting the application are the costliest and least efficient in the business, so the sooner the apps are migrated, the sooner they can turn the servers off to improve their carbon footprint.
The Cloud Centre of Excellence (CCOE), which includes experts from across CLM and Claranet, reviews the application and decides that due to its criticality and its custom nature, that refactoring the application is the right way to go. By refactoring, they hope to decouple the application’s various functions and rebuild it using a microservices architecture. Some of the elements of the application could benefit from serverless compute via AWS Lambda as they aren’t running 24/7 – their role is to execute specific workflows by making calls to other services, which are triggered whenever the business receives data from trackers mounted to migrating animals. A serverless approach will mean that the application only uses resources – and therefore generates emissions – when it is needed, greatly reducing the cost and carbon footprint of the application. Due to the complexity of this activity, as a first step the application is rehosted on EC2, with the plan being to come back and refactor it once the initial migration work is completed.
CLM reviews its database containing all the data gathered from the IoT devices tracking animals. Because it’s a NoSQL database, the team decides that the best option is to replatform the database to use Amazon DynamoDB. AWS takes care of all the heavy lifting including backups and failover, and the team can rest easy knowing that as the volume of data they gather grows, AWS can scale to match without incurring the same carbon footprint that CLM would generate.
Some of its applications, including its expenses management application, CLM decides to repurchase from a partner of Claranet’s, SAP Concur. Because SAP Concur also runs on AWS, compatibility with the new infrastructure is guaranteed, and CLM knows that SAP Concur’s green credentials match its own.
For a number of its other applications, C.Loud Migrations decides to use Apps2Container to move the apps from its existing VMs to containers running in AWS Fargate. The team reasons that they could further refactor these apps, or repurchase in the future to make them even more efficient and use less energy, but the effort to do so during the initial migration would outweigh the benefits.
What’s next?
In our third article, we’ll talk about how you go about modernising your applications once you’re migrated to AWS. If this article has inspired you to think about whether your applications could be replatformed, repurchased, or refactored, I’d love to talk things through with you and help you choose what to do with each application based on our experiences here at Claranet.