SaaS, PaaS and IaaS explained in one graphic | Hacker News Reader

SaaS, PaaS and IaaS explained in one graphic

m.oursky.com

78 pointsashitlerferad21 comments

Open articleView on HN

- 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.

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

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

> 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.

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).

The quote "if you can't explain it simply you do not understand it" has been mis-attributed to Einstein or Feynman in various iterations; whomever said it, the point stands. Analogies help people understand the layers of things, especially for something as abstract at software. Software devs often struggle to explain the difference between containers, PVM, and HVM. It has nothing to do with a person's intelligence, MBA, or sales, otherwise.

Pizza is both tasty and fun - relating complex "serious" dry and boring work stuff to something else is a time-honored teaching technique.

I've been an IBM intern for the last 4 months and I can say that even there they've used the pizza example.

I honestly didn't get it until an actual IT architect explained it to me with real-life IT example. (I'm a SW programmer, not MBA btw).

For them to understand, you'd have to reduce the problem down to square pegs and round holes.

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.

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".

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

This is already outdated! Here's the 2.0 update https://media.licdn.com/mpr/mpr/AAEAAQAAAAAAAAtXAAAAJDJkNTlm...

Original source and context here: https://www.linkedin.com/pulse/pizza-service-20-paul-kerriso...

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"...

> why does beer mean "scaling"

Because of the Ballmer Peak. https://xkcd.com/323/

You got me :)

If there's a pizza parallel for CaaS, it's microwave pizza. Doesn't matter what microwave you put it in as long as you put in the right settings (cough, environment variables, cough) and cooks up much quicker than pizza put into traditional ovens - of course, you pay a price for sharing the same microwave mechanism (cough, kernel, cough) across many different recipes, leading to concerns about taste (cough, secure isolation, cough) etc., but for many people its speed and ease-of-use make it worth it.

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...)

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.

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.

All is well if you are cooking pizza. But if you are cooking meth, the kitchen the XaaS provide will not do any more.

Full stacks are legacy unless you need them customized. For example, not everyone is doing the horizontal scalability trick.

In the large enterprise, Oracle on one big iron is common, so common the newest versions actually concentrated improvements for those use cases, unlike what the marketing department keeps advertising.

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.

Reply on news.ycombinator.com