Cloudonomics: a closer look

The economics of the cloud are becoming assumed and this is dangerous because they are by no means assured. The electricity-commodity metaphor, while useful, has outgrown its usefulness.  Make the wrong choices about cloud and you could be stuck with a solution that doesn’t return ROI at all. The key to Cloud Economics, or Cloudonomics as they’re known, is understanding the types of Cloud and key economic drivers.

I was recently asked to write an article for an IT magazine on the economics of Cloud Computing: Cloudonomics. Specifically, I covered what are the cost dynamics, how do you measure them and how do you evaluate them. Here’s my article:

In preparation for this article I asked a computing professional: “What is Cloud Computing?”

His answer was: “Computing which you buy in a pay-as-you-use, or on-demand way.”

Sound reasonable?

Yes, if you were only talking about Infrastructure as a Service. However, if you’re talking about the economics of Platform as a Service or Software as a Service, you need an answer that is completely different.

This is the nub of the problem: people commonly associate Cloudonomics only with the economics of Infrastructure as a Service (IaaS), which consists of Disk Storage, Compute Cycles, Memory and Network Bandwidth. In other words, virtualised compute resources all purchased as a service- or on a pay-as-you-use basis. The provider that most people have heard of is Amazon EC2.

So what are the Cloudonomics of IaaS?

In the past, organisations had to always provision for peak use- or expected demand. This meant that while the organisation was under normal load- typically about 30% utilisation- 70% of the compute capacity was being wasted. Then when the application needed more power, more physical machines had to be added, thereby increasing spare capacity when not under load. This process could take weeks, so organisations typically tried to predict loads and provision even more resources, thereby pushing utilisation down even further.

And organisations have been known to take over provisioning to extremes; Vivek Kundra, the United States Federal CIO found that utilisation in Federal Datacentres was less than 3%.

Platform as a Service (PaaS) and Software as a Service (SaaS) have completely different economics because they are purchased in completely different ways. A PaaS is a service used by organisations to execute code produced by developers and is paid for as it’s used. Applications typically need to be redeveloped for PaaS, as the application needs to be designed to take advantage of the platform it’s running on. PaaS provides ROI by alleviating developers’ concerns about scaling their infrastructure or employing engineers to run the service.

SaaS is software used by organisations and again paid for in an as-you-use model. However, SaaS is billed on value, is normally aligned with users and delivers ROI much like traditional software, except there is no capital investment, which means that value and expense are closely aligned. It also produces systems that are much more scalable and flexible than traditional software.

So how can IaaS help and deliver ROI? Instead of having to provision for peak capacity, organisations can buy resources as they need them, matching utilisation and thereby provisioning with demand.

Cloudonomics really come into play when you optimise the purchase of resources. That’s because on-demand resources are more expensive than dedicated resources, so you shouldn’t just use all on-demand resources if your application has any continuous load. The formula for working out how much to provision as dedicated is the inverse of the utility premium, i.e. how much more expensive on-demand is over dedicated. If dedicated is the same price as on-demand, then no dedicated resources should be used. 

That’s the idea, but for many organisations that’s nothing more than a pipe dream, as their applications aren’t built for IaaS. Applications that work best on IaaS are applications that scale horizontally and have built in failure redundancy. Not the typical applications that have been built over the last 20 years and deployed widely on the corporate landscape that require reliable hardware and scale vertically using more compute.