[OpenStack Foundation] The two types of interoperability
troy.toman at rackspace.com
Wed Feb 5 16:44:46 UTC 2014
> On Feb 5, 2014, at 6:05 AM, "Thierry Carrez" <thierry at openstack.org> 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.
> 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 think this is the right conversation to have around the goal of interoperability. I think it is important to note that it was decided to NOT focus on interoperability in the initial phases of DefCore but to just try and solve the branding issue. Based on the feedback, it feels like the most pressing issue really is around interop and we should wade into that sooner rather than later even if it is (or maybe because it is) messy. As I said earlier, I also don't think it is helpful to try and solve both with one label or brand.
Given all that, I am very supportive of taking simpler first steps and "learning" our way into this. I think it is more likely to not only yield progress sooner but get us to the proper endpoint faster too. Making tangible progress on making federation/convergence is critical for OpenStack in 2014 IMHO. Or, if we can't line up on that goal, then let's be explicit and stop setting that expectation. I really hope we can do the former. I'm not sure what a loosely-coupled set of clouds does to change the landscape.
> Thierry Carrez (ttx)
> Foundation mailing list
> Foundation at lists.openstack.org
More information about the Foundation