Cloud Elasticity
timothyfitz.wordpress.com
timothyfitz.wordpress.com
At some point you'll see for instance web based applications that fire up a cloud hosted vm per user session, much like you see an httpd process fired handling a single request right now, there will be no 'database' per se for 'your' data, just your VM for that app on ice somewhere when not in use.
This cloud thing is only just beginning, and even though it is the worst abused buzzword of the moment I think in the long run it really is the future of computing for everything that is geared towards services.
While it isn't seconds, 6 minutes would be a lot better than an hour.
Anyway, six minutes or not six minutes. An EC2 image, once shut down, is available to put back in production immediately, so I don't agree with Fitz' prediction that it'll take almost five years to get to 6 minutes intervals. As soon as Amazon realizes this usecase, why wouldn't they slash the billing interval? It would seem that our hours is chosen because it's easier to manage, and their initial use case was host of apps with peak periods - not one-off parallel tasks.
Frankly I fail to see how this matters today or what kind of app he envisions where it could matter in the future.
1000 large instances set you back a measly $800 per hour. If your app needs elasticity to a degree anywhere near that then the spindown overhead will probably be the least of your worries. After all I cannot imagine a traffic pattern that would "flicker" at a second or even subsecond rate.We're rather talking about huge surges (slashdot effect) or the classic bell curve pretty much everywhere.
When you compare that $800/hr to the operating costs of running your own 25 fully stuffed racks then you'll still come out ahead by a large margin - with every opportunity for a spindown only adding to your advantage.
> After all I cannot imagine a traffic pattern that would "flicker" at a second or even subsecond rate.
The app he's describing in the article: testing of his product. If done on 400 machines in parallel, it would take 2 min 36 sec, or 1.040 machine minutes. But he don't want to pay for 24.000 machine minutes, so he's opting for the the closer to one hour option, saving a lot of money, but failing at his objective: make the deployment (of which testing is a sub-process) as short as possible.