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: > [email protected]?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: [email protected] Catalyst IT Limited Level 6, Catalyst House, 150 Willis Street, Wellington -------------------------------------------------------------------------- __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
