Comic Relief changed their infrastructure-centric AWS bill from £83k per month to £5k per month.
Their 16x cost reduction was achieved by refactoring their application to exploit the cloud. But not everyone is refactoring their applications.
Rehost is the most common cloud migration strategy (40%) of the 6Rs. Also known as Lift-and-Shift, is a bottom-up infrastructure-centric migration approach:
- To Rehost you have to replicate the infrastructure topology from non-cloud on-premises to the cloud (networks, security, storage, compute). Then you black-box migrate an application to its new home (usually copying a virtual machine and a dump of the database from on-premises to cloud).
- Rehost is like kicking the cloud can down the road because you still have work to do on your application to help it exploit the cloud.
- Rehosted workloads can benefit from some cost optimizations such as forward-contract purchasing of cloud resources (Reserved Instances), that is a welcome optimization and can chop 20-30% off your bill. Surprisingly, many companies don’t achieve this and still pay the full-price on-demand cost of cloud.
- Rehost = minimum change = minimum cloud value.
You will never achieve the same savings as Comic Relief by rehosting your applications to the cloud. A 16x magnitude of savings is only possible by refactoring your application.
In this post, we compare and contrast Rehost with Refactor and describe how Green Rain by Fedr8 can help you get the best of both worlds.
The benefits and drawbacks of Rehost
The benefit of Rehost is its simplicity.
It requires only an infrastructure-centric understanding of the applications and data. Because the application isn’t changing, it is perceived as getting to the cloud by the fastest, cheapest path. Rehost is popular for mass-migration “factories”, especially where there is a deadline priority (e.g. datacenter end-of-contract/life is coming up).
The drawbacks of Rehost are four-fold:
- You are migrating all the technical debt and non-cloud practices (e.g. scripts, tools) into the cloud.
- You are not optimizing for the cloud which means that massive-sized and under-used on-premises VM is replicated to the cloud. Yes, you can optimize, but often this isn’t done because people are scared to make changes during migration.
- You are not leveraging cloud-managed services. For example, you still run your own database or load balancer instead of letting the Cloud Service Provider take the strain.
- You still have work to do when you arrive. Because you haven’t doing (2) and (3) above, then you have more work to do to become “cloudified”.
All of these drawbacks incur cost penalties.
Vendors like VMware recommend the Rehost approach because you need their software to make the cloud look like on-premises, and vice-versa. If you were doing Rehost from a VMware-dominated on-premises datacenter, then it’s tempting to migrate to VMware-on-AWS in the cloud to minimize changes, though there are higher costs to consider for this “ease of migration”.
Application-centric refactor
Refactor means modifying your application to use cloud services.
Evolving your application to a different architecture — for example, more microservices than monolith. There are new approaches to cloud applications called serverless. Refactoring can take considerable effort but the results can be fantastic, as Comic Relief found.
Benefits and drawbacks of Refactor
Refactor means fully harnessing the power of the cloud.
The goal is to make your application cloud-native. It is impossible to be cloud-native without being application-centric. If you don’t understand your application, if you can’t modify it, you can never be cloud-native.
The drawback to refactoring is that you need the skills, effort and resource to evolve your application.
How Green Rain supports Rehost and Refactor migrations
Bottom-up, infrastructure-centric cloud migration tools will analyze your infrastructure, help you configure and size the target cloud, and migrate your applications, data and databases to the cloud. But they do not understand your application code.
This is a migration blind spot, because:
- You may be using session management that doesn’t work well in the cloud. In the cloud you need to use distributed session management.
- You may be using just one SQL database but in the cloud you could use several types to suit the application (there are seven types of database in AWS).
- You may be writing logs to local disk and saving state locally, which is an anti-pattern in cloud infrastructure where immutable and ephemeral servers scale out and in on-demand.
Know Your Application with Green Rain
If you want to refactor your application then you need to understand the code and what might break or what can be optimised for the cloud.
To Know Your Application means you need the application developer and maintainer to be available to contribute. Are they still employed? Is the documentation up to date? Do your talented software engineers want to work on a tedious cloud migration project or the latest cool whizbang widget?
Green Rain brings clarity to this blind spot by using a deep-learning engine to analyse your code repository and give you signposts about where you need to spend time refactoring.
The intelligent software inside Green Rain presents its findings through a user-friendly interface and tells you what dependencies are found and why they might break in a migration.
You can use Green Rain before and after Rehost and Refactor migrations to give you insights into your code and it’s dependencies on technologies that need to be addressed.
Next Steps
Learn more about Green Rain by Fedr8.
Talk to a Green Rain expert today and get a demo of what it can do for application-centric migrations. Your Green Rain expert can also arrange a trial on your applications on your premises to your cloud of choice.