When one hears the term ‘cloud migration’, most people tend to think it means moving their on-premise server workloads wholesale to public clouds – like Azure and AWS. It can be that, but there should be a more encompassing strategy. For example, If you have VMware, Hyper-V, and OpenStack and use a Cloud Management Platform like CloudController to orchestrate your deployments, you can create a de facto hybrid cloud – giving you the best that public clouds and on-premise infrastructure have to offer in a unified operations platform.
Admittedly, all of this can be very confusing. So to help you get a better grip of the possibilities, let’s compare the traditional or pre-cloud-native ‘lift-and-shift’ migrations to the new migration strategies that we currently see in the market.
Pre-Cloud-Native Migration
Let’s say you want to migrate a workload from your on-premise private cloud to a hyperscale public cloud. You first need to move away from your virtual machine, which is a representation of your infrastructure. But as it’s structurally tied to and dependent upon the hypervisor virtual machine disk (.vmdk) or virtual hard disk (.vhd) file, you can’t just “unplug” these from the hypervisor, plug them into a public cloud and expect them to seamlessly work. There are other intricacies to consider, such as network functions and connections, application-specific middleware and drivers, etc.
In the era before cloud-native deployments, on-premise you could already move Open Virtualization Format (OVF) files from one virtualization platform to another – and there were/are several great software tools to assist with this type of migration. To move, from say, VMware to Hyper-V, you have to convert the .vmdk files to .vhd files. Getting them to work in a public cloud is another challenge – even though they are also .vhd files. These actions performed what the industry calls a “lift and shift” migration approach. This involves the virtual machine being unmounted from its hypervisor-based home and mounted elsewhere – which is a very complex undertaking and technically challenging.
And while virtual machines sit on top of virtualized physical computer hardware as a manageable instance, cloud-native deployments work differently. One of the pillars of the cloud-native methodology is application containerization. Containers virtualize the operating system kernel of your application workload and put it into an entity (container) that also ‘contains’ other software required by your application to function properly, like middleware, drivers, etc. That means it doesn’t matter where it’s running – on-premise, or in a public cloud, on VMware, OpenStack, AWS, Azure, or GCP, etc. The hypervisor (.vmdk or .vhd) is no longer leading, the container is. The [virtualized] infrastructure is a given – it’s just a landing place to mount the container. It’s a bit off-topic, but that is what Kubernetes does for you! Kubernetes creates and manages that standard software interface to mount the container on virtualized infrastructure so it can run!. With cloud-native, you’re moving the containerized application instead of the entire virtual machine like you would with ‘lift-and-shift’.
Cloud-Native Ease
Thankfully, cloud-native makes migration a lot easier. For example, if a company has server platform workloads in a private cloud and/or various public clouds and wants the flexibility to run them in a multi-cloud environment, or to consolidate them, certain workloads need to be migrated. But rather than focusing on infrastructure, the container becomes much easier to migrate than the complete virtual machine.
Every cloud has measurable performance characteristics, like network latency, speed of memory access, and how it is set up etc. This metadata can and will play a role in how you manage workloads in hybrid and multi-clouds. That’s why it’s important to monitor cloud parameters.
Say you have an application running on-premise in VMware and one monitored parameter goes out of range with your set critical zone for proper functionality of that application. You want the ability to migrate that application to a place – a “landing zone” in your hybrid/multi-cloud where it will run properly, without performance degradation. To do that, you need to know all the resource providers’ performance dynamics and parameters in your cloud.
With cloud-native, this is easier to do – compared to other methodologies.
Your Most Valuable Asset
Here at InContinuum, we have some interesting new developments coming in 2021 related to migration orchestration – that is orchestrating the migration, whether user-initiated or automatically based upon policies. There are many companies in the industry that have great migration tools. Our migration orchestration module will not compete with these at all. On the contrary we partner with these firms because we add value for cloud admins and users who need to assure migrations can happen when they need to. Our value add is our policy engine-based migration orchestrator that will help them assure their applications always run in a resource location that has the performance criteria required – using their migration tool of choice.
A company’s most valuable asset is its data. As applications generate and process data, it’s vital to ensure that the infrastructure supports the data’s specific use. Like a car that needs four wheels to drive: it doesn’t necessarily matter which brand the tires are, as long as they fit the car and roll. The same is true for application workloads – it doesn’t matter what infrastructure is used, as long as it meets the right performance criteria.
This is why ensuring you have the right migration strategy – and the right tools to move your workloads – is vital. But without a clear understanding of the issues involved, not getting it right the first time could well be a more expensive and time-consuming undertaking.
Contact us today to see how we can help you orchestrate and future-proof your cloud infrastructure.