Stephen Foskett, Pack Rat

We Don’t Need Cloud Standards (Yet)

Posted on Sep 16, 2009 by Stephen

Championing “open” and calling for standards has become the first stalling action by late-movers in technology spaces. They see opportunity passing by and try to hold back progress and FUD the market by yelling about proprietary solutions, vendor lock-in, and a lack of standards. Many well-intentioned IT folks follow along: After all, who doesn’t want openness, standardization, and interoperability?

But cloud services are different. Seriously! Cloud services don’t need standards because:

1. Cloud services are still rapidly evolving – No one knows how they will look in a year, let alone a decade, and a premature standard will be worthless. Similarly, it’s not at all clear what use cases will eventually win out, and usage should drive interfaces, not the other way around.
2. Cloud services are many and varied – It’s incredibly hard to come up with a reasonably-complete standard programming API or management platform when each vendor’s offering is radically different. Standards must follow the 80/20 rule, but today’s cloud offerings are only about 20% similar.
3. (Real) cloud systems are open already – The whole point of the public cloud is to leverage existing open standards for access (IP/HTTP) and any worthwhile service already has a freely-usable REST-like API. Cloud services are engineered to be programmable and open, so the only lock-in is in how you use the cloud.

We can’t even agree on terminology at this point. Is data storage as a service DaaS (as SNIA says) or STaaS (as NetApp says)? How do you define public, private, and hybrid cloud? And what is cloud anyway? Cloud computing is not a war, it’s a fantastically exciting race to deliver value!

Open for Business

I’d like to return for a moment to that last point: The key element I’ve seen in most interesting cloudy products is programmability. Service providers publish API documents outlining the inputs, processing, and outputs for their systems and developers and end users create applications that leverage these. The best of these APIs use the concept of REST, delivering services through extremely simple and self-contained HTTP calls. This barely even rises to the level of software coding (and thus isn’t a true API) and is the hallmark of the cloud.

These systems are wide open: You can explore their interfaces, discovering new ways to use the them that were never intended. The same process accompanies all Internet systems, from RSS and Atom to Yahoo Finance. Just as one can rapidly migrate from Yahoo to Google by substituting a few URLs and parameters, so too can one move between cloud platforms.

Note that certain cloud systems lend themselves more to this kind of mobility. Once cannot move virtual machines from Amazon EC2 to Rackspace or Terremark because the underlying hypervisor technology is different. But even here companies like RightScale are stepping in to enable mobility.

When it comes to cloud storage services, the major players’ interfaces are open enough that migrating data in and out is simply a matter of performance: Read from this one, write to that one, and wait until the process is done. I am not a programmer and yet I was able to port an application from S3 to Nirvanix in just a few hours using only the respective API documentation. Interfaces like CloudLoop can also be leveraged to ease the movement of data.

Standards When?

Cloud services will eventually settle down and be standardized. I expect a workable cross-platform API for RESTful cloud storage within 24 months, for example. And one expects that the management of cloud compute instances will pass through a consistent and stable interface in that same timeframe. But these will develop as a natural part of the evolution of the systems themselves, not through some artificial “build it and they will come” standardization process.

There is nothing wrong with big companies sending their representatives to SNIA and DMTF meetings to talk about standardization. In fact, this is a great way to discuss ideas and begin to orient the industry. But the time for standards has not yet come, and users of cloud services have no need to wait for them. In fact, waiting for a standard will just prolong the maturation of cloud services, since real-world applications are the external pressure that forces evolutionary selection. Amazon would never have created their virtual private cloud (VPC) capability without customer input, and they will never perfect this capability if they rely only on pundits, bloggers, and product marketers.

Even when standards do appear, they will not eliminate per-solution APIs. Cloud service providers will continue to explore new concepts, and these will appear first in “proprietary” interfaces. Perhaps they will use entirely unique calls, or perhaps they will leverage reserved or unassigned sections of the standard, but innovation will continue. Witness the radical changes in HTML versions to date, the additions to CSS, and the wide world of browser plugins.

So we don’t need cloud standards yet. They will come, whether artificially pushed by committees or evolving through use, but only useful standards will survive. Isn’t that just how it should be?

Note: I am employed by Nirvanix, a cloud managed storage service provider, providing independent cloud strategy advice as Director of Consulting. Although this article was not created for my employer and is not intended to reflect their views, my perceptions are obviously colored by my daily work.

Tags: Amazon, API, cloud computing, cloud storage, CloudLoop, EC2, featured, FUD, Google, HTTP, NetApp, Nirvanix, Rackspace, REST, RightScale, S3, SNIA, Terremark, Yahoo