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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
