Thank you for your questions. It's true that the Amazon APIs all have a SOAP interface. This is really not my point in talking about industry standards. To some degree any API demands that you use *something* that the industry uses or it won't be adopted. More important are services like S3, Amazon's Simple Storage Service. A 100% proprietary file storage system. You won't be able to have an equivalent in your own datacenter.

With regards to EC2, the Xen hypervisor is standard, but that's about it. Storage for EC2 images is in S3, a proprietary standard. The image management and description system is also proprietary. Or, at the very least, you (again) can't have it inside your datacenter. Well, perhaps you can leverage EUCALYPTUS, but their legal status on the structure of their API interfaces is almost certainly in question. More so now that they are a commercial entity. Do you want to bet the farm that Amazon won't sue given their history with '1-click shopping'?

There are two ways to look at whether a given service is proprietary or not:

1) Can you get it today in your own datacenter, infrastructure, or cloud?
2) If you write tools and software that manages the service through an API can you reuse those easily with other similar systems?

My guess is that with most of Amazon it's 'no', 'yes, but it will be painful', or similar. Amazon could choose to provide a de facto standard, but until they take a stance with regards to the legality of copying their programming interfaces and services then sticking with well known standards seems like the best bet.

Look more towards the efforts of the OGF around the OCCI standard, Sun's ZFS, and similar for real-world examples of standards or software that can be safely embraced inside and outside the cloud.

–Randy

- "Unfortunately, every service above is based on an Amazon standard, not an industry standard."
Amazon is delivering all its infrastructure services using the SOAP protocol. It is true that the parameter requirements and such are particular to Amazon as they represent Amazon's custom developed API, but from a client perspective all the services can be interrogated and invoked using an industry standard protocol. Did you mean something different here?

-EC2 provides Xen hosting, but image management and storage is completely custom.
Amazon uses a modified version of the XEN Hypervisor to effect their virtualization, and under the covers image management and storage management is custom, but it would not seem that none of that is visible or of real importance to a client of the services. Am I missing something here?

-SQS does not use any standard queuing or messaging protocols such as JMS or STOMP.
This one I get. Building an application based on Amazon's queuing system would clearly impact a client should they decide to relocate their application to another cloud provider

-SimpleDB now has an ‘SQL-like’ interface, but is essentially a 100% ground up creation of Amazon.
Ditto for this one – I think most enterprise folks will want to stick with a true SQL solution, not a non-portable look alike.

So I guess, I really just have the two items I am seeking clarification on.

Thanks, and again this was a great post!