

Cloud Elasticity - TimothyFitz
http://timothyfitz.wordpress.com/2009/02/14/cloud-elasticity/

======
jacquesm
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.

------
ensignavenger
Didn't Sun originally bill for 6 minute increments (or something like that)
for their Sun Grid Computing service?

While it isn't seconds, 6 minutes would be a lot better than an hour.

~~~
mseebach
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.

------
FiReaNG3L
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)?

~~~
moe
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.

~~~
mseebach
> 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.

~~~
moe
Shame on me, seems I skimmed that text way too briefly. Yes, now it makes
sense.

