There is an ongoing discussion about the need for creating standards in the cloud computing space, including the establishment of the Cloud Computing Interoperability Forum (CCIF) of which I'm a member.
Motivation for Creating Cloud Computing Standards
The drivers for establishing industry standards for cloud computing are quite straightforward and similar to the same drivers in other areas of IT and other industries. From a user/customer perspective standards (at least theoretically) eliminate vendor lock-in. If all cloud providers use the same provisioning API, for example, customers don't need to bet and commit themselves to a particular provider. They will be able to switch with little time, cost or effort and use any other provider's provisioning API.
From a vendor point-of-view there is also motivation for standardization. Given the customer lock-in concern, the approach many companies will take is stay on the sidelines or only dip their toes in the cloud computing waters, and not dive all-in. In other words, lack of standards is an adoption barrier.
Furthermore, the absence of interoperability across the entire cloud computing ecosystem -- not just cloud providers, but also tools that add value to them such as management and monitoring -- reduces the overall value of cloud computing.
Consider the case of the shipping container as described in the excellent book The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger
By standardizing on uniform container specifications, the industry removed the barriers to long-distance shipping and greatly increased the demand for it, while reducing their own costs. A boon to everyone involved.
Similarly, we can assume that if there were standards across the board for cloud computing, the uncertainty and fear of vendor lock-in would be greatly reduced and the ecosystem as a whole will become more beneficial to customers, freeing presumably pent-up demand. In Gang up now before the *aas cloud gets you, Simon Wardley makes a powerful argument for consumers to push cloud vendors towards interoperability and portability, and what he calls "open source standards" (his presentation in the link above is a must watch).
The Case Against Standards
As almost everything else in life, standards too have a downside. Standards stifle innovation - by definition. It's true that good standards should only dictate what the product/technology needs to do, and not how. In other words, and specifically in the software world, a standard should only dictate the API sematics, and not the underlying implementation.
The problem is that in an emerging, dynamic area, such as cloud computing, the "what" is still a work in progress. We are only at the very early stages of understanding what the use cases are for cloud computing, what exact functionalty is needed by various constituencies, and what are the missing pieces. Trying to codify this highly fluid situation in a set of standards is a huge mistake.
Standards are only appropriate when an industry (or class of technology) has reached a medium level of maturity (and then standards will carry it to a high level of maturity). This is why, despite the resistance in the "cloudosphere", Gartner is probably right with their prediction that cloud computing will only reach "mainsream critical mass and commoditzation" between 2012 and 2015.
The Optimal Way to Standardize
There is another reason to avoid forcing a formal standardization process in cloud computing. It's simply not the ideal way to create a standard. There are two kinds of standards: de jure and de facto. Both phrases are from the Latin, the former meaning "by law" and the latter "by fact" --or in other words, there are official standards and standards that were not defined formally, yet have become standards in daily practice.
Formal standards are the ultimate form of "design by committee." They require compromises and involve politics and ulterior motives. They also tend to be too slow and bureaucratic. They are not the optimal way to come up with the best solution the market needs for a particular problems. The marketplace is the best tool for that (and when I say "marketplace" I also include free open source). As a particular class of technology matures, it is actually good to have a number of competing approaches and let the users vote with their feet for the one that best suits their needs.
A good example of this is what happened in Java. Although I'm sure some will argue with this analysis, essentially the Java Community Process (JCP), the official standards body of the Java platform and language was slow to adopt new programming practices and adapt to developer needs, so alternative, unofficial frameworks evolved. One of them, the Spring Framework, came out as an open source framework in 2004, and was so rapidly adopted by the community that by 2008 it was alreaddy considered by many to be a de facto standard.
Another problematic standard was WS*. Where the standards body attempted to keep up with the rapid developments in web services technology -- an impossible tasks, and ended up with numerous half-baked standards, many of which enjoyed little if any adoption in the marketplace.
The evolutionary approach to standards is even more evident in the Ruby on Rails community, which has no standards body or dominant vendor. Multiple Ruby implementations (e.g., MRI, Rubinius, JRuby), multiple frameworks (e.g., Rails, Merb, Sinatra), and multiple app servers (e.g., Mongrel, Thin, ebb) are all competing to become the de facto standard, and we will soon see which ones emerge victorious (and if it makes sense to have multiple approaches for different needs). Already there is some convergence with the merger of Rails and Merb.
In summary, the correct approach to developing standards is to first let the marketplace converge on de facto standards. A formal standards body can step in at a later stage to tie up loose ends and manage a more stable process.
The State of Standards in the Cloud
It's immportant to first make the destinction between cloud-specific standards and standards that are related but are moving on their own trajectory regardless of the developments in cloud computing. These include programming languages, operating systems, many security issues, web services and databases, to name but a few.
We then need to ask ourselves, what then, are issues unique to cloud computing that need to be addressed. The blogosphere has been abuzz lately with the discussion about exactly that. In order to understand what standards are required, we first need to understand what are the techologies that are involved in cloud computing and how they relate to each other. In other words, a taxonomy and ontology for cloud computing. In the Wisdom of Clouds, James Urquhart discusses The need for a standard cloud taxonomy. And inspired by John WIllis's Unified Ontology of Cloud Computing, Chris Hoff developed an excellent diagram of a Cloud Computing Taxonomy & Ontology. These are examples of the correct first step to standards at this point time, which is merely trying to put everyone on the same page in terms of terminology.
Reuven Cohen, who initiated the Cloud Computing Interoperability Forum writes about the need for a Semantic Cloud Abstraction , which he calls the Unified Cloud Interface, a sort of meta-API. As already mentioned, the correct approach for standards is to define the 'what' and not the 'how', so the abstraction approach is correct and I applaud Ruv for it. But as also stated, it is way too early in the game to get into this level of detail. Patrick Kerpan of CohesiveFT expresses a similar sentiment in his blog post Cloud Interop Caution.
Sales people are taught not to fall into the trap of "premature elaboration" when it comes to product feature pitches. "First, ask questions and listen" is the good sales person's rule. I think the same applies when it comes to standards.
