Should Amazon Define Cloud Standards?

Since Citrix gave Cloudstack to the Apache Software Foundation, there has been a lot of blogging, tweeting, and arguing about whether cloud computing software vendors should simply let Amazon AWS drive cloud computing standards. It's time for the stakeholders--enterprises, vendors, open source projects, and anyone else interested to start scoping, developing, and implementing standards that everyone can use.

Mike Fratto

April 7, 2012

6 Min Read
NetworkComputing logo in a gray background | NetworkComputing

Since Citrix gave Cloudstack to the Apache Software Foundation, there has been a lot of blogging, tweeting, and arguing about whether cloud computing software vendors should simply let Amazon AWS drive cloud computing standards. My answer is no. First, I don't think Amazon even wants to be the standard and second, standards should be developed independently of any single vendor. It's time for the stakeholders--enterprises, vendors, open source projects, and anyone else interested to start scoping, developing, and implementing standards that everyone can use. If that doens't happen, the cloud landscape will continue to be fragmented to everyone's detriment.

With Amazon getting Cozy with Eucalyptus, many people, including Informationweek's Charlie Babcock, are wondering if Amazon will try to stop others from mimicking it's API in similar manner that Oracle is suing Google over the latter's use of the Java language semantics in Android. There doesn't seem to be any prohibition to mimicking Amazons API in their license agreements, but that didn't stop Citrix from pointing out that one of the benefits of using their commercial offering of Cloudstack (which is tightly integrated with AWS), is indemnification of its use in the case of legal action, presumably from Amazon.

The big question being debated, without Amazon taking a position what so ever, is what the company should do with their API. Dan Woods writes in Forbes that there are three Questions Amazon Should Answer About Its Cloud Strategy 1) Are there limits to the use of Amazon's APIs? 2) How will community experience inform the evolution of Amazon's APIs? And 3) What is the process that will govern the evolution of the Amazon APIs?

Those are good questions that you should ask any company you integrate your business systems with or depend upon, but why should Amazon answer them publically? I am not even sure that Amazon was ever asked, cares, or even wants their API's to be the defacto standard, and thus their product plans and roadmaps are their own business to share with whomever they like. I do think that if Amazon answered some of those questions, that would place them squarely in a cloud standards leadership role and would be good for everyone, but that is their choice.

Being the curious kitten that I am, I asked Amazon if they think they are, or should be, the stewards of cloud API standards. I received a circumspect answer from an AWS representative who said "Standards have been talked about for years in web services. We believe standards will continue to evolve in the cloud computing space. What we've heard from customers so far--customers who are really committed to using the cloud--is that the best way to illustrate openness and customer flexibility is by what Amazon Web Services actually provides and delivers for them. We'll continue to pursue an approach of providing customers with maximum flexibility as the standards discussion unfolds."

Barb Darrrow thinks that the cloud API debate is over. I don't. I think it is just beginning because companies, potential customers, are just starting to get to the point of sophistication where they can even consider API's. And also disagree with CSC's Simon Wardley who thinks any cloud software that doesn't support/implement/mimic Amazons AWS API's are doomed to failure because Amazon may be the big player in cloud right now. There is no guarantee that they will remain dominant for long. There are lots of other cloud providers coming on-line.

"I think that some de-facto standards, or perhaps benignly neglected intellectual property, can be helpful, but only as long as the owner of said intellectual property don't get crazy about enforcing their IP. And that, of course, is what makes them de-facto standards. VT100, WY-60, FAT32 and PCL 5 were actually helpful in pushing the mission forward without getting hung up in committee for eleventy-billion months. And I think that is a valuable service to the community," Jonathan Feldman who is a director of IT Services for a rapidly growing North Carolina city said.

Frankly, I think if Amazon attempts to stop others from using or mimicking AWS's API, Amazon would be clearly stating they want to be a walled garden and the customer backlash from real or imagined lock-in would be swift.Let's consider some proprietary technologies that became standards (independent or defacto) that we are living with today. SQL started out life being developed by IBM, [1] [2] [3] and was subsequently picked up by Relation Software (now Oracle) and eventually IBM itself. SQL was made into an ANSI project in 1986. There were other languages available but for good or ill, we have SQL. The Win-Tel franchise dominated servers and desktops, still does, in enterprises and that meant software developers where writing to that platform.

Justin Santa Barbara compares Amazons AWS API's to Microsoft Win32 API in The Apache Elephant Graveyard pointing out that projects like WINE, a Windows emulator, tried to implement and keep up with changes to the Win32 API. The alternative to Win32 was Portable Operating System Interface (POSIX), but that never really took off for Windows. And let's not forget Microsoft's Office document formats which are closed, but were, and are, often mimicked with varying degrees of success.

Chasing a vendor API is foolish. Even if that vendor is a good steward of their own API's, which Amazon appears to be.

According to Enstratus CTO George Reese who has seen it all while integrating 14+ cloud services into his company's management service, Amazon is a good steward of their own API's. "AWS APIs are the ugliest APIs on the market. But they are the most reliable. I define reliable as first not breaking between versions and second having full feature coverage. Amazon has never broken API compatibility. Never," he said in a conversation on Twitter. Randy Bias, CTO and co-founder of Cloudscaling, concurs.

API changes can weak havoc on customers and services that rely on them. I asked if Amazon feels increased pressure to not change the API or at least do so in non-disruptive ways and they said "With the number of customers relying on AWS, we take great care to ensure that any changes we make to the services – API or otherwise – do not disrupt customers' architecture or applications."

Frankly, the cloud software vendors and open source projects in the world could easily just by-pass Amazon and be highly successful. There are enough requirements that any creative company could provide critical services. While companies like Enstratus and Rightscale ease inter-cloud management (among other things) and cloud software like Cloudstack and Openstack want to integrate where possible, they do much more than simply gluing stuff together. While I haven't asked them if they would rather spend their time integrating cloud services or developing their own services, I am going to bet that they'd rather do the latter. In fact, I agree whole heartedly with Wardley's assertion that cloud vendors should focus on differentiating on features and not API's. Having an openly developed standard clear of IP issues and implemented by a majority of vendors and service providers would be far more useful than hitching the cloud standards wagon to a disinterested third party like Amazon.

References, right?
[1] History of SQL
[2] Wikipedia: SQL
[3] SELECT * FROM SQL History

About the Author

Mike Fratto

Former Network Computing Editor

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights