Cloud Relationship Model

masterkey

Hiya All, welcome to my first guest post at Startup Essentials;today I'm going to be talking about the cloud relationship model I'vedeveloped and it's use as an artefact when discussing cloud computing.
Iwanted a simply model which I could share with people and use as adiscussion point, whilst still capturing the major areas of cloudcomputing which I considered most pertinent.  I developed a model aboutsix months ago and have since found it useful when talking with peopleabout cloud computing.
Here's the model and I'll go though it's major elements below.
 
 

 
 
 
 
Major Cloud Communities

   In the cloud there are three major participants:

• theCloud Providers; building out Clouds, for instance Google, Amazon, etc. Effectivetively technology providers.
  
• theCloudAdopters / Developers; those developingservices over the Cloud and some becoming the first generation of CloudISVs.  I have included Cloud "Service" developers and Cloud ISVdevelopers together. This group are effectively service enablers.
  
• Cloud"End"Users; those using Cloudprovisioned services, often without knowing that they are cloudprovisioned, the most obvious example of which are the multitude ofFacebook users who have no idea there favorite FB app. is running onAWS. These are the service consumers.
  

Ithink it's important to talk about these communities because I keephearing lots about the Cloud Providers, and even more about the issuesand 'needs' of the Cloud adopters / developers, but very little interms of Cloud "End" Users.  In a computing eco-system such as thiswhere "services" are supported by and transverse technology providers,service enablers and service consumers an end to end understanding ofhow this affects these reliant communities is required. Obvious issuessuch as SLAs for end users and businesses which rely upon highavailability and high uptime from there cloud providers come to mind;however other "ilities" and systemic qualities come to mind such assecurity, and that's before looking at any detailed breakdown offunctional services.
The point here is that the cloudadopters / developers and interestingly the cloud "watchers" (i.e. thepress, media, bloggers and experts) would be mindful to remember theneeds and requirements of genuine end users; for myself it'd certainlybe invigorating to hear more on this topic area.
Billing / Engagement Models

Simon Wardley,a much more eloquent public speaker than myself, does a wonderful pitchwhich includes a look at the different "as a Service types" which heboils down to being a load of "*aaS" (very amusing, and informative,try and catch Simon presenting if you can).
Iwholeheartedly agree that there is a large amount of befuddlement whenit comes to the differing "*aaS" types and sub-types, and new ones arespringing up relatively frequently, however I also think it's importantto not ignore the differences between them.
For me, and many others, I think first popularised by the "Partly Cloudy - Blue-Sky Thinking About Cloud Computing"white paper from the 451 Group, the differing "*aaS" variants areidentified as billing and engagement models.  That white paper alsopostulates the five major Cloud Computing provider models, into whichthe majority of minor "*aaS" variants fall.  They are:

• Managed Service Provision (MSP); not only are you hiring your service from the cloud, you've someone to run and maintain it too.
  
• Software as a Service (SaaS); pretty much ubiquitous as a term and usually typified by Salesforce.com, who are the SaaS poster child.
  
• Platform as a Service (PaaS); the application platform most commonly associated with Amazon Web Services.
  
• Infrastructure as a Service (IaaS);
  
• Hosting 2.0
  

One of the best breakdowns and visual analysis of this space is the model in Peter Laird's "Understanding the Cloud Computing/SaaS/PaaS markets: a Map of the Players in the Industry" article which is well worth a read.
 
Major Architectural Layers

Alsoincluded in the diagram are the major architectural layers that areincluded in each of the above billing / engagement models offered bythe Cloud providers. They are:

• Operations;and this really is operations supporting functional business processes,rather than supporting the technology itself.
  
• Service layer; made up of application code, bespoke code, high-level ISV offerings.
  
• Platformlayer; made up of standard platform software i.e. app. servers, DBservers, web servers, etc., and an example implementation would be a LAMP stack.
  
• Infrastructurelayer; made up of (i) infrastructure software (i.e.virtualisation andOS software), (ii) the hardware platform and server infrastructure, and(iii) the storage platform.
  
• Network layer; made up of routers, firewalls, gateways, and other network technology.
  

Thisrather oversimplifies the architecture, as it's important to note thateach of the cloud billing / engagement models use capabilities fromeach of the above architectural layers; for instance their can be a lotof service simply in managing a network, however these describe themajor architectural components (which support the service beingprocured), not simply ancillary functions, effectively what are thecloud providers customers principally paying for.
Delta of Effort / Delta of Opportunity

Thisis much more than the 'gap' between the cloud providers and the cloudusers, wherein the cloud adopters / developers sit, the gap between thecloud providers and the end cloud users can be called the delta ofeffort, but also the delta of opportunity.
It is the deltaof effort in terms of skills, abilities, experience and technology thatthe cloud adopter needs to deliver a functional service to their own“End Users”.  This will be potentially a major area of cost to thecloud adopters. But it's also the delta of opportunity;in terms of'room' to innovate.
The more capability procured from thecloud provider (i.e. higher up the stack as a whole), the less you haveto do (and procure) yourself.  However the less procured from the cloudprovider the more opportunity you have engineer a differentiatingtechnology stack yourself.  This itself has it's disadvantages becausethe cloud adopters / developers could potentially not realise the trueand best value of their cloud providers infrastructure.
Isuspect that there is an optimum level, around the Platform Layer,which abstracts enough complexity away (i.e. you don't have to procureservers, networks, implementation or technology operations staff), butalso leaves enough room to innovate and produce software engineeredvalue.  Arguably the only current successful cloud provider, based uponmarket share, perception, revenue and customer take up, is Amazon WebServices (AWS) who provide a PaaS offering.
 
Summary

Hopeyou enjoyed the article, in summary if developing cloud services oreven building out a cloud infrastructure I would recommend that youfocus on your users and if your a cloud provider, your users' users;remembering that only a certain percentage of those users will becustomers (I won't getting into discussing Chris Anderson's 5% recommended conversion rate for the long tail, however I would recommend understanding what some of those calculations might be).
Ifyou're looking to develop services over the cloud, think carefullyabout where you and your teams skills lie, and where would you mostwant them focusing there efforts; working on installing and tuningoperating systems and application platforms or writing business valuefocused applications and services, before choosing at which level toengage with your cloud provider(s).
 
I haven't mentioned enterprise adoption of cloud based services, andthat's because I'd like to post that in the near future in a differentarticle.
Hope you enjoyed the article and all the best,
Wayne Horkan