The Varieties of Openness Worth Wanting in the Cloud

By George Reese
March 27, 2009 | Comments: 4

Microsoft's pre-emptive move against the Open Cloud Manifesto and the subsequent early leaking of the manifesto has generated a significant level of controversy and discussion in the cloud computing community. All of the vendors in the cloud space have paid some level of lip service to the idea of openness in the cloud, and most everyone believes that being "Open" is a "good thing". In an environment in which few people agree on the specifics of defining the term "cloud computing", what exactly does it mean to have an Open Cloud?

The term "Open" itself has a number of different meanings in the information technology space:

  • Open source code. The software running the underlying infrastructure is under licensing terms commonly accepted as being Open. Typically, Open Source means portability of your license across environments and access to read and modify source code.
  • Open APIs. The mechanisms for leveraging your service are both published for public consumption and you allow others to implement those APIs to talk to their services.
  • Open data formats. Similar to Open APIs, Open data formats grant customers free access to their data in a format that may be read by other systems without any encumbering patents or licensing.

The technologies that make up the cloud are old. What makes cloud computing "new" is the development of infrastructures of scale that make those old technologies available on demand. The problem with defining Open today in the context of cloud computing is that the evaluation of Openness that you would apply to the technologies behind cloud computing are simply not worth wanting in the cloud. All else being equal, it simply should not matter to you if Amazon is using Xen or VMware or some other product, Open or otherwise.

How do we sort out the varieties of Openness worth wanting while avoiding stifling the mad innovation still going on in the cloud?

1. We want a clear path to business continuity planning.

First and foremost, Openness means a clear path to business continuity planning in the cloud. If Microsoft were to go out of business tomorrow, you would still be able to run your Windows servers in your data center--but you would no longer have access to their cloud infrastructure. As a result, business continuity planning in the context of the cloud is much more significant than it has traditionally been in selecting vendors. Big companies go out of business. Enron did. AIG should have. GM just might. And one day Microsoft or Amazon could go out of business.

An Open cloud will therefore make it possible to move your data systems and licenses from one cloud to the next. The devil, however, is in the details. Does Openness dictate that the cloud provider should use an open machine image format? Or is it sufficient that the provider not require any proprietary version of an OS or proprietary API calls for your app to run in their cloud? Under the former view, Amazon is a closed cloud. Under the latter, Amazon's an Open cloud. I don't think machine image portability is critical unless the cloud provider is requiring custom, non-portable operating system licenses or requires your applications or data to have tie-ins to that cloud.

2. We want the freedom to use the tools that work for us, not the ones a vendor mandates.

In the long term, a heterogeneous infrastructure may demand that you have Windows servers running in Azure, Linux servers on GoGrid, and Solaris servers in the Sun cloud. You should have the option of picking the best tools to manage each environment, or even a single set of tools that span all environments. In other words, an Open cloud vendor must provide a public API for the provisioning of its resources and that API itself must be Open. In other words, for Amazon's cloud to be Open, they need to allow Microsoft to implement the AWS APIs for managing Microsoft cloud services.

This kind of Openness does not mean blindly implementing some industry standard for Open provisioning. It is too early for such a discussion, and that kind of API would limit innovation at a critical time. But Microsoft should have the ability to implement the AWS API and enable its customers to take advantage of the third-party tools that manage AWS environments.

3. We want the freedom to use our data as we see fit.

Your data is yours and no cloud provider should get in the way of that. An Open Cloud provider will make sure that you have access to your data via an Open data interchange format that includes an Open access API. I should be able to take my data and leverage it inside my Google AppEngine application without having to pay absurd fees to for the use of my own data.

It's also worth noting:

  • I should still have to pay for bandwidth associated for moving that data.
  • The vendor should share the responsibility of protecting my data in its control.

You might also be interested in:


The cloud is only one place where standards are required. Recall the big fiasco with XML and OMXL?

SOA (Service oriented architecture) design parallels computer object oriented programming. In the latter, a function has certain well defined inputs, and produces a well defined output. How it works is not essential to the user. With the SOA architecture, the client choses the functionality from his vendor of choice. Cloud computing should be SOA, but MS, YAHOO, and who ever, want it to remain SaaS (Software as a service).

Given the Western populations which are insignificant in numbers against Europe, and Asia, I believe that it is they that will define cloud computing, SOA, and SAAS. In fact, great software from India is already SAAS and SOA ready.

>> "Europe, and Asia .. will define cloud computing"
>> "software from India is already SAAS and SOA ready"


Can you please provide a little bit of support for both of these statements, something as simple as concrete examples of specific European and Asian initiatives and Indian software?


Though I do look forward to the requested examples, it does make a lot of sense that we should be looking to the east for the next Google (assuming of course it's not Google itself :) )



As you are no doubt already aware, at the Open Cloud Initiative we ended up settling on the same three requirements as well as one you have not mentioned: Open Data (it's one thing to have a super funky gene analyser with source code and APIs but it would be far more useful with a copy of the human genome!)

The second two, Open APIs and Open Formats, are by far the most important (in fact the relevance of Open Source appears to be tapering off, which is something the FSF and OSI should be looking at). There's no point having an API to opaque data and conversely there's no point having transparent data locked up in the machine. So these go hand in hand and that's basically what we settled on for "Open Cloud" (along with some wording to avoid discrimination and things like 1,000 year service contracts, and a sensible definition of "open standard" which we can hopefully ratchet up towards "free" over time).

Thanks for your contribution to the discussion... once we finalise the draft it's just going to be a case of getting the word out and we'll be in a much better position.


News Topics

Recommended for You

Got a Question?