There has been a lot of discussion about whether or not Amazon EC2 is oversubscribed and as Reuven Cohen points out, oversubscription is used across a variety of services and industries. The most widely accepted and understood oversubscription model is that of airlines, where it is common practice to overbook flights by as much as 50%. The reason why airlines overbook is because it makes sense to have the occasional irate passenger and extra costs than flying with empty seats and the amount of overbooking for a particular flight uses specialised software and algorithms to work out the optimal overbooking.
From weakonomics:
… some of the inputs into these things would be the number of people flying for business and pleasure, where they’re going, the current weather that day, the time of the flight (surprise! People oversleep and miss flights!), even the odds of the plane breaking down
When too many people turn up for a flight, some passengers get bumped and some are offered a financial incentive (vouchers) to get off the flight and wait for the next one and the people that are generally not bumped off the flight are those with the most expensive tickets (business travellers). You would be surprised at the number of IATA ticket classes available for airline travel, where economy/coach has 13 different classes – meaning that there are potentially 13 different prices for the same cheap seat! It is the business travellers (W class) that will almost always get on the flight – they understand that they have paid a premium to just pitch up at an airport and get on the next departing flight, leaving the cheap ticket tourists to sit for a few hours or days in the airport.
In the EC2 post that started much of the discussion, Allan Williamson tells the story of how they initially used ‘small instances’ and had to move to higher instances because, he believes, they are not oversubscribed and offer better overall performance that is not related to the size of the instance. The core observation is that he feels cheated because ‘Amazon is forcing us to go to a higher priced instance just because they can't seem to cope with the volume of Small instances’.
Chuck Hollis states that the problem is not over subscription, but a lack of control and suggest that the solution is to make more use of private clouds, where enterprise IT has more control of resources. I’m not big on this idea because in my enterprise experience, the allocation of scarce IT resources is done by politics (where the most politically adept business owner gets first refusal) or bureaucracy (where internal processes and interdepartmental billings mean that the department with the most budget gets what they want). This is hardly the kind of control that supports the zero touch model that is promised by cloud computing.
What cloud computing needs, is a mechanism similar to the airlines where a premium is paid for a guaranteed seat. The problem with implementing this in cloud computing is that although the premium could be distilled into financial terms, the seat becomes a lot more complex. You could arguably pay a premium for higher spec instances, lower latency, better disk i/o, better network i/o, guaranteed completion time for a long running process, total bytes in or out and so on – all assuming that it is understandable and supported by the architecture.
The first problem is trying to get the market (even if it is consumers of your private cloud) to understand the complicated pricing model. Most people, when confronted with too many choices will um and ah until selecting the one that is probably the least suited to their real needs. If competitors are offering three different packages, small, medium and large, your highly sophistication multi-factor and dynamic prioritisation model may be too complicated and too risky (because it cannot be budgeted for) – driving customers away.
There is also the problem as to whether or not cloud computing platforms are able to measure these various performance points and make adjustments and decisions accordingly. The first culprit is the virtual machine which, as an abstraction, leaks through to all levels of the application – you may have some part of your process that is a lower priority but, because it is running on the same VM instance as everything else, cannot be prioritised differently. Do cloud computing platforms have a way to measure the applications (or even VM’s) that hog resources such as network and disk i/o and, more importantly, do something about it by balancing them out with less resource intensive applications?
Finally, there is the question as to whether or not an application is architecturally capable of being bumped off the flight or onto business class. I have no doubt that your average legacy ERP application would not take kindly to being shuffled mid-process from one server to the next as an when some fabric controller deems it a really good idea. Most applications are not being developed with the idea of being started up, shut down and moved around, never mind having the necessary monitoring points that help the fabric controller to its job.
I foresee that cloud computing platforms and their consumers will become more sophisticated, allowing the over subscription model to be an asset that allows us to use available resources optimally. Imagine being able to build an application where you can say ‘this step, from here to here, should take 0.5 seconds – if not, escalate to processing plan C1 if it costs less than $0.02/min, otherwise leave as is for 4 hours and reassess’?
We are still a long way from there, but it is coming. I wonder who is building it?
Simon
@simonmunro