18 September 2008

Taxonomy: The 6 layer Cloud Computing Stack

Finally things have settled down enough that we can start making some sensible statements about the taxonomy of cloud computing. The Wikipedia cloud computing article(s) in particular are now fairly stable (after countless hours of work over the recent months) and the main one has climbed its way to the top of Google's search results for "cloud computing". New articles like the hours-old one on RightScale are slipping in to the cloud computing category tree nicely too.

Therefore, without further ado I am pleased to announce the 6 layer Cloud Computing Stack (developed and hosted on the brand new Cloud Computing Community Wiki) in all its Creative Commons Public Domain glory. You can use it however you see fit, commercially or non-commercially, under whatever license you want and you don't even need to give me credit for it. You can get it in SVG and PNG formats from the WikiMedia Commons, and if you've got the excellent OmniGraffle editor then I'll even send you the originals if you ask nicely.

The 6 layers of the Cloud Computing Stack (from top to bottom) are:
This finds a happy medium in that it:
  • Doesn't oversimplify like the aaSy 3 layer stack (SaaS, PaaS, IaaS)
  • Doesn't overcomplicate like the all-inclusive 11 layer stack (remember cloud computing is about hiding the complexity of the Facilities, Network, Hardware, OS, Systems Management and Development Environment layers).
  • Favours 'Application' (as in 'Web Application') over 'Software' (which can exist on the servers with SaaS and/or the clients with software plus services).
  • Ignores things cloud computing users don't care about (most notably anything physical)
  • Avoids altogether the overused 'as a Service' moniker, the characteristics of which (scalability, utility billing, no capex, etc.) are common and shared with cloud computing in general.
  • Resists the urge to create new terms (neologisms) unnecessarily, opting for the simplest appropriate single word possible.
I hope that this work proves useful in understanding what cloud computing is all about and how cloud computing architecture works. I also hope that these terms take over from more complex, aaSy neologisms as they're clean, simple and they just make sense. Here's a translation table to get you started:
  • Cloud Computer, Device, etc. » Cloud Client
  • Web Services » Cloud Services
  • Software as a Service, Software plus Services » Cloud Application
  • Platform as a Service » Cloud Platform
  • Storage as a Service, Cloud Attached Storage » Cloud Storage
  • Infrastructure as a Service, Hardware as a Service » Cloud Infrastructure

11 comments:

  1. Thanks Jesse. I previously had a compressed version, where storage/platform was one split layer and application/services another, giving 4 layers in total. I think the vertical model, like the OSI stack, is more interesting even if (unlike the OSI stack) we don't /have/ to pass up/down through all layers... nothing will be academically perfect but I'm all ears for suggestions on further refining this.
    ReplyDelete
  2. Platform is the bastard-child in your taxonomy, I think - although you've added the get out in your comment:
    >>don't/have/to pass up/down through all layers

    Even so, platform feels some form of super-layer, an amalgam of elements of those below it and those above it and therefore it doesn't deserve its own layer (
    the examples suggest any platform-aaS is just a 'productisation' instance of infr., storage, applications).

    Perhaps these platform products will be made redundant in future by Middleware-as-a-Service™®?
    ReplyDelete
  3. [received by email]

    Hi Sam,

    First of all, great work with the taxonomy. Thanks for the effort you have taken. I have a couple of comments on the taxonomy, for you
    to consider.

    1. Isn't it more appropriate to layer Application above Services? (applications use services, usually, as per your definitions.)

    2. You may consider "Data" or "Data Organization" instead of "Storage." As "storage" is often used in the context of infrastructure (aka SAN, NAS etc.) it can be confusing to at least some people.

    I couldn't post a comment at your blog size due to some error.

    Warm regards,

    --
    xxxxxxxx
    E-mail: xxxxxxxx@computer.org
    ReplyDelete
  4. Good afternoon,

    Thankyou for the feedback - it is most appreciated.

    Regarding the two specific points, you may be more comfortable with the earlier version (http://commons.wikimedia.org/wiki/Image:CloudComputingStack.svg) which has platform/storage and application/services at the same level.

    1. I considered this point for some time - it didn't sit well with me until I realised that services are provided by applications and consumed both by applications and clients; it is not necessary for clients to communicate 'through' an application to reach the services, yet clients regularly (but not always) communicate directly with services (e.g. AJAX).

    2. Storage is already well accepted by the community, though it is sure that there are currently two main 'types' of storage: files (eg S3) and databases (eg SimpleDB). I think we will see a move towards the latter, in that everything will start to look like an object/blob referenced by URL rather than a file (itself a 'legacy' concept anyway) - as such it makes sense to keep it generic. Furthermore, introduction of services like Amazon's Public Data Sets which are actually *data* (some would say 'Data as a Service') rather than a *container* for data also make the term storage more suitable.

    I hope that you are more comfortable with the taxonomy with these clarifications, but if you still have issues then feel free to raise them as it is my intention that this reflect the community consensus rather than an individual view (based on feedback received so far it does).

    Kind regards,

    Sam
    ReplyDelete
  5. Sam

    if "and if you've got the excellent OmniGraffle editor then I'll even send you the originals if you ask nicely" still stands, does this count as asking nicely? Please? ;-)

    paul [dot] miller [at] cloudofdata [dot] com
    ReplyDelete
  6. Of course, but I am currently half a dozen hours from the machine on which it is stored. If you need it immediately then I'd suggest drawing a few boxes yourself (the hard work was in defining the layers - not drawing the pictures :) )

    Sam
    ReplyDelete
  7. It seems IBM have slightly adapted the stack by separating out storage and databases at the expense of the services layer.

    The line between filesystems and databases is blurring - in the cloud things look more like objects without the rigidity (and scalability ceilings) of schemas and large chunks of data are blobs. That doesn't stop Amazon offering S3 and SimpleDB so perhaps there is some value in separating the two, but I'm not 100% convinced about this - it's just another (largely unnecessary) interface.

    Services pop up at each layer (eg VM management, storage access, etc.) and as such having a dedicated layer for them also doesn't reconcile 100%. They are a critical part of cloud computing and as you can see from the many examples at Wikipedia there's already stuff in this particular box.

    Sam
    ReplyDelete
  8. Thanks Sam (sarcasm).

    I just did an exam where one of the questions was ‘Describe the 6 layers of cloud computing’. At the time, I only know of the 3 SaaS, PaaS and IaaS layers. I guessed the data/storage layer, but had no idea about the other 2 until afterward when I googled your webpage.
    ReplyDelete
  9. Hi Sam,
    how would you put "Archive" into this....it is not Storage because it needs a lot of xtras like re-certification/retention/purge/litigation-hold...it is not data because it is un-changeable by law/regulation...it is not platform because location matters a lot...

    ??
    cheers,
    Michael
    ReplyDelete
  10. Although all this is fairly new to me, I'm beggining to understand how it all works and the principles behind it.

    Bookmarked for future reference.

    Thanks Sam, nice to meet you by the way.
    ReplyDelete