Original URL: https://www.theregister.com/2011/07/13/cloud_economics_fundamentals/

Bangs for bucks: Our lightning tour of cloudonomics

How to measure a piece of string

By Tim Phillips

Posted in SaaS, 13th July 2011 18:00 GMT

The important question about moving to the cloud is: am I getting a good deal? It is easy to ask, but if you start to think about it in detail you might fancy a long lie down in a darkened room.

For the purpose of this lightning tour of cloud economics, I’m making several big assumptions:

The price of eggs

That is why when you try to pin down cloud costs people will shrug and say “how long is a piece of string?” It is also why so many vendors grab for the sticker price: this much per seat/gigabyte/core-GHz per hour.

We can do better than that.

A word about our assumptions. Some are specific to your application – for example, the cost of downtime.

The cost of bringing your data centre up to 99.9 per cent availability, if you desire that, is both a capital expenditure and an operational overhead, but it is the type of calculation that many of you have been doing for a long time.

It has to be added into the calculations. Also, the cost of the service you specify may not be the cheapest. If the location of your cloud provider matters, then you do business only with the cloud providers that offer the service at the prices they offer.

One of the most controversial recent investigations of cloud economics was posted in August 2010 on Vijay Gill’s blog. The post compares the cost of Amazon EC2 with a dedicated collocated data centre, and even has a spreadsheet that you can download.

Ticket to ride

Vijay Gill

Vijay Gill

The blog comes to an entirely uncontroversial conclusion: “If you make the trip every day, then you are better off buying a car. The difference is the duty cycle. If you are running infrastructure with a duty cycle of 100 per cent, it may make sense to run in-house.”

In other words, if you use all your servers all the time, don’t move to EC2: it will cost $118,000 compared with $70,000 every month.

This made news because Gill was Google’s “network lord” at the time - he's now at Microsoft.

The flaw in Gill’s analysis is, as he admits, that he is talking about 100 per cent utilisation.

Another flaw pointed out by a commenter is that he uses on-demand pricing rather than the cheaper price you get if you reserve demand. It is the difference between using thetrainline.com to book your ticket and just turning up at the station.

In effect, he calculated the price that Amazon EC2 would charge Google if Gill turned up unannounced, wanted one of his data centres moved to EC2, and then didn’t demand the best rate. Nevertheless, his spreadsheet is a good starting point if you want to fiddle with pricing.

We can, however, delve deeper into ways of modelling cloud economics and reach some tentative conclusions.

Joe Weinman HP

Weinman: hard stuff for fun

If you love these things, go straight to the source: Cloudonomics, a blog written by Joe Weinman full of advanced statistical and economic ideas.

You can just read the blog, run his Monte Carlo simulations or download the working papers. He has statistical analysis on much of what follows, and a lot more.

Weinman’s day job is with HP and he really does this stuff for fun.

Let's examine those conclusions.

1. Hybrid is usually optimal

Let’s start with a model of demand that we will call, in deference to Gill, the Vijay Oblong: a data centre full of servers, fully utilised 100 per cent of the time, in a predictable way. Whether it is inside your data centre or at your hosting provider, this is rarely a cloud candidate, as Gill’s spreadsheet has shown.

Vijay Oblong - graph showing 100% utilisation

The Vijay Oblong. Sometimes your working day seems like this

But this is rarely our experience. Most server demand follows one of two patterns:

The Reg Spike - usage graphWeekly_Wave_usage_graph

Reg Spike and Weekly Wave: unknown unknowns and known unknowns

The Reg Spike is a steady basic utilisation, followed by irregular and unpredictable peaks. This is the load on our web site. Our peakiness is about two-to-one. We just don’t know when it will be.

The Weekly Wave is a predictable variation. You know when the load is heaviest.

For both of these, even if your own data centre costs (say) two-thirds as much to run as renting the same on-demand capacity from a cloud provider, you are better off with the cloud provider because the cloud provider charges for the shaded area only, whereas you would need to build internal capacity (a Vijay Oblong) which can handle peaks. This much is obvious.

In the case of the Weekly Wave, you can also get a better deal by reserving demand, because you know when you will need it.

Assuming that Gill’s rule of thumb holds, and 100 per cent utilisation is cheaper than on-demand cloud when you own (or at least colocate) your own capacity, then hybrid clouds will still always be cheaper on a day-to-day basis than either alternative, even if cloud service costs several times the price of your data centre service for the same job.

Smooth blend

The total cost is determined by how long demand stays at peak levels, not the unit cost of bursting to the cloud.

Note that we ignore setup cost, migration cost and so on; this assumes that you have migrated already.

If you are mixing hosting and cloud, and can move dynamically between them, it is even better than that because you set the optimum level at which you commit to capacity at your hoster. In this diagram, it is the yellow shaded region.

Hybrid Cloud utilisation graph

Don’t worry about the yellow bit.

If the per-unit cost of your variable cloud capacity is more expensive than your basic hosting, then your optimum hosting commitment is somewhere between your average and your peak, but it will always be strictly above the average.

If it is same price or cheaper, why commit to hybrid? For this diagram, total cost is:

(P1 + P2 + P3 + …) x (cloud unit cost) + VO x (hosting unit cost)

which you can minimise by adjusting the size of the Vijay Oblong and calculating cost using the data from your business.

In this way comparative cost between data centre, hosting and cloud does not tell us much. It is total cost, which you optimise by applying it to your demand pattern.

Apply migration costs (and any other capital expenditure impact) to this, and you have a much better idea of the economics of cloud.

2. Demand aggregation is triply efficient

The experience of virtualisation to maximise utilisation also offers insight for cloud economics. The trick is that the peak of the sum of demand will always be less than the sum of the peak in demand.

That is, if server one is at 80 per cent on some days, and server two is at 70 per cent on some days, then when they are combined you might get 150 per cent once or twice, but never more. And if you combine enough servers, you get much less peakiness.

It is never this neat, but the ability to consolidate workloads internally affects your choice of where to put them externally when considering cloud economics.

If two workloads cannot be consolidated, then their individual demand patterns may follow a Reg Spike or a Weekly Wave pattern, and each cloud decision has to be made independently.

Data centre efficiencies

This might be the case if the data cannot be moved out of the country, or if it is simply too expensive to create the infrastructure to consolidate. It doesn’t stop you from optimising the individual loads using hybrid cloud or hosting where it is effective.

If your data centre is dynamic enough to consolidate your workloads, and so you can use few, larger cloud providers, you can take advantage of three efficiencies:

3. Pay per use will eventually become the norm

How will the dynamics of cloud pricing alter your decisions? This underpins the whole analysis, because cloud pricing three years from now affects your infrastructure purchasing decision today.

This fascinating paper from the warm brain of Joe Weinman implies that pay-per-use pricing will supplant fixed-price hosting for all but a very few users. This implies that, as long as cloud develops equivalent services to hosting (or, with caveats, your internal data centre), pay-per-use will be the most economically efficient choice.

Exit this way

The logic is as follows. Imagine you have two choices: you rent a fixed amount of capacity, or you pay to use what you need. The fixed hoster has heavy users and light users. The lightest users are effectively buying capacity they don’t need, and so subsidising the heavy users.

They realise this and begin to defect to a pay-per-use model when it is cheaper. Maybe they read an article on The Register, for example, and are inspired to run the numbers.

As the light users who subsidised the service leave, the hoster has to raise prices for its remaining customers. This makes the service uneconomic for even more users, who defect to a pay-per-use cloud service.

This process continues until the only remaining hosting customers are those for whom it is still uneconomic to move, which will naturally be very large users, or those with regulatory barriers. Or companies with IT departments that don’t trust cloud providers.

Eventually, we have a model dominated by large organisations that can charge pay-per-use pricing thanks to aggregated demand, and large and efficient users whose utilisation is already smooth and near capacity. (But, we recall, they’d be better off with an internal data centre using Gill’s spreadsheet analysis).

This implies that pay-per-use will become an increasingly large component of external services. It is not an argument for cloud in itself, but it implies that pay-per-use models will become commonplace, as they have in other industries.

In reality there are many complicating factors: equivalence of services, the cost of migration, confidence in providers, imperfect competition in niche markets.

And not least, as you tell us, the fact that you don’t trust cloud providers yet, an argument that trumps economics every time. ®