Cloud Orientation - The Cloud Compass

My initial intention for this blog was for it to be about something else and have some diagram at the top, which would then appear in all posts, to orient the reader into which area of 'Cloud' I was talking about. I think the major problem with the term 'Cloud' is that it is an umbrella term for several different levels of technology abstraction, and this leads to confusion. So when I was putting together this little diagram I got a bit bogged down in it, and have decided that before I proceed with more posts, I would explain it rather than sticking it at the top without any context. I call the diagram the 'Cloud Compass'. Its not even a compass, but it is at least round, and I just like alliteration. And I am only talking about Public Cloud here, I don't think Private Cloud will fly long term, agree completely with this and this from Phil Wainewright. So here it is:

The Clouds over Cricklewood 'Cloud Compass' ('CCCC', catchy)

So this is the 'picture' of the cloud that I have in my head. Now, my intention for each blog post is to shove this up at the top without the arrows, and just colour the parts of cloud that I am NOT talking about grey. Revolutionary! Not really, but it should give the reader orientation. So, anyway, here is the explanation before I do that. I think the key to cloud value is abstraction to progress to the point where technology becomes easier, faster, clearer etc to implement. I think over time hardware will become less and less relevant for end-user companies to the point where IaaS will pretty much be exclusively be used by ISVs. Anyway, a bit of explanation of the segments:

• IaaS Level 1 Abstraction - Virtual Infrastructure (eg Amazon EC2 Running Linux): This refers to just replicating hardware. Which is pretty much what Amazon EC2 does. 
• IaaS Level 2 Abstration - Hmm, I felt IaaS had to be split because companies are introducing a layer on top of hardware which abstracts it, but not to the degree that it is PaaS. I feel Database.com fits there. Discuss.
• PaaS Level 1 Abstration - If you look at something like VMForce vs Force.com, there is certainly a difference in the skills you need to get going with each one. VMForce provides a Java coding framework, but not the kind of point and click environment that you get with Force.com. Of course you can code on Force.com, but given the extent of build you can do without coding, I feel the split is valid.
• PaaS Level 2 Abstraction - Something like Force.com where you have a balance of 'point and click' environment complimented with code.
• SaaS - The end-user application, with some high-level configuration able to be done by end-user Admins (ie add Products, change profile permissions etc). Something like SuccessFactors, WorkDay or Salesforce.com Service Cloud. (yes there is an overlap with PaaS there but never mind)

As you go from top to bottom here, there should be an increase in speed of delivery and stability, but possibly some 'give' in flexibility. I would suggest that when companies are looking for their 'sweet-spot' here in line with their requirements, they start from bottom to top.

So, just as a preview my next post will not be about 'Cloud' because that is too general a term of course. It will be about (the blue wedges):

There....nothing revolutionary, but will help me give context to my posts.