Open Stack

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:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>