We at The Virtualization Practice, LLC have migrated our business critical applications to the cloud. How simple was that task? It was not as easy as we have heard from others, and not as difficult as some have had, but it was not as simple as move my VM and run. Why is this? What are the methods available to move to the cloud? How do they stack up to what actually happens. Theory is all well and good, and I have read plenty of those architectures, but when the shoe leather hits the cloud where are we? Here is a short history, a comparison of methods, and some conclusions that can be drawn from our migration to the cloud.
The Virtualization Practice is a small to medium size enterprise with systems that must stay running 24/7. We look at our data center as a part of our business. We use that data center not only to run our business critical applications, but we also run various other systems as a test lab.
Migrating Business Critical Applications
While we do not have many mission cricical systems, the ones we do have are extremely crucial. We considered the following ways of migrating to the cloud:
- As part of Disaster Recovery planning, unfortunately when we spoke to some cloud vendors they were not able to satisfy our need using our existing tools. For some, if we switched to Zerto we could do this. Others, they supported esoteric backup solutions that I had never heard of in context of 100% virtual environments. The ones that claim to have Veeam support, really did not have effective support, they were just a repository with no means to run the workloads or are not ready for usage. Due to these limitations, this option was closed to us, however, I still think it is the best option if you have the time to put it together. Our problem, was we had a shrinking time schedule based on outside influences that required us to attempt to use what we have.
- As part of vCloud Director or Connector, unfortunately we did not have our virtual machines within a vCloud yet, they were just a standard 100% virtual environment running vSphere. While we could have migrated our data via convert to OVA, import, etc. from our backups, we did not find a vCloud vendor that was priced properly. This is one of the more expensive options and would require us to setup vCloud Connector, migrate our VMs into vCloud to use effectively. Since we did not have this setup yet, we had to go with what we had.
- Setup brand new VMs and migrate over the applications and data. This option was initially unappealing because of the work involved, the lack of automation, and the lack of scripts to setup our applications on the other side. However, this option would allow you to setup the workloads and run them side-by-side until the final cut over date. However, while we went this route, requires intimate knowledge of your data, what data is changing, what data is static, what data is critical to move and the mechanisms to move the data. All these need to be known before you head down this path. What made this path attractive, was the recent update we did of our business critical email services. We had the techniques, used them recently and it all worked as expected. Experience won out, but we did not script everything previously.
The last option is for a small amount of systems. As John Troyer stated on a VMware Communities Round Table, (paraphrased) the lack of automation will hamper any movement to the cloud (or if you are not automating the deployment of your workloads, something is wrong). He is correct, in order to migrate workloads you should use some form of automation. In this case, we did not have any automation, but we built the automation script as a part of our deployment to the cloud.
Closing Thoughts
We need more automation to migrate workloads. To migrate workloads without importing or migrating virtual machines, you need to understand all aspects of your data. You need to understand your applications and all the intricacies and practice helps! Run the machines side by side and make sure things work until you are ready to push the big read button. The big red button in most cases will end up being your DNS services and not the start of the virtual machines or workloads. When you run your workloads side by side you gain the ability to not only test everything but for certain applications you know what things SHOULD be and can compare them to what you have. But when you switch over DNS, you also have to consider those sites that do not get your updates and ensure your systems run side by side until all parts of the internet have picked up your changes, which hopefully is less than 24 hours. Which means, you have to do one last data migration of what is critical just before you turn off the old servers and services.
Do you know how to migrate your applications and data? Have you automated those tasks yet? When virtualizing business critical applications and migrating them to the cloud, this is important information.