If "peak provisioning" refers to the capacity necessary to handle peak work loads, then I suppose "idle provisioning" is what is necessary to handle a very small load. We already know what peak performance is, and that is what a single user sees on a single server with a 1GB connection. The only thing standing in the way of delivering that to every user is capacity, and as long as capacity is elastic like it is on EC2 we are pretty much there, right?
Well the devil is in the details, of course, and there are tons of details to take into consideration. Web servers scale far easier than database servers, for example. And Amazon has yet to announce support for load balancing although there are third party alternatives. Finally, autoscaling servers is one thing, bandwidth is another - slowdowns can occur at either the server or the network layer, so scalability must take both into account in order to deliver "sub second response time regardless of load".
Fortunately, this is one of the many benefits of EC2 cloud computing, knowing that your app will never be starved for bandwidth and you won't have to shell out thousands per month for a dedicated OC3 or anything. You only pay for the extra bandwidth when you need it, just like the extra servers.
Haven't heard back yet from Todd at High Scalability but I think some of the techniques being discussed on his blog are perfect for cloud computing, with things like "database shards" that allow databases to be far more scalable. This will be a critical factor in the success of cloud computing, just as it is for bare metal.
Bare Metal? Bear Medal? See how it easy it is to confuse these things? But cloud computing is not confusing at all - extra capacity on demand. What's so hard about that?
No comments:
Post a Comment