[OpenStack Foundation] The two types of interoperability

Mark McLoughlin markmc at redhat.com
Wed Feb 5 12:14:20 UTC 2014

On Wed, 2014-02-05 at 13:04 +0100, Thierry Carrez wrote:
> 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.

Right, it's about bootstrapping - I'm all for total interoperability,
but feel it will need to be "looser than total" in order to bootstrap

> 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).

I'd hope there would be consensus around convergence and, if so, I'd
like to see a discussion about bootstrapping tactics.


More information about the Foundation mailing list