Is Amazon the Official Cloud Standard?
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Ellen Rubin
The Structure 2010 show was memorable for CloudSwitch, highlighted by the launch of the commercial version of our CloudSwitch Enterprise software that lets companies easily use multiple cloud providers to run their enterprise applications. With a few clicks, users run their applications where they best fit, based on their specific business and technical criteria.
So it certainly got our attention when at the Hybrid Clouds panel, Marten Mickos, CEO of Eucalyptus Systems, made a claim that Amazon’s API should be the basis for an industry standard. Marten added that the industry should orient around Amazon’s approach much as IBM’s personal computer became the standard for the PC industry. (Generations of loyal Mac users are probably glad there was still room for alternatives!)
If there were an industry standard, Amazon certainly has a strong claim for it. They’re the clear leader, with technology second to none. They’ve made huge contributions to advance cloud computing. Their API is highly proven and widely used, their cloud is highly scalable, and they have by far the biggest traction of any cloud. So full credit to Amazon for leading the way in bringing cloud computing into the mainstream. But it’s a big leap from there to saying that Amazon should be the basis for an industry standard.
It’s clear to us that the enterprise market wants options, both to avoid being locked-in and because other cloud providers have much to offer. While Amazon delivers many great benefits, other cloud providers have differentiated based on compliance, service level agreements, dedicated environments, storage capabilities, connectivity options, and support. They’ve implemented their infrastructures and APIs around these areas of differentiation. They’re unlikely to want to adopt a general industry standard since in many ways this commoditizes what they’ve built and limits their innovation.
One of the problems with any cloud standard is that making it work is fraught with controversy and technical complexity. A cloud computing “standard” involves more than a single API or format; it includes a number of elements that together define how the cloud works. For Amazon, this includes the AMI virtual machine format, their EC2 API that defines cloud operations, as well as their storage APIs, which come in two flavors: S3 and EBS. Other clouds have their own set of APIs and formats, developed to reflect their infrastructure characteristics and needs of their target market. VMware, for example, has its vCloud API as well as its own physical machine description (VMX) and storage unit (VMDK). There’s a spectrum of technologies in play that cloud providers and enterprises would first have to agree to, and then do a lot of heavy lifting in order to comply. I have yet to see a compelling reason that would justify their time and cost.
Of course, Amazon isn’t actively promoting a standard, they’re just “doing their thing” — offering their cloud services to whoever is willing to pay for them, and continuing to innovate in the cloud. I suspect they’re content to leave well enough alone and let the market take its course, and we'll continue to see innovations in everything from billing to cloud infrastructure from them.
The irony behind this standards debate is that CloudSwitch technology makes it largely irrelevant. The days when using a cloud meant binding yourself to a provider’s proprietary architecture are over. Cloud providers can innovate for their market segments, and customers can choose the best solution without fear of lock-in. Why go backwards? CloudSwitch customers know better.
Reader Comments
-
Kin Lane
July 07, 2010 2:00 PM | Permalink
Great post. Google has kind of given the nod that Amazon S3 API is the cloud data storage API standard by adopting it for Google Developer Storage.
So I think there is some weight to saying that Amazons model could be a starting point for a standard.
Although I'd agree with you, I think that would be very short sighted. Using it as "starting point" would open up interoperability and further escalate cloud computing adoption.
But I fear with just the big boys leading the standards definition a lot of innovation is left out and could hurt the industry overall.
Its great to at least see discussion around cloud standards.
-
Eirikur Hrafnsson
July 07, 2010 2:41 PM | Permalink
Good post Ellen and nice meeting you at Structure :)
In our real world experience of talking to partners we confirmed our belief that the AWS API's are what developers want to build on so we have support for them in Greenqloud AND offer additional API's. I think any cloud provider will be shooting themselves in the foot by not supporting AWS compatible API's. So for us it's a matter of making it easier on the developers to support us and for users to switch from Amazon or to scale out to our carbon neutral cloud using products like CloudSwitch.
cheers
Eirikur Hrafnsson, CEO
http://greenqloud.com
The World's First Truly Green Public Compute Cloud -
Robert Jenkins
July 11, 2010 3:32 AM | Permalink
Dear Ellen,
Your article highlights some key issues surrounding creating a 'standard' API. The actual notion that a standard can can exist does assumes of course that a common feature set and approach to cloud computing is possible and desirable. Especially at the IaaS level, this is highly problematic. Amazon have taken one approach but it is not necessarily the optimal one. Also, by adopting a standard you exclude and limit innovation in a very real way. Standards are attractive but the simple fact is they protect incumbents and discourage real innovation. At such an early stage in the development of infrastructure-as-a-service is that what we really want?
There are many examples of very similar areas which don't have standards, web hosting being a very obvious one! In terms of just some of the major limitations that adopting Amazon's API would entail they include:
- fixed instant sizes as defined by Amazon (an arbitrary restriction)
- no coverage of other account actions such as billing etc.
- no persistent servers (again completely possible and available today)
- no data encryption options
- restrictions on networking and software to match Amazon
These are just a few, there are a great deal more. The reality is that the real lock-in in clouds comes from lack of access to data and system lock-in through deliberately proprietary architecture. The time it takes to re-code some scripts to fit a new API is negligible compared with dealing with these two forms of lock-in.
In short I believe the industry and press are looking in the wrong direction with regards to trying to reduce friction between cloud providers. People should be concentrating on the ease with which data can be inputted and outputted from clouds and also highlighting when vendors deliberately adopt new arbitrary proprietary behaviours and standards when existing well adopted standards already exist. Addressing these two points can have a very real impact on the ability of customers to switch between clouds.
Finally, companies abstracting customers from proprietary APIs are by far the best approach to allowing customers to develop for one platform and benefit from multiple clouds.
Kind regards,
Robert
Co-Founder
CloudSigma
http://www.cloudsigma.com -
Sayak Saha
December 30, 2010 5:20 AM | Permalink
Hi All,
Thanks a lot for the wonderful article.
I was just wondering and having few doubts related to the role of "Cloud Standards" in "Cloud Billing Model".
a) If a vendor is using cloud infrastructure from two different vendors like my primary data is getting stored in cloud1 and I am taking a backup in cloud2, What aspects in standards needs to be considered.
b) Is any of these standards talking about cloud billing model? Presently options include pay based on space usage or i/o operations etc. The i/o units may change based on i/o protocol used like nfs, cifs, iscsi or fc. How to tackle such situations?
Please suggest and share your views.
Regards,
Sayak.
