openstack team mailing list archive

[Bryan Taylor <btaylor@xxxxxxxxxxxxx>]

But this cuts both ways: many of their clients don't immediately adopt new
changes, and if we can provide a spec for what parts of the amazon api you
have to stay within to obtain switch-ability with openstack, then we slow
down the adoption of those new features.

The clients that are happy with lock-in and already on amazon aren't going
to change to openstack anyway. But let's be clear, Amazon is not
Microsoft, and I don't think this category is the dominant one. The market
is growing and the biggest opportunity is for new adopters. It's valuable
to openstack for some new adopters to have the option to switch back to
EC2, because we are the newcomer. We also want to win some directly to the
open APIs, and convert some once they get here by offering a better
overall feature set in the open API.


On 7/9/11 9:48 AM, "George Reese" <george.reese@xxxxxxxxxxxxx> wrote:

>The other piece of the puzzle is that it is very easy to keep a client
>consistent with the API; it's very hard to keep an implementation
>up-to-date.
>
>I've built an EC2 compatible API and the problem is that understanding
>what has changed in the API (and it changes fairly frequently) is hard.
>On the other hand, AWS is great at not breaking clients. So, when they
>roll out a change, it doesn't impact clients; but anyone implementing an
>EC2-compatible API will immediately be broken for clients taking
>advantage of new features. Furthermore, it may not be entirely clear from
>your end what it is that broke things.

This email may include confidential information. If you received it in error, please delete it.