Together with increased cloud elasticity we'll have to have a much more accurate billing scheme based on fractions of a second usage, the vendors of cloud services will have to address that as well as the actual performance issues.
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.
What does he means, an hour to spin down? You pay for a minimum of an hour per node on EC2? I wasn't aware of that... why don't they charge per minute (or second, for that matter)?
They charge by the partial hour. E.g. when you shut down a small instance after 61 minutes you'll pay for two hours.
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.
> Frankly I fail to see how this matters today or what kind of app he envisions where it could matter in the future.
> 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.
My thought exactly .. where did the grid go? It was all the rage a few years ago.
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.
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.