Or Why Carr’s Analogy is Wrong. Again.

Nicolas Carr envisioned compute resources being delivered in a means similar to electricity. Though providers and consumers alike use the terminology to describe cloud computing billing and metering models, the reality is that we’ve just moved from a monthly server hosting model to a more granular hourly one, and the delivery model has not changed in any way as we’ve moved to this more “on-demand” model of IT resources.

There’s very little difference between choosing amongst a list of virtual “servers” and a list of physical “servers” with varying memory capacity and compute power. Instead of choosing “Brand X Server with a specific memory and CPU spec”, you’re choosing “generic image with a specific memory and CPU spec.” You are still provisioning based on a concrete set of resources, though arguably the virtual kind can be much more easily modified than its physical predecessors. Still, you are provisioning – and ultimately paying – for a defined set of resources and you’re doing so every hour that it remains active. You may provision the smallest amount of resources possible as a means to better perform capacity planning and keep costs lower, but you’re still paying for unused resources no matter how you slice it (pun intended).

The pay for what you consume concept doesn’t actually apply to cloud computing today unless you look at “use” from the application or virtual machine point of view, and even then it breaks down. True, the application is using resources as long as it is powered on, but it’s not using all the resources it is allocated (likely) and thus you aren’t paying for what you use, you’re paying for the minimum you need. The difference is significant. Bandwidth can be metered in a way similar to electricity and its delivery model is almost exactly the same as the electrical grid. You can, in fact, deliver and consume bandwidth based on the same model – pay only for what you use. We don’t, but we could. 

Compute resources, however, are not (yet) available for “delivery” or use in such a model. The granularity is at the virtual machine, not the compute resource layer, and thus you are paying for discrete chunks of compute resources, not necessarily what you use at any given time. You’re also paying on the basis of time, in intervals usually of one hour. Even if you only fired up the virtual server and served one request, using perhaps three minutes of time, you’re still paying for an entire hour. That’s not paying for what you use, it’s simply a more granular version of billing models that have always existed: you rent X capacity for Y time. Even cloud computing providers that allow on-demand resizing of virtual machines to provision more (or less) compute resources are still falling into the same bucket because the billing model doesn’t change. This kind of capability is more about elasticity than it is the billing model and while it’s an excellent example of how providers are moving forward toward an even more dynamic and fluid provisioning and capacity management system, it doesn’t change the line-items on the monthly bill.

Like cell phones, there’s a minimum cost at work here, and that minimum cost is always incurred whether you use it all or not. It’s not as granular as an electrical grid, and probably won’t be anytime in the near future.

In most cases, this is probably true. This is not an argument about whether cloud is more financially or operationally efficient, it’s just a reminder that there is overhead in a public cloud computing environment.  Considering that according to IDC analysts at Directions 2010, the primary driver for adopting cloud computing is all about “pay per use” with “monthly payments” also in the top four reasons to adopt cloud, that’s an important point to remember. If the billing model is the primary driver then it behooves organizations to understand just how “pay per use” really works. Organizations must recognize that while it will reduce total overall costs there will be overhead associated with cloud computing, just not nearly as much as is generally associated with on-premise solutions. But you don’t want to assume that a business application that’s really used during business hours isn’t incurring costs the rest of the day. Unless it’s “powered down” it’s still “using” compute resources in the form of memory and disk and that means it’s incurring costs.

The last thing you want is to get that “monthly bill” and be as surprised as parents receiving their teenager’s first cell phone bill. Cause the cloud is fluffy and probably won’t even notice the hammer.