Since my last post was about the cloud, why not another? I was reading the blog of Nicholas Carr (whose "Does IT Matter" currently holds a place of honor in the introduction to my book-in-progress), as he noted approvingly the attempt by Amazon to create a spot market for computing cycles. After failing to get my comments on that thought posted there (ain't technology grand?), I thought "Hey, I have one of those blog things myself." So, one cut, one paste, and here we are.
The attempt to analogize computing services with electrical utilities breaks down at some interesting points. The one relevant to this article is the point about the service provider attempting to avoid unused capacity. For Chicago Edison, customers were buying its services for themselves. For Amazon, customers are buying its services primarily for their own customers. This implies that one set of customers has a greater ability to regulate their usage in the face of cost fluctuations than the other set of customers (especially given the modern web business model in which the customers of AWS customers expect free and fast web services, rather than expecting to have to pay more for better response times).
Most of AWS "juice" is sold to companies who are doing things like running websites, or some form of web-based service for their own customers. These are applications that use both bandwidth and CPU in a notoriously bursty and uneven fashion. It is not uncommon to plan for a factor of 10 of overcapacity to account for the difference between normal and peak usage. Indeed, a big part of what companies hope(!) they are buying from AWS is exactly that: overcapacity -- the guarantee that one can add an order of magnitude of resources in a matter of minutes, without having to pay for that enormous difference in capacity when it is not needed.
This places AWS in the conflicted position of joyously promising customers that they will indeed have overcapacity without paying for its idle time, while not really wanting to (or being able to, in the long run) pay for enough overcapacity to deliver on that promise. Trying to create a spot market (note that this is specifically aimed at customers who do NOT have customer-facing, uncontrollably bursty needs) is an attempt to lessen the cost of this fundamental flaw in their business model. It would be interesting to know whether Amazon adjusts their own internal demands on the fly to lessen that cost as well; Chicago Edison was not using massive amounts of its own electricity to directly compete with some of the businesses of its customers -- another breakpoint in this analogy.
I think the label of "the cloud", and to a lesser extent, attempts to analogize computing to an electric utility, are distracting from basic facts. The "cloud" is really only an incremental alteration of the situation with the boring old issues of running an ISP: how much overbooking can you get away with before you piss too many customers off? How many outages can you have before customers gain a more realistic grasp of your quality of service? How many DDOS attacks and RBL listings before customers realize centralization means incurring difficult-to-estimate risks instigated by the behavior of other centralized customers? I believe the more relevant historical situation to examine is the mainframe, and the lessons learned (or often not learned) about the pros and cons of centralization versus decentralization of computing. Computing time was commoditized quite heavily nearly 50 years ago, just about the right amount of time for the lessons learned then to have been forgotten.
