You may or may not be aware that I have just moved house, and, me being me, I have not done it by halves. My family and I up’d sticks to the other side of the world, and we landed in Perth—not Scotland, but Australia. Call it a cross-cloud migration; this obviously was fraught with difficulties and did not go as smoothly as planned. This has got me thinking about moving home in a cloud environment, whether from site to site, region to region, or cloud provider to cloud provider. In a perfect world, this should be as simple as live migration is today between like-minded virtualization hosts: VMware to VMware, Hyper-V to Hyper-V. The unfortunate truth is that this is not the case.
Recent outages with AWS have once again demonstrated the limitations of a single-vendor cloud solution. What you may consider a failure domain probably isn’t one to your cloud provider. In the UK, with the imminent declaration of Article 50, the divorce from the European Union commences, and the sovereignty implications will be a major issue for data storage. Currently, AWS has three regions in Europe: London, Frankfurt, and Ireland. In two years’ time, London will no longer be in Europe, and although EU member country businesses will be able to utilize Ireland and Frankfurt for resilience, the UK will not, as it has only a single AWS region. Azure users are in a slightly better position, as Azure has two regions in the UK: one in London and another in Cardiff. Google Compute Engine users do not even currently have the option of a UK-based region or zone, although Google does have expansion plans in process. Finally, the new kid on campus, Oracle Cloud Services, has a site in Slough, UK, and one planned in London.
Now, given that it is considered good practice to have at least three separate copies of your data for resilience, there will be no single major cloud provider that can meet this requirement with any assurance completely within the UK by building out to a public cloud deployment, as would be required for data sovereignty compliance post-Brexit. Azure and possibly Oracle may be able to do so by building out a hybrid cloud deployment. The time for architects to be looking at cross-cloud deployments has arrived, if not passed.
I believe that a cross-cloud solution for public or hybrid deployments is simply good practice. However, these deployments are fraught with issues, notwithstanding virtual machine formats across VMware, Xen, Hyper-V, and QEMU-based cloud formats. Differing networking models, storage models, similar-but-not-the-same cloud services, and cost models all add to the pain that a potential business analyst and IT architect will have to suffer when designing and deploying this kind of environment.
Multicloud and cross-cloud deployment are similar in concept to a hybrid deployment, but they may or may not involve a local on-site private cloud deployment as part of their environment. A lot of the questions that need to be answered in deploying a hybrid cloud also need to be answered when looking at a multicloud deployment. This is why I like the approach of VMware, with its cross-cloud initiative. Its partnership with AWS to provide the ability to deploy VMware clouds on bare-metal AWS servers is a straightforward way of architecting a cross-cloud environment without incurring the problems alluded to above. This solution could offer that ability to provide three separate data locations in the UK post-Brexit. Currently, the concept is, on the whole, vapourware, but the ability to migrate running workloads across was demo’d at VMworld in 2016 (this was to VMware on AWS, so was a standard vMotion event). However, there is the need to migrate native VMware-based virtual machines to Hyper-V, Xen, or any other format. In fact, this needs to be done seamlessly and at speed across all formats in either direction.
The technology for machine format migration exists in VM conversion software, but not without a service disruption. Detailed scripting and automation processes can minimize the outage, but there is still a period when the source machine needs to be switched off before the target machine is powered on. Another issue with the majority of mainstream conversion software is that it migrates data from any format to a vendor-proprietary format, and not the other way. To date, cross-format methods of moving machines have been clunky in the extreme. OVF and OVA formats come to mind.
These improvements are coming, but obviously not from the vendors that have a vested interest in making migration to their format easy, but migration out of their format hard. VMware is at a tipping point: it was the harbinger of the cloud age, but lost focus on the new infrastructure paradigm by attempting to shore up its now-legacy ESX cash cow, which allowed AWS and Azure to dominate the public cloud environment. VMware has the majority technology available in its stack already, NSX to provide the networking between disparate clouds, VMware-integrated OpenStack to interface with other OpenStack deployments, and cross-platform automation capabilities. With its partnership with Blue Medora, VMware Operations Manager is fast becoming a very versatile cross-platform management platform. Its new investment, PowerCLI—a powerful scripting language that, due to the new openness, is being displayed within Microsoft post the Nadela investiture—is now available for both Windows and Linux workload automation. VMware is once again at the forefront of a new paradigm. If it grasps this nettle with both hands and develops and deploys the necessary tools to enable seamless cross-version live migration, it can capture this market and perhaps recapture the glory of the early naughties.
Share this Article:
Latest posts by Tom Howarth (see all)
- Has VMware Effectively Killed the VCDX Program? - April 18, 2017
- VMware rolls back its borders with a flash sale of vCloud Air - April 11, 2017
- VMware Ends Support for 3rd Party Virtual Switches - April 6, 2017