Last week at CloudOpen we had a short panel discussion about what makes an “open cloud.” Surprisingly, some folks don’t think that having the source code to the cloud service is a requirement.
The panel, led by Red Hat’s John Mark Walker, included Sam Ramji (Apigee), Greg DeKoenigsberg (Eucalyptus Systems), Stefano Maffulli (OpenStack) and I sat in on behalf of Apache CloudStack. It was a fun panel, lively, and short. With just 30 minutes for the discussion, we didn’t have time to do a deep dive into the topic.
On many points, all of the panelists were in agreement. The notable exception? Source code. Sam argued that source was unnecessary, and as long as the APIs were open and you could get data out, it’s an “open cloud.”
Since cloud is a huge trend in IT right now, everyone is trying to hop on board whether their products really fit the cloud definition or not. (The NIST definition of cloud is pretty good, but I’d add APIs to that mix. It’s really not a cloud if you can’t access it and control it via APIs.) Vendors that try to dress up products that don’t fit the NIST definition are often called out for cloud washing their products.
This is nothing new. Vendors have been trying to paint their products with the open brush for years. But we are seeing a resurgence with cloud computing, as vendors who don’t offer open source software try to call their offerings open.
The Properties of an Open Cloud: Show Me the Code
Some folks will argue that a cloud service or offering is open if it has open APIs and open standards. Note that, for the purposes of this post when I talk about cloud, I’m talking about Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (Paas) clouds like CloudStack (IaaS) and OpenShift (PaaS).
For my money, the best definition of the open cloud came from Red Hat’s Scott Crenshaw:
- It enables portability across clouds
- Has a pluggable, extensible, and open API
- Lets you deploy to your choice of infrastructure
- It’s unencumbered by patents and other IP restrictions
- It’s based on open standards
- It has a viable and independent community
- It is open source.
Having open APIs is necessary, but it’s not enough. If you depend on one vendor to provide your cloud, and you can’t pull it in-house for any reason, it’s just not open.
One issue that came up on the panel is the responsibility of vendors to offer open clouds. While I think that vendors should provide solutions that meet all seven of Crenshaw’s points, you can’t put all the responsibility on the vendors to automatically do the right thing.
That is to say, customers have some responsibility here as well to demand open cloud from vendors or vote with their feet and dollars by choosing open solutions. If an open solution doesn’t exist, then it might be necessary to build it rather than buying into a closed cloud.
Why It Matters
Why is it so important for a cloud to be open? It’s not just a philosophical exercise – today’s organizations have practical needs to be able to touch the source, modify it, and distribute it.
Companies like GreenQloud and SunGard have not only deployed CloudStack in their own infrastructure – they’ve also improved it and deployed changes. You can’t do that with vCloud or Amazon Web Services.
The other reason is that organizations need to take a very long view about cloud deployments. You really don’t want to be locked into a single provider for the next decade after deploying essential services that your organization depends on.
It’s important to remember that we wouldn’t have cloud without open platforms to begin with. Amazon used Linux as the foundation for Amazon Web Services (AWS), and that was possible because the components that Amazon needed (the operating system, the Xen hypervisor) were open source. Amazon was able to tailor those components to its needs and build out massive services.
Organizations that are building out their cloud infrastructure need and deserve the same advantages that Amazon and others started with. If you think about it, it’s pretty clear what an open cloud is – and why it’s the smart choice.