Open Stack

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.


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

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--------------------------------------------------------------------------