Three hurdles of data portability with multiple cloud providers

Moving apps from on-premises to cloud or from one cloud provider to another won't happen overnight. And these three obstacles can halt it completely.

This Content Component encountered an error

Migrating 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.

Migrating data from one cloud platform to another can be a substantial challenge.

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.

Reconfiguring network settings should not be prohibitive, as long as you're prepared.

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.

Dan Sullivan, M.Sc., is an author, systems architect and consultant with over 20 years of IT experience with engagements in advanced analytics, systems architecture, database design, enterprise security and business intelligence. He has worked in a broad range of industries, including financial services, manufacturing, pharmaceuticals, software development, government, retail, and education, among others. Dan has written extensively about topics ranging from data warehousing, cloud computing, and advanced analytics to security management, collaboration, and text mining.

This was first published in July 2012

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

1 comment

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchServerVirtualization

SearchVMware

SearchVirtualDesktop

SearchAWS

SearchDataCenter

SearchWindowsServer

SearchSOA

SearchCRM

Close