Why You Can Trust CNET Exploring cloud interoperability, part 2
There is tremendous excitement in the market about what the world will look like with "cloud interoperability" standards, such as image portability and mobility. How much of that is easier said than done, however?
Earlier, I talked through the three key categories of cloud interoperability as I see them, and the promise that each holds for increasing the agility and value of IT. One of those categories was Image/Data interoperability, which I defined as follows:
This is the one that most people assume when they say "cloud interoperability." How do you define a virtual server image, or a Java application, or a customer relationship management (CRM) database, such that it can be deployed on another host, often a competitive host, without modification?
In reality, Image/Data interoperability can be further divided into two subcategories:
Portability: The ability to move an image in a "down" state, and boot it at its destination. The image, in this case, can be as simple as a file system or as advanced as an Open Virtualization Format (OVF) portable VM image with sophisticated metadata. This can be considered a "stateless" move.
Mobility: The ability to move a live compute workload without losing client connections or in-flight state. VMotion is an early example of workload mobility, but the future promises mobility of "virtual containers," which incorporate one or more VM, network policy, storage policy (which may or may not contain actual data), and additional metadata around dependencies, automation policies, etc.
The problem facing the market right now is that most people assume that mobility is the target everyone is shooting for today. It's true that in the long term, everyone I've spoken to is targeting mobility as a way to create opportunities for cost savings and new business models. I've written about this before.
However, it is also a sobering fact that mobility across data center boundaries (especially across so-called "Layer 3" boundaries) will be some time in coming. The issue isn't simply networking challenges, though they are big--for example, global IP address portability, latency, security, etc. Other challenges are equally as daunting, such as how to manage data in a dynamic deployment environment, how to maintain access from mobile VMs to static resources, etc.
The truth of the matter is that global live workload mobility is still an early research and development project. Unless, of course, some start-up comes along and proves me wrong...
That being said, there is an algorithm for simulating mobility that is very compelling today, and I believe will be used in a wide variety of applications in the coming years. In fact, it is already common in Amazon EC2 deployments, and you might already be using it within your own data centers today.
The idea is to take advantage of the portability of images to replicate compute workloads across all of the data centers in which you may want it to run. Then, you set up your global load balancing to distribute load to one or a few of those instances. When "mobility" is needed, you just change the load-balancer configuration to redirect to instances in other data centers.
I call this scenario "faux mobility," and it is for all intents and purposes a stateless mobility algorithm. Faux mobility is what you might use to distribute risk across multiple availability zones in Amazon Web Services. It may also be the way you distribute risk across multiple cloud providers. One of my favorite uses is an algorithm I've heard called "whack-a-mole," in which an application is kept running in a single data center at a time, but if availability to data center A is interrupted, load balancers send subsequent requests to data center B--which now becomes the primary data center for the application. This can be repeated over and over again as events require.
While faux mobility is extremely useful, it won't be the game changer that live mobility will be, as the former requires images to be stored in all applicable data centers/cloud providers before an event occurs. Live mobility will change things drastically precisely because the image (or "virtual container" of images) can be moved to a provider whether the provider knew of the image beforehand.
Finally, it is interesting to note that, while most cloud customers probably think of portability and/or mobility as "cloud interoperability," it is not the primary front in the standards effort under way today. That would be management interoperability, where there are several efforts already under way. I noted several of these in part 1 of this series, but I will cover the issues in more depth in part 3.