For years now those of us who talk Cloud on a daily basis have used variations on a triangle shape as a way to articulate what Cloud actually is and how the various services that make up Cloud can be differentiated.
Traditional thinking (if one can have traditional thinking in a space as young as Cloud) is that Cloud is made up of three distinct parts. At the bottom of the triangle you have Infrastructure as a Service (IaaS) essentially the move from physical hardware to virtualized hardware (let’s not argue the definition at this point). Next up in the middle layer of the triangle is Platform as a Service (PaaS) – an even more confusing acronym that is generally accepted to mean some kind of scalable and automated development environment.
At the top of the triangle we have what is probably the most easily understood part of Cloud, perhaps because of the work that early vendors like salesforce and NetSuite did. Software as a Service (SaaS) is the delivery of software built for the web – scalable, browser based, pay per use or variations on those themes.
We even have our own version of the triangle – in our case we developed this one for our Cloud Stack report for CloudU (see below);
This way of describing the Cloud has been a useful tool – it’s simple, is reasonably understood and compartmentalizes things nicely for a non technical audience. Recently however this triangle metaphor has been questioned a little. A number of innovations have made a simple three level stack a little too simple;
– IaaS vendors have started adding more automated and “platform-like” services into what they do
– PaaS has become a little fragmented from automated application deployment options at one end, to high level declarative environments for creating business applications on the other
– Even SaaS, arguably the simplest of the three to understand, has been extended with extremely rich customization options that see it nudge downwards into PaaS’ space
At the recent Structure conference in San Francisco, Werner Vogels of Amazon Web Services suggested in his ”State of the Cloud” address that the stack model is now outdated and should be left behind. Rather there is a notion of a service-based architecture with containerized services and applications that are interconnected.
It’s an interesting notion – the difficulty I have with it however is that no matter how ragged the triangle metaphor becomes, it is still a highly effective tool for communicating to non-technical audiences the different aspects of Cloud. For this reason, I’ll be continuing to talk about triangles – in all their imperfect glory. Read more about what Cloud can offer small and medium businesses at CloudU.
Couldn’t you argue that the “cloud stack” never really existed because it was a bad generalisation?
A stack is generally used describe a series of different parts that when combined form a greater whole. e.g. A Subway sandwich comprising of bread, meat, cheese, salad and sauce.
We are used to using stack to refer to server software choices, the most common being LAMP (Linux/Apache/MySQL/PHP). These decisions are additive, inter-related, and leverage the strengths of the other choices.
The same can’t be said about the “cloud stack” because these inter-dependent relationships do not exist. As IT decision makers we do not have to pick and combine the infrastructure, platform and software components of the stack in the same way that we build a web server stack or a Subway sandwich.
Instead of a stack, what we are instead faced with is a vague continuum which at one end has IaaS, and at the other SaaS. In the middle somewhere sits PaaS, but where the borders lie between these three is up for debate.
So yes, the cloud stack is dead, it never existed. Long live the cloud continuum.
Just my two cents.
Thanks David – great input
The stack metaphore is useful to describe major types of functions and typical dependencies as oppose to create boundaries so as to prevent overlap. Even outside of the cloud context, the lines between what belongs in the OS, what should be provided by the development platform, and what is the responsibility of the application changes over time. With the rapid pace of change, it is inevitable that the lines will blur quickly. It doesn’t mean the model is out-dated or not useful. Just because everything can be characterized as a service doesn’t mean we shouldn’t think in terms major categories of services and define typical dependencies between the types of services.