Why Amazon Compatible API is not a Good Idea

When Google Storage for Developer came out, it came out with an Amazon S3 compatible API. There are also other service providers do the same thing.

The logic was simple. If Amazon S3 is the leader, by providing an S3 compatible API, the cloud storage provider attracts existing S3 communities and existing S3 developers.

Initial thought, it is a good move. But wait a second…

Can you really be S3 compatible?

S3 is a moving target, it has 4 regions support in the API, do you? It has version support now, do you? It has pause/resume multi-part upload now, do you?

Since cloud storage is new and there are many features that can be added, trying to be S3 compatible and S3 will leave you behind.

When an ISV (independent software developer) updates its tools to support the latest S3 features, the update could break the compatibles.

The devil is in the details

If you claim you are S3 compatible and the developer’s tool breaks, a typical developer will claim his tool works perfectly with S3. You are left with the burden to be compatible.

There are many small details when it comes to implementation.  For example, if an upload is broken in the middle, is the upload atomic on the backend? If S3 does it one way, do you need to follow? In S3, you can create a zero byte file with name ended in ‘/’ to represent folder, do you need to follow?

When JAVA started, the goal was simple, write once and deploy everywhere. However, when it started, it was write once and debug everywhere. The devil is in the details.

Who benefits more?

If you are compatible, why people don’t just go S3 directly? First you acknowledged that S3 is superior. Second, you are just a compatible. At the end of the day, it strengthen S3’s position and weaken your own position long term. 

Apple’s Mac continued to be different from Windows. Linux continued to be different from Windows. Neither claim that they have Windows compatible API. Being different is also good.

What could be a good move?

Open Stack could be a good move. If you were a king in the Open Stack community, it is far better than S3-Compatible. The market will always pick a #2 in any category, including cloud storage. being something different in the open source community has  a better chance to be the #2 to Amazon S3.

Providing API libraries could be a good move. You can have your own APIs, with C#, Python, Perl, Ruby libraries supporting your own cloud storage APIs. Making developer’s life easy, they will support you.

Providing similar API but different enough. For example, Windows Azure Blob storage is both similar and different. By not claiming S3-compatible, it forces developers to maintain a separate code base.

 

Related Post

Google Storage, Where is the Attack Point

OpenStack Windows Client

Gladinet Cloud Storage Access Solutions

Comments

Mark said…
Or you could just implement an existing cloud storage standard. See http://www.sniacloud.com/?p=25
CentreStack said…
A standard without big company behind it will be difficult to deploy. It requires either a group of big company supporting it or a big open source community supporting it. The majority wins. However, like you said, if the majority controls the IP, it is trouble too.

Popular posts from this blog

7 Biggest Limitations of SharePoint Online And How to Fix Them

5 Reasons CentreStack's File Server Mobilization Beats File Server Migration

Access and Backup to HP Cloud Storage