Pizza as a Service 2.0 by Paul Kerrison
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”.
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
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 restuarant. 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!
About Paul Kerrison
Paul Kerrison is a visionary and capable IT architect and leader with over 15 years experience solving complex business problems with innovative and reliable solutions. Calm, considered and diligent with an infectious enthusiasm for great enterprise-level architecture across multiple business domains. Able to communicate and negotiate effectively at all levels and deliver transformational change to business capabilities and processes. An approachable and confident personality with a proven ability to learn quickly, bring out the best in others and deliver strategic objectives. Paul operates his own blog at paulkerrison.co.uk.
Views represented by guest bloggers are their own and do not represent those of AMI or their employer. If you would like to be a guest blogger, please reach out to us via our contact page.