This article was originally a guest post I did recently for Stewart Townsend over at Sun Startup Essentials describing the cloud relationship model I had developed as an artefact when discussing cloud computing.
I wanted a simply model which I could share with people and use as a discussion point, whilst still capturing the major areas of cloud computing which I considered most pertinent. I developed this model about six months ago and have since found it useful when talking with people about 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:
- the Cloud Providers; building out Clouds, for instance Google, Amazon, etc. Effectively technology providers.
- the Cloud Adopters / Developers; those developing services over the Cloud and some becoming the first generation of Cloud ISVs. I have included Cloud "Service" developers and Cloud ISV developers together. This group are effectively service enablers.
- Cloud "End" Users; those using Cloud provisioned services, often without knowing that they are cloud provisioned, the most obvious example of which are the multitude of Facebook users who have no idea there favorite FB app. is running on AWS. These are the service consumers.
I think it's important to talk about these communities because I keep hearing lots about the Cloud Providers, and even more about the issues and 'needs' of the Cloud adopters / developers, but very little in terms of Cloud "End" Users. In a computing eco-system such as this where "services" are supported by and transverse technology providers, service enablers and service consumers an end to end understanding of how this affects these reliant communities is required. Obvious issues such as SLAs for end users and businesses which rely upon high availability and high uptime from there cloud providers come to mind; however other "ilities" and systemic qualities come to mind such as security, and that's before looking at any detailed breakdown of functional services.
The point here is that the cloud adopters / developers and interestingly the cloud "watchers" (i.e. the press, media, bloggers and experts) would be mindful to remember the needs and requirements of genuine end users; for myself it'd certainly be invigorating to hear more on this topic area.
Billing / Engagement Models
Simon Wardley, a much more eloquent public speaker than myself, does a wonderful pitch which includes a look at the different "as a Service types" which he boils down to being a load of "*aaS" (very amusing, and informative, try and catch Simon presenting if you can).
I wholeheartedly agree that there is a large amount of befuddlement when it comes to the differing "*aaS" types and sub-types, and new ones are springing up relatively frequently, however I also think it's important to 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 are identified as billing and engagement models. That white paper also postulates the five major Cloud Computing provider models, into which the 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
Also included in the diagram are the major architectural layers that are included in each of the above billing / engagement models offered by the 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.
- Platform layer; made up of standard platform software i.e. app. servers, DB servers, web servers, etc., and an example implementation would be a LAMP stack.
- Infrastructure layer; made up of (i) infrastructure software (i.e.virtualisation and OS 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.
This rather oversimplifies the architecture, as it's important to note that each of the cloud billing / engagement models use capabilities from each of the above architectural layers; for instance their can be a lot of service simply in managing a network, however these describe the major architectural components (which support the service being procured), not simply ancillary functions, effectively what are the cloud providers customers principally paying for.
Delta of Effort / Delta of Opportunity
This is much more than the 'gap' between the cloud providers and the cloud users, wherein the cloud adopters / developers sit, the gap between the cloud providers and the end cloud users can be called the delta of effort, but also the delta of opportunity.
It is the delta of effort in terms of skills, abilities, experience and technology that the cloud adopter needs to deliver a functional service to their own "End Users". This will be potentially a major area of cost to the cloud adopters. But it's also the delta of opportunity;in terms of 'room' to innovate.
The more capability procured from the cloud provider (i.e. higher up the stack as a whole), the less you have to do (and procure) yourself. However the less procured from the cloud provider the more opportunity you have engineer a differentiating technology stack yourself. This itself has it's disadvantages because the cloud adopters / developers could potentially not realise the true and best value of their cloud providers infrastructure.
I suspect that there is an optimum level, around the Platform Layer, which abstracts enough complexity away (i.e. you don't have to procure servers, networks, implementation or technology operations staff), but also leaves enough room to innovate and produce software engineered value. Arguably the only current successful cloud provider, based upon market share, perception, revenue and customer take up, is Amazon Web Services (AWS) who provide a PaaS offering.
Summary
Hope you enjoyed the article, in summary if developing cloud services or even building out a cloud infrastructure I would recommend that you focus on your users and if your a cloud provider, your users' users; remembering that only a certain percentage of those users will be customers (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).
If you're looking to develop services over the cloud, think carefully about where you and your teams skills lie, and where would you most want them focusing there efforts; working on installing and tuning operating systems and application platforms or writing business value focused applications and services, before choosing at which level to engage with your cloud provider(s).
I haven't mentioned enterprise adoption of cloud based services, and that's because I'd like to post that in the near future in a different article.
Hope you enjoyed the article and all the best,
