Open Stack

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.