[OpenStack Foundation] The two types of interoperability

Randy Bias randyb at cloudscaling.com
Fri Feb 7 02:52:45 UTC 2014


Folks,


	I still struggle with this entire conversation.  Linux is not interoperable, how do you expect OpenStack to be so?  RHEL is interoperable with RHEL/Fedora/CentOS.  SUSE with SUSE and so on.  Debian and Ubuntu perhaps more so than most Linux distros.  Take an app you wrote on Cray Linux and run it on Android.  Or recompile it for Android even.  It may run, but it’s certainly not guaranteed.

	The simplest example I can think of: HP vs. Rackspace Public Clouds.  HP has chosen a “flat" network scheme.  Rackspace has chosen the “multi_host” option.  On HP, each VM has one NIC.  On Rackspace, they have two NICs.  If you build your app around one assumption vs. the other, then portability becomes difficult, regardless of the APIs in use.  That forces you as the app owner to figure out the differences between these two clouds, regardless of them both being OpenStack and having the OpenStack APIs.

	This is only the simplest example.  There are dozens of these kinds of situations where architectural design decisions directly impact application portability and the API is irrelevant.

	I see it as a simple issue: we either stifle choice OR we facilitate choice and compromise on interoperability.

	I don’t think compromising on interoperability means there is no interop, but more of a baseline of interoperability that is a lowest common denominator (an SQL92 equivalent if you will) and then additional interoperability between “flavors” of OpenStack.

	It took years for IPSEC, which was a standard protocol, to actually have decent interoperability and I would argue it’s still difficult.  This is largely because of the amount of choice that was available, which caused complexity.  Choice is the enemy of interoperability.  Choice seems like it has been a key defining attribute of OpenStack.  How can we continue to enable choice, while searching for interop.  The only solution I see is the one I’m proposing (above).  You can try to dictate to the community what they should build, but I can’t see a way that is successful in the long term.  Instead you are likely to cause forks.

	Linux is significantly more mature than OpenStack and the Linux Standard Base (LSB) still struggles to unify the various Linux distros in a way that guarantees application portability.  We should be focusing more on driving DefCore to conclusion, building a lowest common denominator baseline, and then figuring out what the “flavors” of interop are above that.

	Just my $0.02.



--Randy

Founder & CEO, Cloudscaling
Board of Directors, OpenStack Foundation
+1 (415) 787-2253 [SMS or voice] 
TWITTER: twitter.com/randybias
LINKEDIN: linkedin.com/in/randybias
CALENDAR: doodle.com/randybias









On Feb 5, 2014, at 4:04 AM, Thierry Carrez <thierry at openstack.org> wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/foundation/attachments/20140206/5dada251/attachment-0001.html>


More information about the Foundation mailing list