Three hurdles of data portability with multiple cloud providers

IntroMigrating applications is not a trivial process. Whether you want to move apps from on-premises infrastructure to the cloud or distribute them across multiple cloud providers, you'll face obstacles. Moving virtual machines, migrating data and configuring networks can all create friction in the app migration process. Moving virtual machines. You have several options when migrating virtual machines (VMs) between an on-premises infrastructure and the cloud: using a shared machine image format, importing or rebuilding. The simplest option for migrating VM images is to have a shared image format across all platforms. When choosing a cloud provider, IT admins will likely weigh several factors above their existing VM image file format, so finding a common format requires some planning and a little luck. Some cloud providers import virtual machines as a service by importing a VM image built for a different virtualization platform. Amazon Web Services (AWS), for example, has an import service specific to VMware-based VM images. The service imports VMware ESX VMDK, Citrix Xen Virtual Hard Disk (VHD) and Microsoft Hyper-V VHD images. VM images can be exported to those formats as well as to VMware ESX OVA. Rebuilding virtual machine images is an option, but it requires the use of configuration tools like Puppet and Chef. To do this, you need to specify scripts to generate VM images and run those scripts in your target platform. Configuration scripts allow you to easily and frequently rebuild VM images so you always have the latest versions of software components. It's imperative, however, not to make any mistakes during the application-build process; an updated version of a software component won't be compatible with another component. Migrating data among clouds. Migrating data from one cloud platform to another can be a substantial challenge. The first step is to assess your existing data storage configurations and filter out which data will move to the cloud. Consider, among other things, read/write loads, the amount of data you would potentially move and network latency. Relational databases are typically used in a client-server structure, with client applications reading from and writing to a database on another server. You have the option to migrate both clients and servers together or move only one of the components. Which approach is better will depend on a number of factors. Consider a case in which you have a compute-intensive application that writes data to the database at the end of a complex calculation. Assume that minimal reads are performed on the database. The application and database are currently running on-premises, but you have a spike in workload. In this case, it makes sense to move the compute load to the cloud but leave the database on-premises. Because the application reads and writes only a small amount of data, the database can remain on-premises without degrading performance; network charges that users accrue for transferring data into or out of the cloud for this scenario will be negligible. But let's assume the application is database-read intensive. Network latency between an on-premises database and a cloud-based application could degrade performance. In this case, it makes sense to migrate the entire database to the cloud, assuming the application will run for an extended period of time. Configuring networks for cloud. You'll have to address a number of network configuration issues when migrating applications to and from the cloud. The most obvious issue surrounds the use of domain name services (DNS) that address servers. In these instances, you'll need to update records. Less-apparent network issues are internal configurations. For example, if you use load balancers to distribute application workloads, you need to update those load balancers to use servers in the new location. Other applications, such as database clients, may need to be reconfigured and will need to address a new database server IP address. When shifting applications between on-premises infrastructure and clouds, you could encounter challenges in moving VM images and data as well as with configuring network settings. It's relatively easy to shift virtual machine images from one virtualized environment to another. Migrating large databases or data sets, however, can be more problematic. And reconfiguring network settings should not be prohibitive, as long as you're prepared.