On 13/07/17 23:32, Fei Long Wang wrote:
I agree with Zane for most of the parts. But one thing I don't really
understand is, why OpenStack community is still confusing at the IaaS,
PaaS and SaaS, does the classification really mater at nowadays? Do we
really need a label/tag for OpenStack to limit it as an IaaS, PaaS or
SaaS? I never see AWS says it's an IaaS, PaaS or SaaS. Did Azure or
Google Cloud say that? I think they're just providing the service their
customer want.
I sort-of agree that it shouldn't matter. But we do need to communicate
clearly, and those terms commonly come up, and if we don't have a shared
understanding of what they mean then we're going to be talking past each
other a lot.
So a common thing for folks to say is that OpenStack should concentrate
on IaaS, not PaaS. And this is fairly widely agreed-upon. Even I mostly
agree!
AWS has a PaaS. It's called Elastic Beanstalk. I don't hear about it
much. Without having seen numbers for any of them, I would guess that
there are far more users using PaaS services that run on top of AWS's
IaaS (e.g. Heroku, OpenShift Online) than there are using Elastic
Beanstalk. Google's PaaS (AppEngine) hasn't been a runaway success
either. That's a good argument for leaving PaaS to other open source
projects - it's a complex space with lots of innovation happening and
there's no reason to think that we need to pick only one and control it.
Unfortunately, when a lot of people say OpenStack should do "IaaS only"
they don't mean "equivalents of basically anything that AWS does except
Elastic Beanstalk is fair game", they mean "only the equivalents of EC2,
VPC, and EBS are fair game". This, they believe, will lead to the holy
grail of a "small, stable core", presumably predicated on the following
assumptions:
* The pool of OpenStack developers is a fixed resource, and if we make
it clear that some projects are unwelcome then their developers will be
reassigned to 'core' projects in a completely zero-sum process. (Nnnnnnope.)
* While code like e.g. the Nova scheduler might be so complicated today
that even the experts routinely complain about its terrible design,[1]
if only we could add dozens more cooks (see above) it would definitely
get much simpler and easier to maintain. (Bwahahahahahahaha.)
* Once we make it clear to users that under no circumstances will we
ever e.g. provide them with notifications about when a server has
failed, ways to orchestrate a replacement, and an API to update DNS to
point to the new one, then they will finally stop demanding
bloat-inducing VMWare/oVirt-style features that enable them to treat
cloud servers like pets. (I. don't. even.)
That's a... ahem... let's just say it's a difficult case to make, but
it's much easier to say "OpenStack should just be IaaS" and let everyone
substitute in their own different definitions of IaaS and nod in
agreement. So the terminology is unlikely to go away ;)
cheers,
Zane.
[1] https://twitter.com/jaypipes/status/885278601821769728
On 14/07/17 05:03, Zane Bitter wrote:
On 29/06/17 10:55, Monty Taylor wrote:
(Incidentally, I think it's unworkable to have an IaaS without DNS.
Other people have told me that having an IaaS without LBaaS or a
message queuing service is unworkable, while I neither need nor want
either of those things from my IaaS - they seem like PaaS components
to me)
I resemble that remark, so maybe it's worth clarifying how I see things.
In many ways the NIST definitions of SaaS/PaaS/IaaS from 2011, while
helpful to cut through the vagueness of the 'cloud' buzzword and frame
the broad outlines of cloud service models (at least at the time),
have proven inadequate to describe the subtlety of the various
possible offerings. The only thing that is crystal clear is that LBaaS
and message queuing are not PaaS components ;)
I'd like to suggest that the 'Platform' in PaaS means the same thing
that it has since at least the '90s: the Operating System and possibly
there language runtime if any. The difference between PaaS and IaaS in
terms of compute is that in the latter case you're given a machine and
you install whatever platform you like on it, while in the former the
platform is provided as a service. Hence the name.
To the extent that hardware load balancers are used, LBaaS is pretty
clearly IaaS. Hardware is infrastructure, if you provide access to
that as a service it's Infrastructure as a Service. QED. It's also
possible to provide software load balancers as a service. Technically
I guess this is SaaS. Theoretically you could make an argument that an
API that can abstract over either hardware or software load balancers
is not "real" IaaS. And I would label that argument as BS sophistry :)
The fact that PaaS implementations use load balancers internally is
really neither here nor there.
You can certainly build a useful cloud without LBaaS. That just means
that anybody who needs load balancing will have to spin up their own
software load balancer to do it. But that has a couple of
consequences. One is that every application developer has to build
their own orchestration to update the load balancer configuration when
it needs to change. The other is that they're stuck with the least
common denominator - if you use one cloud that doesn't have an LBaaS
API, even one backed by software load balancers, then you won't be
able to take advantage of hardware load balancers on another cloud
without rewriting a chunk of your application. That's a big concern
for OpenStack, which has application portability as one of its
foremost goals. Thus an IaaS cloud that includes LBaaS is considerably
more valuable than one that does not, for a large range of very common
use cases.
This is pretty much the same argument as I would make for DNSaaS.
Without it you're developing your own orchestration and/or manually
updating stuff every time you make a change in your infrastructure,
which pretty much negates the benefits of IaaS for a very large subset
of applications and leaves you stuck back in the pre-aaS days where
making any changes to where your application ran was slow and painful.
That's despite the fact that DNSaaS is arguably pure SaaS. This is
where the NIST model breaks down IMHO. We tend to assume that only
stuff that faces end users is SaaS and therefore everything
developer-facing has to fall into either IaaS/PaaS. This results in
IaaS developers treating "PaaS" as a catch-all bucket for "everything
application developer-facing that I don't think is infrastructure",
rather than a term that has meaning in itself.
This confusion leads to the implicit argument that these kinds of
developer-facing SaaS offerings are only useful to applications
running in a PaaS, and therefore should be Someone Else's Problem,
which is WRONG. It's wrong because different parts of an application
have different needs. Just because I need to tweak the kernel
parameters on my app server, it doesn't follow that I need to tweak
the kernel parameters on my load balancer, or my database, too. It
just doesn't.
At one level, a message queue falls into the same bucket as other SaaS
components (like DBaaS, sometimes LBaaS, &c.). Something that's useful
to a subset of applications running in either an IaaS or a PaaS. The
subset of applications that would use it is probably quite a bit
smaller than the subset that would use e.g. LBaaS.
However, there's also another dimension to asynchronous messaging in
particular. If a cloud needs to notify an application about events in
or changes to its infrastructure, then if it has a built-in *reliable*
message queue API it can reuse it to deliver these notifications.
(Actually, I would put it the other way around: if a cloud has an API
to deliver messages to applications from the infrastructure, it can
also allow applications to reuse this capability for their own
purposes.) Again, you can certainly have an IaaS cloud that doesn't
provide an asynchronous messaging capability. But it will necessarily
be very limited (no way to proactively inform applications about
infrastructure events), or poorly designed (lots of different places
and ways to poll), or both.
I hope that clears things up :)
cheers,
Zane.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
