Thursday, 24 February 2011

Cloud infrastructure pricing and billing models

Previous posts here have considered the costs of both buying and building storage in the cloud. Based on our work so far, we estimate that is possible to build an academic cloud infrastructure (storage and compute) that is both sustainable and that can be offered in broadly the same price 'ball-park' as, say, Amazon Web Services.

Of course, the proof of the pudding will be in actually building it! Furthermore, how compelling such an offer might be to the academic community is not just down to price. We also have to think about the nature of the technology on offer, the service level agreements that we are able to provide, the associated support that might be offered, and the kind of pricing and billing models that we can put in place.

This post considers (admittedly at a very high level) the last of these - pricing and billing models. The intention is not to provide any answers at this stage. Rather I'm interested in what sorts of pricing and billing models would be attractive to the consumers of academic cloud services... in an ideal world (I have to add the 'ideal world' bit because, clearly, there may be tensions between what consumers want and what providers are able to offer in a cost-effective way - there will likely be some trade-offs to be made).

To frame this question further, let's think about some of the different parameters that might be considered in this area. Firstly, on pricing... there seem to be two options here:
  • Pay as you use (essentially the Amazon model where you are charged under various different categories for the amount of resource that you use) vs. Plan (where you commit to a certain amount of resource, paying extra (probably at a premium) if you go over your allowance. GoGrid provide an example of this kind of pricing model).
Of course, there are some subtleties around these options. Amazon, for example, offer both Reserved Instances (where hourly rates are lowered by committing up-front to using the resource for either 1 or 3 years) and Spot Instances (where you bid for unused resource against a fluctuating hourly price). One might refer to these more generically as Short-term commitment vs. Long-term commitment and Fixed-pricing vs. Bid-pricing.

Reserved Instances allow the provider to plan their capacity more accurately (hence the lower prices - my understanding is that, from a consumer perspective, an Amazon Reserved Instance breaks even if it is used for more than 30% of the time). Spot Instances soak up otherwise unused capacity, again meaning that the provider can offer better value for money.

There's also the issue of whether providers offer any kind of free-tier, as Amazon currently do, meaning that consumers can get going at little or no cost but, ultimately, driving up consumption for the provider. Again, one might refer to this generically as Introductory tier pricing vs. Flat pricing.

On billing models... there seem to be two aspects to consider:
  • Credit card vs. Invoice.
  • Up-front payment vs. Pay in arrears.
To draw an analogy with mobile phone tariffs for a moment... pay-as-you-go is (typically) a combination of what I'm calling here 'Pay as you use' and 'Up-front payment' while contract is (typically) a combination of 'Plan' and 'Pay in arrears'. (Note: I really wouldn't want to wish the complexity of mobile phone tariffs on anyone!).

My understanding, from discussions at conferences and so on, is that universities (at the institutional level) are keen to pay by Invoice rather than Credit card, that they like to Pay in arrears and that they lean towards the predictability of a Plan rather than the open-ended nature of Pay as you use. Note: individual researchers may see things differently.

So, first question... is this categorisation into:
  • Pay as you use vs. Plan
  • Up-front payment vs. Pay in arrears
  • Credit card vs. Invoice
  • Short-term vs. Long-term commitment (a la Reserved Instances)
  • Fixed-pricing vs. Bid-pricing (a la Spot Instances)
  • Introductory tier pricing vs. Flat pricing
useful? What have I missed?

Secondly... what is attractive to you (either as an individual or as an institution)?

I have to say that our thinking, to date, leads us towards sticking close to the Amazon pricing model (not least because it is a widely understood and accepted way of thinking about things), ignoring discount for long term commitments and bid-pricing (at least in the short term), and allowing payment in arrears based on a saved credit card and/or invoice (probably).

Introductory tier pricing is problematic for the provider (particularly so where the infrastructure is limited) because it is difficult to manage. Further, it tends to encourage a mindset that stuff can be made available for free when the reality is that it can't. Which is not to say that introductory tier pricing can't be done - just that its consequences need to be thought thru.

Note that all of this is just theory at the moment. It is thinking that will (primarily) inform a FleSSR project deliverable on cloud business models. As such, I welcome any and all views. Thanks.


  1. I think your breakdown of pricing models is reasonably complete, although there's a lot of scope for mixing elements of plan against PAYG, and for complexities in what plans offer.

    I think the offer for researchers vs institutions is very different. I'm also not sure that institutions always want pay-in-arrears. They often will, especially when interest rates are higher. But there are times when it's useful to get money off the books, particularly if that results in a more attractive plan.

    One area that both groups will be similar in is the desirability of both fixed price and spot price. Both individuals and institutions have an appetite for both. There are some things that you know you need, where you want guaranteed availability and a fixed price. There are other types of activity - particularly in research - where you'll soak up what's available when it's available at low cost. Mainframe scheduling systems from the 1970s onwards exploited both these markets, as well as the other extreme of the premium-priced queue jumper ("I need this NOW and I don't care what it costs.")

    You need to have some way of allowing people to try before they buy. One alternative to a free offer is to give money-back guarantees for the introductory period.

    More another time, but I'm meant to be on holiday today...

  2. For me (investigating ways to use technology to help researchers communicate and collaborate) the attraction of cloud computing is being able to put up a server for a short period to try out a tool ( came up recently for example) or do things like load-testing on services.

    From that perspective (and I agree about individuals seeing things differently to the insitution), pay-as-you-use would seem like a sensible model to use, though if a pattern of regular use emerged switching to a plan might be preferable as long as the penalties for going over-quota weren't punitive.

    I'm not sure how you could manage to pay in advance for a pay-as-you-use model: perhaps load up with credit in the same way as we do with mobile phones. That would be attractive from a project management perspective, as a budget could be allocated and credit bought up front.

    If I put on my (slightly dusty, couple-of-years-old) scientist hat, I'd also say that offering an introductory trial long enough to migrate some code to the cloud and try it out a couple of times could be the difference between people adopting it and leaving it alone as too much effort to try.

  3. I'd rather get a plan over a pay as you use. Thanks
    us vpn

  4. Hi,
    Great work done by author. I appreciate it. Thanks for sharing this informative post. Keep posting updates.

    Portable Buildings

  5. Businesses up against THAT troubles have a couple of alternatives - contact the handled THAT products and services firm they may be outsourcing techniques managed IT services

  6. Hello,
    Users of cloud are billed only for usage. There is no uniform unit yet. Known billed resources are instance-hour (with set equivalents to CPU/RAM/HDD capacity), bandwidth, infrastructure support

  7. pengobatan herbal untuk mengatasi penyakit varises secara alami tanpa efek samping

    Obat Herbal Varises