Best.
alain

To give the simplest model that works very well in practice for companies big and small, there is a contracted price-service floor (“commit”) that will be billed regardless of service usage, usually at a discounted rate. There is a 95th percentile billing on all resource usage over the commit (“burst”), which both allows organic growth up to the capacity of the underlying resource (best effort) *and* allows transient peaks to not generate any additional billing activity (32 hours worth in a month), usually billed at a premium over the commit rate (typically around 50% plus or minus). Lastly, there is resource cap such that burst billing can never exceed a certain value specified by the customer, allowing them to put a hard limit on their cost even if radical growth does cause them to go way over their commit rate. In short, it lets the customer set the minimum and maximum bill, with a substantial discount for resources that are committed.

Percentile based pay-as-you-go billing that has both a floor and a ceiling is simple enough that people can understand it, and powerful enough that it can handle the entire spectrum of risk averseness and absorb transients — giving the impression of better quality of service — without a billing event. In practice, you find companies that have no commit and pay for whatever it is they use at the premium burst rate (no billing risk aversion at all) and other companies that set the commit and cap to the same value such that there is no variability (extreme billing risk aversion). But you find that most companies choose a commit based on their estimates of resource usage with a comfortable cap maybe two or three times the commit value just in case they really need it.

This is essentially the evolved billing model for modern network resource “clouds”, and it works well for everyone. I see no reason the same basic lessons in dynamic billing models could not be applied to cloud computing.

Thank you Ken for mentioning the concept of “non-core” operations. This is the first time that I have heard anyone referring to non-core operations and many vendors forget this concept. Non-core areas are the ones that support an organization’s central activity (e.g., in a pharmaceutical company the core operation would be R&D whereas non-core would be purchasing, human resources, facilities management etc.). In my 18 years in the enterprise applications software business I have learned that these days a majority of organizations are willing to let someone else manage or deliver services to support non-core operations.