How providers affect cloud application migration

Migrating applications from one cloud to another isn’t quite as simple as picking up and transitioning. A lot depends on choosing the right provider.

In an attempt to reduce lock-in, improve cloud interoperability and ultimately choose the best option for their enterprises, more than a few cloud computing users have been clamoring for the ability to seamlessly migrate applications from cloud to cloud. Unfortunately, there's more to application migration than simply moving an application into a new cloud.

To date, cloud application migration in clouds has focused on moving apps back and forth between a virtualized data center or private cloud environment and public clouds such as Amazon Elastic Compute Cloud, Rackspace or Savvis. There is also a group of public cloud-oriented companies that are looking to move applications to private clouds or virtualized data centers to save money. Still others are interested in moving applications from one public cloud to another in a quest for better service-level agreements and/or performance at a lower cost.

What are some of the worries in moving an application from one environment to another?

  • Data movement and encryption, both in transit and when it reaches the target environment.
  • Setting up networking to maintain certain relationships in the source environment and preparing to connect into different network options provided by the target environment.
  • The application itself, which lives in an ecosystem surrounded by tools and processes. When the application is moved to a target cloud, you may have to re-architect it based on the components/resources that the target cloud provides.

Applications are being built in a number of ways using various Platform as a Service offerings, including Windows Azure, Google App Engine and Force.com. With a few exceptions for Windows Azure, the applications you create using most platforms are not very, if at all, portable. If you develop on Google App Engine, then you have to run on Google App Engine.

Public clouds, like Amazon, also allow you to build applications. This is similar to building in your data center or private cloud, but public clouds may place restrictions on resources and components you can use during development. This can make testing difficult and create issues when you try to move the application into production mode in your data center environment or to another cloud environment.

Applications built in data centers may or may not be easily moved to target cloud environments. A large number of applications use third-party software, such as database and productivity applications. Without access to source code, proprietary third-party applications may be difficult to move to clouds when changes are needed.

The complications of cloud application migration
Why is migrating apps in the cloud so difficult? During traditional application development, we have complete control of everything we need: a physical server, an operating system, the amount of memory needed, the disk storage system, network configuration, patching and runtime systems such as Java.

But when server consolidation came along, our notion of environment for applications changed somewhat. We are given an application environment that we still control, sans the personal physical server. Hypervisors provide us with hardware and all other aspects of an environment, so that our operating system, middleware and applications still have all of the things that they want and need.

And when it comes to clouds, providers pick the operating system, management tools, the networking architecture, the storage system and the virtual machine configuration. This is the baseline with which you work, offering much less control of the environment for developing and deploying applications. If you want to move some of your applications to a cloud, then you have to make them work in an environment that will almost certainly be different from the one in which they were last deployed and/or developed.

The decisions made by the cloud provider affect what you can and cannot do within the cloud. For example, a cloud provider could decide to go with cheap disk drives and do big NFS shares or iSCSI shares to feed the virtualization layer, which sets a performance envelope, a protection level and a raw capacity for the storage for your virtual machine. You do not generally get a say in any of this; you must live with it.

Take a look at Amazon. The public cloud leader has decided that your virtual machine gets one network adapter with one interface. It also doesn't support layer 2 connectivity or broadcast and multi-cast. When you go into these types of environments, the design of your application is constrained by the cloud resources, in this case networking, that you're allowed to access.

Another example further illustrates how functions at various levels can affect your ability to move applications to clouds and from cloud to cloud. You have chosen MySQL as the database system for your application. One of the functions you can perform with MySQL is database replication -- two instances of a database kept in synch. The replication process in MySQL utilizes multi-cast as part of low-level Ethernet to communicate between the two database instances. If you want to run your application on Amazon and replicate a database, you have a problem: Amazon does not support multi-cast in its networking layers.

What do you do? You could use a different database in your application, or you could implement the replication function differently, but that would require messing with MySQL or handling it through the application. Either way, if you're thinking about interoperability and moving applications from cloud to cloud, you'll also have to think about top-to-bottom integration of your entire software stack into a target cloud environment.

The challenge is that you may not know all of the dependencies between the components of your application stack and elements of the cloud itself. There is a lot of value to extract from the use of clouds. but if you have to expend a lot of energy and if it creates a burden for maintenance and support, you greatly diminish whatever gains you get.

Tools to facilitate application migration in clouds
Given the differences in environments, some customers may not want to go through the oft-difficult process of making an application work in a target cloud. But if we can give the virtual machine in the new cloud exactly what it wants to see -- independent of the hypervisor, the cloud environment it is on -- then application migration is easier. This is what products like CloudSwitch and Racemi offer.

Applications built in data centers may or may not be easily moved to target cloud environments.

CloudSwitch facilitates multi-tier application migration in the cloud with its Cloud Isolation Technology, which is a virtualization technology layer that automatically runs on top of the cloud provider’s hypervisor and beneath the end user’s operating system. The virtualization layer feeds the virtual machine exactly what it wants to see -- without requiring anything special from the cloud provider -- and runs on behalf of the customer to protect and isolate an environment in the cloud. Applications do not have to be modified when using CloudSwitch; it maps the application so that it seems to be running within the target cloud environment while actually maintaining the same exact configuration as in the source environment.

Racemi takes a different approach to migrating applications than CloudSwitch. It involves capturing a server, physical or virtual, in one environment (data center or cloud) and then deploying it in a target environment (data center or cloud). An important component of the Racemi application migration offering is a management appliance that has access to both the captured server environment and the target server environment and begins a mapping process between the two. Once this mapping process is completed, the capturing-deploying activity is complete and the application has been migrated to the target environment.

Cloud application migration takeaways
Migrating applications can be quite a big issue in hybrid cloud and a little less of an issue when you just want to move an application from your data center to a public cloud. You may, however, still encounter some of the problems discussed above.

Application migration involves more than just dealing with potentially incompatible cloud application programming interfaces. There are potential issues at each level of an application stack, as your two clouds are very likely to have differences in hypervisors, operating systems, storage and network configurations, and drivers.

When you are creating cloud environments with the intention of moving applications around, you need to perform a thorough investigation of the differences in the cloud environments and look at your application architectures to determine if they are reasonable fits. The second part of this piece on cloud application migration will offer up some possible solutions to difficult migration problems.

ABOUT THE AUTHOR:
Bill Claybrook is a marketing research analyst with over 35 years of experience in the computer industry with the last dozen years in Linux, Open Source, and Cloud Computing. Bill was Research Director, Linux and Open Source, at The Aberdeen Group in Boston and a competitive analyst/Linux product-marketing manager at Novell. He is currently President of New River Marketing Research and Directions on Red Hat. He holds a Ph.D. in Computer Science.

This was first published in June 2011

Dig deeper on PaaS cloud computing strategy

Pro+

Features

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

0 comments

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

SearchAWS

SearchSOA

TheServerSide

SearchFinancialApplications

SearchBusinessAnalytics

SearchCRM

Close