Developing for the Cloud

I’ve recently come across two apparently unrelated articles that together imply a lot about how development for the cloud should be done.

The first refers to post by Steve Yegge. In this he explains how Amazon embraced service orientation and what that meant for the developers and the company.

The second article is from Simon Wardley in which he laments that current “enterprise” cloud developments have a product rather than a utility mindset, i.e.:

Unfortunately, many applications are designed with the best practice for a product world i.e. scaling is about bigger machines, resilience is about N+1 and in general the focus is on reliable hardware. Best practice for a utility world involves resilience, scaling and failure modes built around software i.e. design for failure, distributed systems and chaos engines such as Netflix's chaos monkey approach. There is an inevitable cost of architectural transition from one set of best practices to another.

Both of these provide lessons in how to develop for the cloud:

• Use SOA with clear contracts and a mechanism for handling contract violations. 
• Loose coupling between sub-systems is essential for business survivability in an unreliable distributed computing environment a.k.a. the cloud.
• Develop platforms, and with it the ability to continually extend what’s offered.

What's PaaS?

One of the models used to explain the cloud computing service offerings - derived from the NIST model -  shows the service models arranged as a stack. Implicit in this model is a usage hierarchy (explicitly shown in the diagram below) , that is BPaaS will use SaaS, SaaS uses PaaS to provide an abstraction from underlying computing resources and IaaS provides the basic resources. This seems to make a lot of sense to software architects who recognise a familiar pattern.  

  However, one of the problems I face when talking about PaaS is that many have different preconceptions as to what it is, usually derived from what is currently being provided by various cloud vendors. These range from:

Provided PaaS Services	Example Provider
A set of services for resource allocation in a IaaS service model.	Amazon EC2, Rackspace
Basic middleware and data storage services.	Amazon Web Services (AWS)
A set of application services.	Goggle App Engine (GAE)
Model driven development platforms in the cloud.	force.com
Application development framework for cloud computing.	vFabric, Heroku
A process development framework in the cloud.	Cordys Process Factory, IBM Blueworks Live
Platforms that provide a set of business functionality that can be built upon.	CRM functionality, platforms that provide document management and process automation etc..  PaaS at this level seems to be a underdeveloped model.

Looking at this suggests that the simple model as proposed by the NIST is, in fact too simplistic. So what should the model look like?  

One possibility I like, is to place the PaaS service model to the side of the others and show that they are used by two different roles, i.e.:

PaaS is then a set of functionality that can cover the development needs for the complete spectrum from IaaS to BPaaS, but in practice each cloud service provider will only cover a limited set.

(Update: I've been having some problems with the images displaying. Reloaded them so hopefully it works now.)