Cloud Application Migration—It’s the Network, Stupid
Companies are increasingly turning to SaaS and IaaS vendors to manage their applications and infrastructure; cloud storage is the fastest growing segment behind SaaS. Many service providers are looking for solutions to facilitate customer on-boarding, but customers are looking for ways to minimize vendor lock-in. Why have these services been so slow to mature?
Clearly the functionality is much needed as more workloads are migrating or being built directly in the cloud. Organizations need to be able to move workloads across and between remote data centers and disparate virtual infrastructures. Direct uses for this functionality include disaster recovery, high availability, and the ability to migrate applications between different cloud service providers.
The problem in a nutshell is how to build an application migration service that allows live migrations of active virtual machines (VMs) from one data center to another over a WAN network link. Any migration technology must address not only any changes in the IP addressing and routing information of the live systems on the fly—typically what load balancers are designed to do—but also the more significant constraints of available network bandwidth limitations.
Another issue that needs to be addressed is the lack of interoperability between the disparate hypervisors, cloud platforms, and storage systems. That is, the difficulty of transferring workloads is more related to being locked in to the specific underlying hypervisor and hardware than operating system portability. Isn’t this just the problem that cloud abstraction was supposed to solve?
Workload migration can be approached at a number of different levels of the IT stack. Traditionally, live migration has been done through shared infrastructure and storage. It is a trivial exercise to migrate a VM on shared storage, but there are also plenty of layer three architectures that allow migration over the WAN at the operating system or application levels. The advantage of taking this approach is that it minimizes the problem of hardware dependencies, but it does require the software and images to be compatible across the source and target platforms.
There are already a number of commercial products on the market that address this issue at the operating system or application level. Rivermeadow Software offers a SaaS-based migration service where users pay for migrations by the workload, where a workload is defined as a single virtual machine. Racemi Technology and NetIQ (formerly Platespin) have similar product offerings. All the commercial products—whatever their relative merits and touted features—allow migrations not only over the Internet but also across disparate cloud architectures and hypervisors.
There is clearly a need for migration software, but it is a niche market. Companies that have a significant technological head start and a more sophisticated understanding of the issues are making this functionality work. In the future, more cloud service providers will want to incorporate these features to smooth the on-boarding process and expand their disaster recovery and high availability capabilities—something that cloud services have been weak at for a long time.
