Over the last few months there has been a growing amount of momentum around cloud interoperability. Lately it seems that a few in the industry have gotten a little confused on the differences between Cloud Compatibility, Portability and Interoperability. So I thought it might be time to take a closer look at the various terms and how they relate as well as how they differ.

First lets start with Cloud Interoperability. As I've described before, Cloud Interoperability refers to the ability for multiple cloud platforms to work together or inter-operate. A key driver of an interoperable cloud computing ecosystem is to eliminate what I call proprietary "API Propagation" whereby each new cloud service provides their own unique set of web services and application programming interfaces. Simply, the goal of Cloud Interoperability is to make it easier to use multiple cloud providers who share a common set of application interfaces as well as a consensus on the terminology / taxonomies that describe them.

The next logical question is "how?" which brings us to Cloud Compatibility & Portability, something I would describe as a subset of Interoperability. What I find interesting about Cloud Computing is that unlike traditional CPU centric software development, in a cloud computing infrastructure the underlying hardware is typically abstracted to a point that it no longer matters what type of hardware is powering your cloud. Cloud Computing is about uniformity -- all your systems acting as one. Within this vision for the cloud we now have the opportunity to uniformly interact with a virtual representation of the infrastructure stack, one that can look and act anyway we choose (See my Multi & Metaverse posts). Whether you're using a component centric virtual environment (IaaS) or an application fabric (PaaS ) is completely secondary. What matters now is ensuring that an application has a common method of programmatic interaction to the underlying resources & services. More simply, Cloud Compatibility means your application and data will always work the same way regardless of the cloud provider or platform, internally or externally, open or closed.

Lastly is that of "Cloud Portability", this is where the application components are able to be easily moved and reused regardless of the provider, location, operating system, storage, format or API. The prerequirement for portability is the generalized abstraction between the application logic, data and system interfaces. When you're targeting several cloud platforms with the same application, portability is the key issue for development & operational cost reduction as well as a critical requirment when trying to avoid cloud lock-in.

One such example that address several of these concepts is the Open Virtualization Format (OVF). The format is an "open" standard proposed by the DMTF for packaging and distributing virtual appliances or more generally software to be run in virtual machines. The proposed specification describes an "open, secure, portable, efficient and extensible format for the packaging and distribution of software to be run in virtual machines". The OVF standard is not tied to any particular hypervisor or processor architecture. Like most standards, the major problem is it's only useful if all platforms / clouds actually support the OVF format. That's where a "semantic abstraction layer" comes in handy, with semantic cloud abstraction it doesn't matter if any providers actually implement the standard because it acts as a unifying agent capable of adapting to the similarities all cloud API's share while either ignoring the unique aspects.

I believe that without first a common consensus and eventually set of cloud standards, that the cloud ecosystem will likely result in a series of proprietary cloud's giving cloud users little hope of ever leaving. Cloud customers will be forced to be locked-in to a particular cloud vendor, unable to use another cloud without substantial switching costs. At the end of the day, this is the problem we're trying to solve at the CCIF.