Open Stack

Mark McLoughlin wrote:
> To put the question another way - which helps users more? The ability to
> write interoperable code which uses a large number of OpenStack APIs,
> but which is only actually interoperable between a small number of
> OpenStack clouds? Or interoperability whereby you have a smaller set of
> interoperable APIs, but code that uses only those APIs would be
> interoperable with a much larger number of OpenStack clouds?

I like your way of framing the question.

Personally I think going for loose interoperability is short-sighted.
Yes you'll have a lot of providers but you'll forever have a bad
experience moving workloads around.

With total interoperability, you may have less providers at start, but
at least they provide a great experience moving workloads around. And as
more join them, it only gets better. Total interoperability is basically
the only way to potentially reach one day the nirvana of "lots of
providers + great end user experience".

The trick is to bootstrap it. If you have 0 or 1 "true openstack" cloud
available at first, it's hard to get any benefit from that hypothetical
federation. Total interop requires a bit of a leap of faith.

So yet another way to frame that discussion (at board level) is: are you
more interested in convergence and federation (and beating Amazon all
together), or are you more interested in competing (and be a set of
individual loosely-coupled small competitors to Amazon).

-- 
Thierry Carrez (ttx)