One of the greatest challenges in running an Infrastructure-as-a-Service cloud is how to deliver performance at a cost effective rate. The key metric behind this is the utilisation rate of hardware used in the cloud; too high and performance suffers, too low and prices inevitably rise. How can a cloud provider deliver performance and value for money in this case?
An IaaS vendor such as ourselves is a utility company. In the short term we have a fixed capacity so it is a classic yield management issue. Over-commitment is an old model deployed in a traditional shared hosting setting to keep utilisation high; that doesn’t translate well to the cloud.
What underpins the over-commit model is the low churn in clients and relatively static resource usage levels over time. That doesn’t sound like IaaS to us and it isn’t. That’s why (nameless!) cloud vendors that employ this model get a lot of complaints surrounding performance because in the cloud the demand is fluctuating much more often over short periods of time. The last thing you want is performance to suffer during peak times when you want the best performance! So this is very much a utilisation issue and good utilisation management is a win-win for both customers and vendors. What model can be used then to manage utilisation effectively?
The first thing to grasp is that there are different IaaS uses and they need to be priced differently. The second thing to understand is that markets clear through price adjustment.
So the first point is that some users of IaaS have medium to long term computing needs. This might just be their core need with peaks above it but regardless there is, for many, a core computing usage that varies little in the short term. For this need a fixed price with discounts for longer subscription periods (and potentially volume discounts for large customers) makes sense. The vendor has a defined commitment period and can therefore price accordingly. In our system we call this ‘subscription pricing’ and you can subscribe for anything from 1 month to 3 years. That capacity is then reserved for the customer 24/7 over that period of time.
This relatively stable computing need isn’t dissimilar to more traditional hosting solutions and it doesn’t require anything particularly advanced to manage yield under these conditions. This core, stable computing use forms the foundation of the cloud utilisation rate over time but, because it varies minimally in the short term, it doesn’t require active utilisation management. Here are our subscription prices which are based on unbundled per resource pricing.
The second pricing model we use is called ‘burst pricing’ and this deals with the second main component to IaaS computing; short term computing needs. This is where yield management suddenly becomes critical.
You can think of this as a fractal. Customers each have their core computing level with peaks or temporary needs (there are pure 100% burst computing users but most aren’t) and the cloud exhibits the same behaviour over a larger scale. There is a base load that represents subscribed capacity and minimal burst capacity and then there are the short term fluctuations. The crucial difference is that unlike each customer, the cloud can’t vary in size to accommodate at such short notice. So as a vendor you can either have capacity standing idle during off peak times (commercially and environmentally wasteful) or over-commit capacity during peak times with the resulting poor performance as outlined above. Both solutions are clearly sub-optimal. There is another way however and that is to use the price mechanism.
In our cloud the price of short term on demand ‘burst’ capacity varies dynamically with the utilisation of the cloud.
How does that work? Basically we have a rolling billing system with 5 minute billing periods. Customers using above their subscribed capacity of any resource automatically get billed using the burst pricing on demand system. It means our customers can automatically combine subscription and burst usage transparently and implicitly.
The burst pricing levels are announced one billing period in advance by RSS (i.e. T+5min). You can view or RSS pricing feeds online. This gives users time to perform orderly shut-downs on their servers when prices rise above their tolerance level and this is the critical difference between our on-demand computing and that of other vendors. Likewise when you shut a server down in our cloud that is on burst usage, you aren’t being charged any more for CPU and RAM. In our cloud the customer is given the control and choice about when and how they perform their computing.
The up-shot of all this is that during off peak times, the clearing price for the capacity is LOWER than during peak times. Our customers know this. We’ve given our customers a direct financial incentive to shift discretionary computing away from peak times and benefit from cheaper prices. This is exactly what we see happening.
Users script off the back of the RSS feed and set price tolerance levels which trigger API calls to bring up and down their servers. It sounds complicated but its basically a script of a few lines running every five minutes or so. We’ve designed the pricing to give discounts for off-peak usage rather than charging huge premiums during peak times. The highest burst usage rate is not penal but customers can make real savings by shifting computing off-peak where possible. Here are our burst pricing rates in full.
Utilisation of our cloud is managed in real-time through the price mechanism. In principle this is no different from airlines managing their seats on a particular flight. As a cloud provider we don’t need to overcommit yet we can run our cloud at a high utilisation rate even during off peak times by shifting computing away from peak hours; it is a win win.
This brings us back full circle regarding performance and pricing. Pricing in the short term on a cloud should be dynamic allowing the vendor to manage utilisation to ensure reliable performance. The idea of fixing prices for on-demand computing breaks utilisation management and forces vendors to rely on the ‘bad old days’ of over-commitment which harms performance for customers. In essence if someone wants to shift 500GHz CPU/500GB RAM at 3am to our cloud for 2 hours, the price they would get would be very different from 3pm in the afternoon and that is how it should be in our opinion; just like with electricity. Over time as the IaaS space becomes more experienced and sophisticated customers will be able to arbitrage between clouds which again will further increase the efficiency of resource allocation and improve cloud performance overall. There are already the first signs of this new age taking shape. A great example is the recently launched SpotCloud. As a vendor we are fully committed to this sort of open market in computing resources.
The cloud turns computing resources into utilities and that means utility style pricing and yield management. Customers gain greatly from this shift through more reliable performance whether they are using short term on demand computing or not. The sooner we see wider adoption of utility management in the IaaS space, the sooner we will see additional progress in delivering reliable performance across the various IaaS clouds.