Image for post
Image for post

Pizza as a Service 2.0

Paul Kerrison
Sep 1, 2017 · 3 min read

Recently I was trying to describe the various types of cloud services available for modern IT deployment. Like many, I resorted to an analogy — the ever popular “Pizza as a Service”.

Image for post
Image for post
Pizza as a Service 1.0

However, the more I tried to use it, the more strained it became — my main difficulties were:

  • The elements intuitively thought of as infrastructure Eg Oven, Electric / Gas and Dining Table were not provided by Infrastructure as a Service.
  • The benefit of Platform as a Service is that all the “mundane” stuff is taken care of, giving you the space to concentrate on creating great applications. In this analogy, surely that’s the pizza itself — not the drinks and eating surface…
  • With Software as a Service, the vendor appears to manage everything — so there’s nothing left for you to do. In reality, you would normally need to configure the product (even if that’s just choosing your email address or background image)
  • It also excludes some important new additions to the aaS family — in particular Functions as a Service

Not being one to overthink things(!), I decided to redraw the graphic including some recent aaSes and what I consider to be more appropriate elements to highlight the differences.

Without further ado, I give you — Pizza as a Service 2.0

Image for post
Image for post
Pizza as a Service 2.0

Now for the justifications…

  • On-Premises — like a homemade pizza, made from scratch, you do everything yourself (no change so far). Example: Datacentre
  • Infrastructure as a Service — You share a kitchen with others. The utilities and oven are provided, but you make and cook the pizza yourself. Example: EC2
  • Containers as a Service — You bring the pizzas but someone else uses their facilities and cooks the pizza for you. Example: ECS
  • Platform as a Service — You order a pizza for collection, the pizzeria make and cook the pizza using their facilities. Example: App Engine
  • Function as a Service — You go to a pizzeria with some friends. You order and then eat pizza made by the restaurant. You order drinks from the bar and they’re made for you. Example: AWS Lambda
  • Software as a Service — You go to someone’s house for a party, they provide the pizza and invite others round for you to meet. Conversation with the guests is still your responsibility! Example: Gmail

For the more technically minded, I’ve added the levels of abstraction at the side so you can see what I was thinking from an actual implementation point of view. The one that’s probably slightly contentious is the scaling level. I was trying to use this to highlight the difference between PaaS and Faas ie with PaaS you still have to worry about how to manage scaling Eg how many dynos (Heroku) do you want to run.

Hopefully that makes more sense and is easier to use when trying to explain the differences…

…or maybe I’ve just overthought this a bit

Either way, I welcome your comments / thoughts and suggested improvements!

Originally posted on my blog: Pizza as a Service 2.0

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store