As I make my way to tonight's heavily over-subscribed Cloud Computing Camp in London, I'm mulling an important aspect of cloud business models that I doubt will get much airtime tonight. People who talk about computing as a utility miss a vital point that Dan Farber brought up more than three years ago:
"... an industry standard definition of CPU per hour usage doesn't exist. There is no equivalent to kilowatt hours or the price of a barrel of oil for CPU usage."
Although Amazon EC2 subsequently took us a few steps closer than the Sun Grid offering that prompted Dan's remarks, the fact remains that cloud computing is nothing like the electricity grid. Cloud computing isn't a tradeable commodity. Each cloud provider operates its own proprietary infrastructure and every one of them has their own set of pricing plans. We can measure bandwidth in MB and storage in GB, but there's no standard unit of computing — providers measure hours or seconds of processing, but each processor configuration is different — making it all-but-impossible to compare the cost of hosting your application from one provider to another.
I guess it's premature to expect such standards to emerge so early in the life of a nascent industry. Many providers are still evolving their own pricing models. One such case that's been interesting to watch is Mosso, the Rackspace subsidiary that relaunched as a pay-as-you-grow cloud computing service in February (disclosure: Mosso has given me a free trial account to test its service, which I've just started working with for a couple of my own sites and will write up once I'm further along with it).
Last month, Mosso introduced a concept that, who knows, might provide the basis for a standard unit of computing. It has come up with the notion of a 'compute cycle' based on looking at the monthly capacity delivered by a typical 1.2Ghz server under average load, and has defined that as 10,000 compute cycles. This allows Mosso to calculate the processing time, disk I/O and memory that equates to a single cycle, and the provider measures this in real-time so that its customers can monitor their consumption during the month and it can bill them for what they've used at the end of the month. The 10,000 figure conveniently maps to Mosso's $100-per-month base-level monthly charge, and additional usage scales up at the same 1-cent-per-compute-cycle rate.
The background to the creation of Mosso's compute cycle is an interesting story. When it first introduced its pay-as-you-grow pricing model in February, customers were very unhappy about its proposals and it was rapidly forced to backtrack. Its initial proposal had been to measure processing by simply counting requests, on the assumption that this was easy to explain and measure. But, as Mosso co-founder Todd Morey told me last month, "Not all systems are created equal." Customers with largely static websites pointed out that thousands of requests for a static HTML page have a different compute profile than the same number of requests for a dynamic PHP page. Others argued — and this was an important consideration from Mosso's point of view — that its proposed model that didn't reward customers for architecting sites to have a lean compute profile.
"It's a more complicated effort to calculate compute, but it's certainly worth it," Morey summed up. "We needed some mechanism that measures your compute consumption."
There are still some tweaks to be made, so Mosso won't be billing customers using the new model until September. A handful of customers are experiencing what it calls "abnormally high compute cycle usage" and the company has promised to investigate why this is occuring so that it can make sure the model is reporting usage accurately in those cases. But Mosso believes it has found a strong formula that it can use for a range of services as it expands its offerings in the future. "[Customers] can consume all these different services without having lots of different line items on [their] statements," said Morey.
Whether other cloud computing providers will adopt a similar model of course is another question. For example, Amazon could move away from charging different prices for different types of machine image to a single compute-cycle price. If providers took the further step of standardizing on an agreed measure of compute-cycle, then customers could directly compare prices across different infrastructures — and perhaps ultimately consume computing from a true utility grid in which providers compete to offer the most competitive value. But perhaps that's a step too far towards commoditization.