The Cloud Value Chain

Consumers of cloud computing have clamored for a more unified approach to the services they use, be it IaaS, SaaS, PaaS or some other cloud based service. The knee jerk response is to federate services. While the approach is sound, allows seamless access across services and would in theory provide some modicum of security, this does not necessarily mean that they are provided by the same cloud services provider (CSP) leaving the consumer to manage relationships and SLAs with multiple CSPs. One possible solution is for CSPs to be a one-stop-shop that allows customers to create value by building up the stack, so to speak.

Pause------------------------------------------

Before we get any further, let's keep in mind the classic pyramid diagram of cloud computing:

OK, it's a cheesy graphic, but we all understand that software (SaaS) is built on programming platforms (PaaS) which are run on infrastructure (IaaS). Clearly the graphic is not drawn to proportions because the SaaS market has outstripped the IaaS market. An inverted pyramid wouldn't cut it either because PaaS is a smaller market than IaaS. (Maybe an hourglass shape... But I digress.) A variant would be a more Application Service Provider (ASP) model where software is installed on an IaaS-based instance and offered for the use of customers. This latter variation is not strictly speaking SaaS but is a reasonable hand drawn facsimile.

Unpause----------------------------------------

Let's say one such CSP has launched a cloud computing service that offers these services to customers (say IaaS, PaaS, and SaaS to keep it simple and avoid getting into any sticky discussions about cloudwashing).

So now we have a stack based on software created by software vendors or by the open source community on which value can be created. CSPs add value by tying the three service models together and offering them transparently to customers; CSP customers add value by using the tools to write apps and programs that their customers in turn use. Hence a cloud value chain. This, of course, does not take into account value added by cloud brokers or aggregators.

The interesting bit is what happens when the app is written and then launched. The current typical development cycle sees a dev team working to create an app and then making the architecture fit the app. This is backwards and I have lived it firsthand through cloud RFPs. This is because there is a gap in the knowledge and understanding of cloud computing among developers and their management. Schools generally don't teach students to write programs with cloud computing in mind. They teach them to write stand alone apps and programs that can be run on individual servers or, more often than not, in VMware-based virtual machines--AKA, the application service provider model.

The ASP model is inefficient because it relies on individual servers (whether virtual--no this is not cloud computing--or physical) to deliver the service and defeats the purpose of cloud computing: the flexibility to acquire only those resources necessary to meet demand.

In a perfect world, customers would acquire a SaaS seat via some self-service portal; the app or program would automatically create an instance or partition for that customer; and the app or program would be written on a PaaS to make it somewhat self-aware: that is, capable of making use of APIs to scale IaaS according to demand without mucking about with middleware. This raises the ugly spectre of vendor lock-in, but then, if you like the service, it meets your needs, and is flexible as you need it to be, why would you move?