First of all, let me define what I encompass when saying "in the cloud." I certainly do not limit myself to software as a service (SaaS) as Richard Stallman was referring to when he stated that "cloud computing is a trap."
In the cloud, from the perspective of this blog, refers to all the components that together make up cloud computing; from the infrastructure (IaaS), to the platform (Paas) and to the software (SaaS), as shown:
In this pile, SaaS is only the tip of the iceberg. The individual is left to choose whether they should or should not use a public SaaS infrastructure to store data or else they'll be falling into a trap. From the enterprise perspective, due to the fact that you can deploy a cloud infrastructure within your own network, the risks are not the same.
Risks AheadAs I mentioned in my previous blog last month, the use of proprietary software and data formats are a heightened risk when used in the cloud; even more so if the transparency regarding which technology is being used where, is not provided to the user. What I did not mention though is that there is an effort to standardize the interactions between the various bricks in the cloud, through the definition of standard APIs. Last time we counted there were more than 13 vendors proposing their APIs as a standard, and just about as many standard committees trying to define what the standard API should be. I don't foresee much hope to reach a resolution in the near future, and that is obviously part of the problem.
Optimistically, let's imagine that through the use of some magical wand, a standard is finally agreed upon quickly. Whether it is by ECMA, DMTF, IEEE, or whomever, does not really matter. What will really matter is whether this standard will come with a reference implementation that is free software.
Why is that? Well, let's try to look back at software standards that do not provide a reference implementation which is free software. There are multiple examples of this, with SQL, .Net, and DocX coming immediately to mind. Would you consider those good examples of standards that allowed user independence from the software they use?
Smarter ApproachesOn the other hand if you look at TCP, OpenDocument, TLS, HTML (again, just a few random examples) the very fact that free and open source implementation of them existed prevented vendors from deviating from the standard, or else they would not be inter-operable. Moreover, with reference implementation that is free software, why would you go through the pain of reinventing the wheel unless you were really forced to, or were willing to re-implement it in a better (faster) way, but still exposing the same API. Of course every standard evolves, but if the evolution is conditioned by the release of matching free implementation, this is the real key to a standard that actually protects the users.
At the moment, two interesting initiatives exist on the infrastructure level (IaaS). The first one I'll talk about is Red Hat's DeltaCloud, "an API that abstracts the differences between the clouds." In a nutshell it tries to provide the same direction which Red Hat provided with libvirt at the hypervisor level. It is too early to see if an ecosystem of tools using this API will emerge, as this will be the key success measurement. The second is a series of free (and non-free) software projects that have built themselves around implementing a cloud infrastructure that responds to the same API that Amazon's EC2 uses. It assumes that Amazon's API, which is the largest deployed one at the moment, will become a de-facto standard. This is the approach chosen for Ubuntu Enterprise Cloud, and it pays, as tools such as RightScale or CohesiveFT which had been built to manage EC2, quickly embraced UEC. The good thing is that as DeltaCloud supports the EC2 API, it does not really matter which API will win in then end, as long as it is a free software one.
However, API standardization is only one of the reasons free software is important to cloud computing, albeit an important one. Cloud computing does obey the same rules as computing in general from the perspective freedom, but this freedom becomes even more important if you are thinking about outsourcing a part of your computing environment. Data, software and competitive freedom suddenly all become crucial elements that any enterprise should watch when considering their outsourcing options, as the TIO Libre workgroup has been finding out. I would personally add that net neutrality is also an important factor in your ability to bring back your outsourced service to you. If the day you bring back your service, you realize that you cannot share it on the Internet anymore, or that you cannot run the software stack, or that you cannot migrate your data, the operation will be highly compromised.
I hope this sheds some light on why free software, and other correlated freedoms, is so important to cloud computing. It doesn't necessarily make it easier in the short term, but will definitely pay in the end. "The price of freedom is eternal vigilance" (Thomas Jefferson), is as true a statement in the computing world as it is elsewhere...e.
Nicolas (Nick) Barcet is server product manager at Canonical. Guest blog entries such as this one are contributed on a monthly basis as part of WorksWithU’s 2009 sponsorship program.