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!

I don't know if there is an inherent difference of approach in terms of what cloudcenters need to do differently from infrastructure web services. My guess is that there is not a significant difference there. Both need to find ways to allow not only clear transparent metering, but very granular (down to a 'user' or 'department') billing capabilities.

Thanks for your great question.

–Randy

Thanks for asking. Cloudcenters are obviously *not* datacenters so there will be quite a few areas of divergence. Some that come to mind off the top of my head:

– Less control over border network infrastructure (i.e. you don't control the upstream routers, only your switch and load balancers)
– You will have to replace network automated installation systems like Kickstart/Jumpstart with virtual machine image mgmt processes
– Need for robust command line scripting tools to allow sysadmins to deliver the automation they are accustomed to
– Access to the 'console' is usually unavailable
– Related, there's a need to 'think different' about servers; the advent of disposable IT (e.g. some times it's easier to throw away a broken server and re-launch rather than to 'fix' it)
– Cloud storage will have nuances about how it is handled differently from typical IT storage infrastructure

I'm sure there is more.