Thoughts on British ICT, energy & environment, cloud computing and security from Memset's MD
For a less technical description of IaaS/PaaS/IaaS, see this article: What is cloud computing?.
One of the areas on which we reached clear agreement in the G-Cloud and App Store phase 2 was the definition the layers of the stack, infrastructure, platform and software, and their scalable, standardised “as a service” modes. Pleasingly, our delinations were very similar to prior work from two decades ago by IBM, except that ours incorporate virtualisation.
The diagram shows what we agreed we mean by Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (right hand side) and the areas encompassed by the individual terms infrastructure / platform / software on the left. A better term than “software” might be “application” since the platform part is also really just software, but SaaS has already gained wide acceptance.

It is assumed that “as a service” means all services within the definition are fully integrated up to and including the respective level, thus incorporating any sub-levels. Therefore, SaaS providers could either sub-contract to a PaaS provider, or would incorporate the PaaS themselves and provide it as part of the SaaS “stack”. In turn the IaaS could be sub-contracted or incorporated. The customer would see an integrated service.
It is also worth explaining the overlap between ‘platform’ and ‘software’; that is because some advanced platforms are built on complex software solutions which go well beyond just operating systems and a bit of infrastructure software.
For example, one could consider bare operating system as the platform, with the bespoke software application incorporating its own software infrastructure elements (eg. a bespoke CRM solution). One might also consider a Linux-Apache-MySQL-PHP stack as the platform in its entirety, with only the PHP code and databate structure being the software/application layer. The key differentiator between ‘platform’ and ‘software’ is that a platform is standardised and to an extent commoditised, with the software being the bespoke / custom element. A platform would also often, but not always, be highly scalable across multiple servers.
Standardised / commoditised software (hosted application) services, as opposed to bespoke / custom deployments, would most likely be considered to be SaaS.
Virtual differences
Until this point many experienced readers might be saying, “Yes, that that is just hardware, middleware and software renamed!”. To a large extent you would be right, with one small exception being subtle differences between modern platform or middleware, but there is an important difference between the old concept of “hardware” and ours of “infrastructure”: virtualisation.
It was agreed among the G-Cloud team that the virtualisation should now be considered as part of the hardware layer since it has become such an integral method of dividing and provisioning hardware resources. It is important to note that we drew the line precisely between the virtualisation layer (ie. the hypervisor) and operating system, viewing a bare-bones virtual machine without operating system or kernel as the unit(s) of hardware.
Of course, virtualisation is not ubiquitous. Indeed for many systems including highly scalable ones upon which PaaS and SaaS stacks are built do not use any virtualisation (Google App Engine does not, for example). In such cases one would simply view the stack without the virtualisation layer with the boundary between infrastructure and platform being between the physical hardware and operating system layers.
Network
Another critique of this model could be that the “interconnecting network” appears to link directly from the software layer through to the client device. In reality, of course, all network traffic has to sink back down through the layers from the software to via the networking & firewalling layer, then on to the client device. To keep the stack looking like a stack, however (which is correct from a logical perspective), it is better to stick the client device on top rather than off to one side. In the full postulated functional of the G-Cloud logical architecture the connections are more explicitly shown in a 2D rather than linear model. Hopefully that will be in the public domain soon!
Page optimized by WP Minify WordPress Plugin
Thanks for your comments on this topic. I frequently get asked this question and it is nice to have a clear and concise definition to point folks to for additional reading on the subject.
Regards,
-Robert
I think the picture of Service Layers Definition in this article presents the IaaS, PaaS, and SaaS very well. Can I have your permission to reuse the picture when I explain the distinctions to others?
Thanks,
Yahping Wang
How do you think, the G-Cloud will address the Digitial Rights Management and IPR.
Andy
PaaS is a bit easier to use since you're not concerned at all with the OS or underlying infrastructure, but the actual infrastructure requirements are obscured and there is scope for vendors to put in large margins.
SaaS is the simplest to use, but has the real costs are entirely obscured. For example, I estimate that Salesforce.com's infrastructure costs are at least 2 orders of magnitude below what they charge (~$1,000/year/user vs. ~$10/year/user), but you are paying for the software and support in that so the customers don't mind.
I'm working on several whitepapers that are trying to address the confusion around the "Cloud". I think that your diagram would be a good source for presenting this topic. I would like your permission to use your diagram as the base of diagram that I'm working on....
Many Thanks
Fred Rowell, VP / CTO
Bit of a late post in response to your blog. Like Yahping I too am seeking permission to use your graphic. Also saw a good graphic on G Cloud that was displayed during one of your excellent talks. This too would be of value, interest and very relevent.
Purpose is info sec training (accredited BCS-ISEB and others). Will link back to your blog and or Memset as required.
Many thanks in advance
Nigel Landman
MD, QT&C Ltd.
Ditto to the request to use our graphic for an internal presentation (ref to you and memset to be included) please?
I'm actually hoping to draw a new version to fit with the presentation's visual style, but this is by far the best visual representation of cloud classification I've seen.
TIA,
Mark
Andy
A very good post and a very good "anatomy" of cloud, and as others have requested can I please use the visualization in an offline presentation to be given to students of my class (I would credit you and Memset Ltd.)?
Thanks,
Abhishek
If it is possible, could you provide an example of and SaaS application, like box.net that was developed (and runs?) on a PaaS (like ??) and is hosted on a IaaS like Amazon. I am guessing the above scenario could be true but I can't find an example of it.
thanks for any help
Bud
Can I have your permission to reuse the "Service Layers Definition" picture in an offline article? I'll make sure to mention the URL and you as the author.
Thakns in advance
Jan Martens
I hate to say it but the most interesting pure PaaS play at present looks to be Azure - provided that they can crack the gnarly problem of seamlessly scaling a relational database. Google App Engine (GAE) is a poor cousin by comparison with its huge restrictions on coding and its non-relational data store. Also, GAE have recently priced themselves out of the market.
However, one possible example, going back to my LAMP stacks again, would be some of our customers who rent IaaS (virtual machines etc) from us, install and manage the application infrastructure software themselves (Linux-Apache-MySQL-PHP/Python etc - "LAMP" stacks), and then provide managed Web hosting services to their customer who are less technical and just want a platform to run their e-commerce shop or whatever. Those Web hosting resellers, for want of a better name, are in effect providing PaaS, though usually not on the granular level we tend to think of with cloud.
The big issue I see with PaaS at the moment is that no one has worked out the right way to bill for it. Google App Engine's new billing is more like IaaS (instances etc). I think charging per-user would be best for PaaS, but then you're having to poke up into the software layer in most cases.
Reading through the comments, I wonder why you are disqualifying PaaS vendors like LongJump and force.com as "true PaaS"? Could you elaborate on that? Based on your classification and explanations, these to me seem prime examples.
Thank!
Is there another standard known?
Fantastic representation of Cloud Service Layer Definition. Very clear and concise which is very hard to find. Would you mind if I used your diagram in a presentation?
Regards,
Damien
As many others, am requesting to use your diagram as well. It's very good -- clear, concise and makes the points easily.
Regards,
Sam
Thanks Kate
PS love the Desmo RR, would love one but the R1 big bang will do for now!
You are right insofar as an IaaS service would normally include at least an initial operating system. However, with most IaaS providers (us included when talking about our "self-managed" service which is analagous to EC2's SLA) the operating system is outside the provider's SLA scope for management purposes.
Further, most heavy IaaS users would actually spool up VMs with their own operating system which is stored with the provider via a snapshot/imaging service; that's what we and Amazon do and how our main cloud users use the service.
Finally, during phase 2 of the G-Cloud programme we all concurred that the operating system would be part of the "platform" layer; often the specific infrastructure applications being used to provide a platform layer are tightly linked to the OS itself.
This does highlight the fact that there is a certain amount of "greyness" in these definitions, however. The boundary between PaaS and SaaS for instance is most certainly not clearly defined! To my mind it generally comes down to the service level; what is within the scope provider's SLA and what is not.
However, we do need to provide a "bootstrap" OS in most cases, though in an ideal world the customer spins up VMs from their own images which they have uploaded to us. Equally, we will actually be retaining root on IaaS-only customer VMs by default since it is generally helpful to be able to access the OS when diagnosing issues - even with an IaaS-only SLA.
So, I would maintain that in the pure sense my layering is right (and it is what G-Cloud have adopted) but concede that the line is a little more blurry than I make out!