
SaaS, PaaS and IaaS explained in one graphic - ashitlerferad
https://m.oursky.com/saas-paas-and-iaas-explained-in-one-graphic-d56c3e6f4606
======
jondubois
\- SaaS is for those who can't code.

\- BaaS is for hackathon participants.

\- PaaS is for web developers.

\- IaaS is for software engineers.

\- On-premise is for dinosaurs.

~~~
athenot
Even though this might ruffle some feathers by making broad generalizations,
it's a better explanation than the pizza analogy in the article.

------
justin66
I am pretty sure the point of these graphics is to get people deeply pondering
what the #*#$ "drinks" represent in the analogy and, while they are staring
into space, sneak up on them and steal their wallet.

------
TheMagicHorsey
Why don't people just explain it with actual computers instead of pizza? MBAs
are not that dumb.

~~~
visakanv
> Why don't people just explain it with actual computers instead of pizza?

People use mental models and heuristics and metaphors to make sense of all
sorts of things. Very smart people do this, too.

Simplified maps can have their uses, even when you might personally be
comfortable with a more complicated one.

~~~
TrickyRick
In this case however it just makes it more complicated, especially when the
matter at hand can be as easily described as here. Basically it's a layer
model, Software (SaaS) is built on Platforms (PaaS) which is build on
Infrastructure (IaaS).

------
bonzini
I have just realized that all the time I have been reading the pizza-as-a-
service graph the wrong way (that is, the way the author suggests instead).

This is the key point: "The [original graph] doesn’t allow customization,
which is what IaaS and PaaS offer".

~~~
david90
The way interpreting PaaS as "user managing the table and soda" actually does
not help explaining (in the original version)

------
andrenotgiant
This is already outdated! Here's the 2.0 update
[https://media.licdn.com/mpr/mpr/AAEAAQAAAAAAAAtXAAAAJDJkNTlm...](https://media.licdn.com/mpr/mpr/AAEAAQAAAAAAAAtXAAAAJDJkNTlmYTQwLWY2YmQtNGM4Zi04Nzg0LTRjOTczYzI5MjE0NA.jpg)

Original source and context here: [https://www.linkedin.com/pulse/pizza-
service-20-paul-kerriso...](https://www.linkedin.com/pulse/pizza-
service-20-paul-kerrison)

~~~
david90
Author here - I appreciate the 2.0 version adds the concept of "container-as-
a-service" and "function-as-a-service" in, as those are really the latest
trends. I actually agree on Traditional on-premise deployment and IaaS. But I
still find the right hand side 2.0 is not a good abstraction of X-as-a-
Service. Reason: The relationship between Conversation / Friends / Beer /
Pizza is not as such in SaaS /FaaS / PaaS and CaaS. They do not illustrate a
correct hierarchy of customization and abstraction.

Secondly, why does beer mean "scaling"...

~~~
solatic
> why does beer mean "scaling"

Because of the Ballmer Peak. [https://xkcd.com/323/](https://xkcd.com/323/)

~~~
david90
You got me :)

------
sverhagen
It says "BaaS" in one diagram, I didn't know that one. I've probably been
referring to the same as "Middleware-as-a-Service". And I'm disappointed in
it. As amazing as it still is that Amazon and friends let you spin up machines
at will, this day and age, I find us (where I work) still rolling a lot of
stuff ourselves, that I'd hope by now to be able to buy as a service inside
Amazon. (From Amazon, or from 3rd parties that integrate into your Amazon
account, somehow magically, I don't know what that model would be.) Still
we're doing our own Elasticsearch, JMS, databases (been burned on RDS), cache,
Kubernetes, and so on. Is this just a market that hasn't matured yet? (While
SaaS probably has?) Not because AWS offers nothing for it, but just because
it's quite not always the best of breed.

(Disclaimer: while we practice DevOps quite a bit, me being a Java architect,
I'm still not an operations expert, so I may well overlook something real
obvious...)

~~~
athenot
We use it for cases where we don't need that much customization. Everything
you do yourself has a maintenance cost (setup, patching, security, monitoring,
fixing state, backups...). If that component is integral to your service, roll
your own and manage it with your standard config management. If it's a
component for an auxilliary tool (say you need a backend to store some
dashboard thingy), it's better to use these middleware services.

------
Spivak
I like how being full-stack is 'legacy'. I do understand the separation of
concerns though: once you are big enough to afford a team of sysadmins and
infrastrcture people you can provide your devs in-house PaaS and IaaS.

~~~
unit91
Yeah, legacy is probably a bad term because it connotes "old". Still, there is
a sense in which this is the legacy approach: very few do it, whereas it used
to be the norm.

In fact, the only place I've ever worked that self-hosted and loved it was the
Air Force. Three other companies I've worked for haven't self-hosted at all,
and one very large, established company had an active offload-to-AWS plan.

