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


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to