It is a good sign that Google has decided to expose their Storage API based on Amazon S3 API. Eucalyptus Walrus Storage API is completely compatible with S3.
There has been a discussion on standardizing the API for the Cloud Storage. What fueled this discussion further is a poll that ReadWriteWeb.com ran on their site.

Let’s get back to the original discussion on Cloud Storage API standards.
If we look back in history, the industry faced exactly the same challenge in the late 80s when the RDBMS market started to explode. Businesses didn’t want to suffer from lock-in and developers wanted flexibility at the API level. During the transition from monolithic to Client / Server, Open Database Connectivity (ODBC) became the de-facto standard. Every DB vendor shipped their own libraries that adhered to the ODBC standard and developers could switch the libraries at runtime to talk to multiple databases. The front-end applications were completely insulated from the back-end.
For Cloud, we fortunately have the standards as the Lowest Common Denominator. What is common across all the APIs is that they are based on HTTP, REST, XML and SOAP. That makes it easy for abstractions to surface. What we need now is a Cloud version of ODBC. Let me take the risk of calling this as Open Cloud Storage Connectivity API. I am visualizing an architecture that looks something like this:

This is based on the factory method pattern which is used by many enterprise architects. With this, a change in the configuration file will load the appropriate library for the target Storage service. This will be transparent to the Cloud Storage Consumer.
I already see this coming! Take a look at jClouds and Apache libcloud . The future of Cloud Storage is bright and exciting! What do you feel about the standardization of the Cloud Storage API?







