Open Stack

On 18/04/17 10:39, Flavio Percoco wrote:
> On 16/04/17 09:03 +0100, Neil Jerram wrote:
>> FWIW, I think the Lego analogy is not actually helpful for another
>> reason: it has vastly too many ways of combining, and (hence) no sense
>> at all of consistency / interoperability between the different things
>> that you can construct with it. Whereas for OpenStack I believe you
>> are also aiming for some forms of consistency and interoperability.

I agree that this is another important limitation of the analogy.

> Could you expand on why you think the lego analogy does not cover
> consistency
> and interoperability?

This is one of the interesting ways in which building an application 
with multiple independently-governed deployments (like OpenStack) 
differs from building a hosted service (like AWS).

So if you look at https://aws.amazon.com/products/ there is currently 
somewhere north of 90 services listed. Despite this, literally nobody 
ever says things like "Wow, that's so many services... do I have to use 
all of them?" Because it's obvious: as an application 
developer/deployer, you use the ones you need, you don't use the ones 
you don't, and there's no problem. (People, of course, *do* say things 
like "Wow, that's so many services, how do I find the one I need?" or 
"What does all this stuff do?" or "What do all these silly names mean?")

Now with OpenStack, operators look at 
https://www.openstack.org/software/project-navigator and say "Wow, 
that's so many services... do I have to use all of them?" And for the 
most part the answer ought to be equally obvious: install the ones that 
application developers deploying to your cloud need, and not the ones 
they don't. (Strangely, though, we don't often talk about application 
developer needs... OpenStack is largely marketed to operators of clouds, 
with the apparent assumption that application developers will use 
whatever they're given. IMHO this is a colossal mistake - it's the exact 
mechanism by which a lot of really *very* bad 'Enterprise' software has 
gotten developed over the years.)

However, there's a subtlety to it: with a single hosted service, all the 
stuff is already there, and if you want to start using it you just 
start. With multiple deployments, the thing you want may or may not be 
there, or it may be there on only some of the clouds you want to use, or 
it may not even get properly integrated at all.

So, for example, AWS services can all deliver notifications to SNS 
topics that application developers can reliably use to e.g. trigger 
Lambda functions when some event occurs. If you don't need that you 
don't use them, but when you do they'll be right there. (Azure and 
Google also have equivalent functionality.)

OpenStack has equivalents to SNS & Lambda for these purposes (Zaqar & 
Mistral), but they're not installed in most clouds. If you find you need 
them then you have to beg your cloud operator. Even if that works, 
you'll lose interoperability with most other OpenStack clouds by 
depending on them. And in any event, hardly any OpenStack services 
actually produce notifications for Zaqar anyway because most people 
assume that it's just a layered service that only a small class of 
applications might use, and not something that ought to be an integral 
part of any cloud.

Meanwhile in unrelated news, it's 2017 and Horizon still works by 
polling all of the things all of the time.

There certainly exists a bunch of stuff that you can just layer on - 
e.g. if you need Hadoop as a service you should probably install Sahara, 
and if you don't then it won't hurt at all if you don't. But the set of 
stuff that needs to be tightly integrated together and present in most 
deployments to yield an interoperable cloud service is considerably 
larger than just what you need to run a VPS, which is all that we've 
really acknowledged since the start of the 'big tent' debate.

If we treat _everything_ as just an independent building block on top of 
the core VPS functionality then we'll never develop the integrated core 
*cloud* functionality that we need to attract application developers to 
the platform by choice (and hopefully convert them into contributors!).

cheers,
Zane.