Openness in software and architectures is a big win for users. This truth is so widely recognized that a lot of vendors seem to favor using "open" as a sort of mantra even though they're often not, well, open except in glancing and incidental ways. This is nowhere truer than with cloud computing.

Having an open architecture and approach when building a cloud matters deeply. Only an open cloud allows customers to manage diverse infrastructures by bringing them together under the same cloud architecture. Instead of creating a new cloud silo or forcing them to (impractically) start their IT over from scratch, an open cloud extends its benefits to their entire IT infrastructure, delivering greater efficiency and agility and putting them in control of their technology roadmap and, ultimately, the future of their IT.

But what does "open" mean in the context of cloud? 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 in our view, should be) a given. But it's more than that too.

An open cloud has the following characteristics:

  • 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.
  • 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 on your 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, or 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 means that retesting and requalification isn't needed every time you want to redeploy.


An open cloud requires a wide range of attributes to push the needle from wholly closed to truly open. Having a few of these attributes is better than not having any. But only the full gamut lets organizations maximize the benefit they gain from cloud computing.

To learn more about Red Hat’s open approach to the cloud, join an announcement webcast presented by Red Hat executives on Wednesday, February 15, 2012 by visiting https://vts.inxpo.com/Launch/QReg.htm?ShowKey=8347. The webcast will also be available on demand following the live event.