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
