Open Cloud Where Art Thou
On Wednesday, I participated in the Open Cloud Panel at the Linux Collaboration Summit. The panel was organized by John Mark Walker, and featured James Urquhart, Doug Tidwell, and Sam Ramji, besides yours truly. It was a lot of fun, but made it clear that there is no clear definition of what Open Cloud means, much less anything tangible that cloud users can turn to determine which clouds are open, or even why they should care about open clouds.
As I explained on the panel, I’d consider a cloud truly open if it gives users the same rights and opportunities that are the founding principles of open source software: freedom, choice, and user-driven innovation. Ultimately, users need open clouds for the same reason they need open source software: to protect their interests to the biggest possible extent, and fully determine their own (computing) future, without undue dependency on third parties.
What does that mean in the context of clouds ? Obviously, privacy and security of what you do and store in clouds is a strong concern, and has been widely discussed. More subtle are the issues that tie you more closely to whatever cloud you’re using than you initially imagined. Anybody who considers moving to the cloud should therefore consider how they get out of that specific cloud before they move in.
For SaaS clouds, the biggest issue is that the software you are using as a service might not be available anywhere else; that means that even if your SaaS provider lets you retrieve your own data, a feature whose absence any user should consider a deal breaker, that data might not be of any practical value. After all, you are using the SaaS application since it provides a valuable service — unless you can be sure that you can either run the SaaS application yourself, or transform your data with reasonable effort to an equivalent application, your data might turn into the proverbial pumpkin when you part ways with your SaaS provider.
For PaaS clouds, the situation is less dire - generally, deploying an application to a PaaS provider is not all that different from deploying on your own hardware, simply because developers still develop applications locally, and PaaS providers try to make it easy for developers to go from local development to cloud deployment. The danger here is more in value-added services where your application becomes more ‘cloudy’ and depends more and more on convenient, but singular, services of your provider.
Finally, IaaS clouds, pose some of the same issues as PaaS clouds, since they all offer singular services that you will come to rely on. Since the API’s offered by IaaS providers are immensely important for any serious deployment in IaaS clouds, your own tooling will come to depend more and more on the cloud’s management API, locking you into that cloud if you are not extremely careful. It doesn’t help that most public clouds exemplify the strange equation ‘open source + open source = proprietary’ — most of them use open source software for their infrastructure, you generally run open source virtual machines in those clouds, yet the glue holding it all together, including the API, is essentially prorietary.
