In the past few months I have been discussing the emerging state of cloud standards. Cloud users are asking when cloud computing standards will be mature enough so that more companies will feel comfortable implementing cloud architectures and using cloud services without feeling vendor lock-in.
Ironically, while the commercial cloud offerings have been growing—built on the very standards that created the Internet itself—Amazon and others have been notoriously loathe to publish details about their underlying architectures, claiming the need for security. This has led to rampant speculation and educated guesses in the blogosphere about Amazon’s AWS architecture.
On his blog Floyd Strimling at Zenoss recently wrote Wrong Strategy: 5 Ways Not to Compete with Amazon AWS, which explains why he thinks it doesn’t matter. Others are of the opinion that maybe we should be embracing vendor lock-in rather than attempting to avoid it. Orlando Scott-Crowley in The Great Cloud Vendor Lock-In Fallacy describes why he is convinced the entire vendor lock-in debate is largely a red herring.
Whatever side you are on in this argument, there are a couple of obvious questions to ask: Is there an opportunity for a commercial cloud IaaS service to become a standard? Is Amazon the right IaaS standard platform to use for this purpose?
Certainly there have been several precedents where formerly proprietary data formats, such as VMDK (Virtual Machine Disk) originally developed by VMware, have become actual standards by simply being widely adopted by the industry. Another older example is the now standard DXF (Data Exchange Format) pioneered by AutoDesk, which allows users of other CADD systems to migrate their files to their AutoCAD software. In the cloud world, the closest analogy is the recent calls to deem Cloud Foundry the PaaS standard.
One could even argue that Amazon’s AWS IaaS service is already the de facto standard for the industry. After all, Amazon has a fifteen-year jump on the competition with millions of users and apparently more than 30 million virtual machines in their data centers.
There have been several attempts to create an Amazon-like Open Source project. The most “successful” one is Eucalyptus, which originally started as a project to reverse-engineer AWS. Now that Amazon is fully backing the company, it is not clear that this makes it a viable standard, but it does offer an attractive option for companies that want to build what Amazon euphemistically calls on-premise services.
The biggest difference in attempting to set Amazon as an IaaS standard is—unlike VMware, AutoCAD, or even Microsoft—Amazon is providing a publically available subscription service, not a product that will be used internally. Until now it has not been in Amazon’s best interest to provide even an interoperability capability, much less a standard that will allow companies to share applications and data across different clouds.
Other than the perception that there is a rising threat from the growing number of enterprises that are building private clouds, which Amazon is presumably addressing through Eucalyptus, I just don’t see a strong case for them to gain market share by setting up their architecture as an IaaS standard. Yes, you are more than welcome to use Amazon’s well-documented API, but that does not guarantee true interoperability with Amazon or any other cloud vendor.
In the end, cloud standards—however we eventually arrive at them—should only help increase the uptake of cloud services across a wide range of industries. But I am not convinced that using Amazon as a IaaS standard is the right approach.
Beth Cohen is a senior cloud architect for Cloud Technology Partners, delivering solutions to help enterprises leverage the efficiencies of cloud architectures and technologies. Beth was director of engineering IT for BBN Corporation, was involved with the initial development of the Internet, and worked on some of the hottest networking and web technology protocols in their infancy.