Exploring cloud interoperability, part 3

While most readers probably think "portability or mobility" when they think of cloud interoperability, the vendor community sees a shorter-term opportunity in standardizing the operation of clouds and cloud infrastructures. It's not that vendors don't care about image portability; it is an especially critical opportunity for so-called "cloud operating system" vendors.

However, the cloud operations opportunity--building a full-featured operations API and user interface for a cloud--is a daunting task, requiring tools for provisioning, management and monitoring, among others.

(Note that I am calling the term "operations" tools, not "management" tools. It may seem like semantics, but when I published part 1 of this series, one of the systems management tools vendors quickly came back and said "hey, that's us!" Unfortunately, I'm not talking about monitoring and responding to problems with specific cloud payloads here, I'm talking about the interfaces you use to provision and control the clouds themselves. Of course, there is often overlap between the two concepts, just to make things...er...cloudier.)

In some ways, cloud operations interoperability is your basic API standardization story; allow several different independent management tools interact with several different independent cloud platforms and providers. Create a loosely coupled market dependency between the tools you use and the systems you manipulate with those tools. This is always a desirable goal in any open software marketplace.

However, there is a little more at stake here than simply enabling tools to be used across platforms. Consider this scenario: an enterprise has a distributed application system that runs components on two different major cloud provider infrastructures, relies on services running on two or three more, and stores data in their local data center. What would be the most desirable way to address the management of this system?

I would argue that you want as few "panes of glass" (i.e. disparate management applications) as possible, preferably one. To do that, you need standards that the single, all-encompassing management platform can rely on to access and manipulate all of the cloud platforms involved in the system.

In fact, you probably want to combine SOA and cloud management into a single pane of glass, so you probably want the standards to cover just about everything in the computing stack, from servers, storage and networking to specific application components and data stores.

Today, the focus is on providing a unified API for Infrastructure as a Service operations. In addition to standardizing how systems are provisioned, when they are active and what policies apply for situations like component failure or load spikes, it is also critical that this API unifies the way in which images are imported and exported from each provider's platform. A cloud operations API needs to cover as much of the system life cycle as possible, including provisioning and deployment.

There is so much effort being made in this space right now, by so many groups, that it is at times a little overwhelming. Luckily, I found a resource that has helped me organize not only the predominant operations API effort, but also the image/data and application/service interoperability classes. Believe it or not, it is a wiki dedicated to cloud efforts in the federal government market. (I'm telling you, the feds seem to be way ahead of the pack when it comes to organizing cloud activities these days.)

The wiki lists the following key efforts for "Governance and Management":

• Management of Virtualized Resources - DMTF (http://www.dmtf.org/initiatives/vman_initiative/)

• Open Cloud Standards Incubator - DMTF (http://www.dmtf.org/about/cloud-incubator)

• SLAs -at SOI (http://sla-at-soi.eu/)

• Compliance - Industry organizations (e.g. HIPAA, PCI) (http://www.hipaa.org/)

I was surprised to see three organizations missing from this list: the Cloud Computing Interoperability Forum (CCIF), the Open Cloud Consortium (OCC), and the Open Grid Forum's Open Cloud Computuing Initiative (OGF OCCI). It turns out the CCIF and OGF are acting more as organizing entities here, and the OCC is working standards around data and application interoperability, which I will talk about in part 4 of this series.

There is a "Cloud Standards Summit" planned for July 15th in Arlington, Va., that may clear further organize "who's doing what" in this space. I think the fact that such a meeting is taking place at all at this point is phenomenal. It is clearly an artifact of cloud computing's distinction as the first major IT disruption to take place in a world that assumes openness and transparency, thanks in large part to open source software.

As Matt Asay noted recently:

As much as anything, cloud computing has borrowed from open source in terms of its governing principles, which could well be open source's lasting contribution to the cloud. It took a few decades of Microsoft dominance to really get the open-source movement in full swing, but it only took a few months for things like the Open Cloud Consortium to spring to life. Open source has taught us to expect openness by default. The cloud is no different.