Open clouds: Beyond a veneer

After one too many shouts punctuated by "In the name of the Queen!" by London's Master of Revels, Judi Dench's Queen Elizabeth in Shakespeare in Love rises to intone: "Mr Tilney! Have a care with my name -  you will wear it out."
I sometimes feel similarly when it comes to the ferocity with which a lot of vendors apply the word "open" to cloud computing. Especially given that not a few of those involved aren't very, well, open but make up for the glancing and incidental ways their software and approaches are open with the volume of their rhetoric and the font size they use to display "OPEN" in their marketing literature.
But what does "open" mean in the context of building a hybrid cloud? (In this context, I'm primarily focused on building hybrid Infrastructure-as-a-Service clouds, although a lot of the principles carry over to other forms of cloud computing as well.) It certainly doesn't begin and end with the submission of some format to a standards body or with an announcement of partners endorsing some specific technology platform. And open source may be (or should be anyway) a given. But it's more than that too. In getting ready for a Red Hat Webcast that I helped put together, I did a lot of thinking about the different aspects of openness. Here's what I (with the help of others at Red Hat) came up with. An open cloud:

• Is open source. This allows adopters to control their particular implementation and doesn't restrict them to the technology and business roadmap of a specific vendor. It lets them build and manage clouds that put them in control of their own destiny and provides them with visibility into the technology on which they're basing their business. It provides them with the flexibility to run the workloads of their choice, including proprietary ones, in their cloud. Open source also lets them collaborate with other communities and companies to help drive innovation in the areas that are important to them.
• Has a viable, independent community. Open source isn't just about the code, its license, and how it can be used and extended. At least as important is the community associated with the code and how it's governed. Realizing the collaborative potential of open source and the innovation it can deliver to everyone means having the structures and organization in place to tap it fully.
• Is based on open standards, or protocols and formats that are moving toward standardization and that are independent of vendor and platform. Standardization in the sense of “official” cloud standards blessed by standards bodies is still in early days. That said, approaches to interoperability that aren't under the control of individual vendors and that aren't tied to specific platforms offer important flexibility. This allows the API specification to evolve beyond implementation constraints and creates the opportunity for communities and organizations to develop variants that meet their individual technical and commercial requirements.
• Intellectual property rights owners offer freedom to use IP. Recent history has repeatedly shown that there are few guarantees that intellectual property (IP) assets will remain accessible to all from one day to the next.  To have confidence that you will continue to enjoy access to IP assets that you depend on under the terms that you depend on, permission needs to be given in ways that make that technology open and accessible to the user.  So-called “de facto standards,” which are often “standards” only insofar as they are promoted by a large vendor, often fail this test.
• Is deployable across a customer's choice of infrastructure. Hybrid cloud management should provide an additional layer of abstraction above virtualization, physical servers, storage, networking, and public cloud providers. This implies—indeed requires—that cloud management be independent of virtualization and other foundational technologies. This is a fundamental reason that cloud is different from virtualization management and a fundamental enabler of hybrid clouds that span physical servers, multiple virtualization platforms, and a wide range of public cloud providers including top public clouds.
• Is pluggable and extensible with an open API. This lets users add features, providers, and technologies from a variety of vendors or other sources. Critically, the API itself cannot be under the control of a specific vendor or tied to a specific implementation but must be under the auspices of a third-party organization that allows for contributions and extensions in an open and transparent manner. Deltacloud, an API that abstracts the differences between clouds, provides a good example. It is under the auspices of the Apache Software Foundation and is neither a Red Hat controlled project nor tied to a particular implementation of cloud management.
• Enables portability to other clouds. Implicit in a cloud approach that provides support for heterogeneous infrastructure is that investments made in developing for an open cloud must be portable to other such clouds. Portability takes a variety of forms including programming languages and frameworks, data, and the applications themselves. If you develop an application for one cloud, you shouldn't need to rewrite it in a different language or use different APIs to move it somewhere else. Furthermore, a consistent runtime environment across clouds ensures that retesting and requalification isn't needed every time you want to redeploy.

Of course, none of us have a perfect grade in every respect. Communities take time to develop. There are finite developer hours but an almost limitless variety of potentially supported infrastructure. And there will always be tradeoffs between value-add and perfect portability. However, I'd argue that the more aspects in which a cloud is open, the greater value an organization can gain from that cloud.
If you're interested in seeing my thoughts fleshed out in a bit more depth, here's a white paper that I wrote on the topic.