Amazon's Cloud May Provision 50,000 VMs a Day

Dan Jones writes "It has been estimated that Amazon Web Services is provisioning some 50,000 EC2 server instances per day, or more than 18 million per year. But that may not be entirely accurate. A single Amazon Machine Image (the virtual machine) may be launched multiple times as an EC2 instance, thereby indicating that the true number of individual Amazon servers may be lower, perhaps much lower, than 50,000 per day. So, even if it's out by a factor of 10 that's still 1.8 million VMs per year. Is that sustainable? By way of comparison, In February of this year, Amazon announced S3 contained 40 billion objects. By August, the number was 64 billion objects. This indicates a growth of 4 billion S3 objects per month, giving a daily growth total of about 133 million new S3 objects per day. How big can the cloud get before it starts to rain?"

tag: Dumbquestion

[drinkypoo]

How big can the cloud get before it starts to rain?"

Clouds don't work like that, they let go their rain when they enter a pressure zone where they can no longer hold water.

If Amazon is centrally dispatching, then they deserve to fail. If not, then there's no reason why getting larger would necessarily cause any particular problem.

Please stop...

[broken_chaos]

Cloud is bad enough. Starting up bullshit analogies with clouds and rain just muddy whatever you're talking about far, far more than is necessary.

How is using so many VMs more efficient?

[Viol8]

I've never really understood the fuss around VMs. Sure , they're useful if you want to test run an OS install or run a different OS on top of another. But otherwise whats the point? Instead of having app + OS you end up with app + VM + OS so how exactly is that benefiting anyone other than the power company for the extra electricity used?

50k VMs/day is not THAT much...

[nweaver]

Lets give a 12 hour lifespan, and say 25K VMs at the same time.

At 5 VMs/physical host (I suspect it is MUCH denser actually), thats only 5K servers. At 50 servers/rack, its 100 racks.

Or, in translation, not THAT much.

Re:ok did a manager write this?!

[commodore64_love]

So to use a car analogy (cough)

- It's the same reason why people lease cars instead of buying them. It's cheaper in the short term, and easier to come up with $300 for rent than $20,000 for purchase. Plus adding extra cars as new employees join the company is trivially easy.

Re:Please stop...

[moon3]

Managers love this kind of terminology, because from their point of view Internet just 'happens' somehow, they do not have a real clue how, but the cloud fits perfectly into this kind of thinking. That is why cloud hosting is so popular, they just order 4GB/100Mbit/s cloud and the hosting company creates one for them. They do not have to worry about setting up DNS, SQLs, multiple servers, domains, SMTPs and get schooled by some lowlife nerdy IT guys, they understand the dumbed down cloud interface well enough themselves, they just interact with the web interface and are happy it is all working for them.. somehow, somewhere, in the cloud.

Re:ok did a manager write this?!

[afidel]

But it's even better than a car lease, because you can end the lease on the VM with no penalty. If you have a really big batch job that needs to run once a month then you just spin up the VM's for the duration of the batch job paying for your usage and them deprovision them for the rest of the month.

Re:How is using so many VMs more efficient?

[timeOday]

The point is that multi-tasking operating systems already support server consolidation by protecting processes from each other so you can run multiple processes on a host safely. And they do it in a FAR more efficiently than VMs, which have an entire OS instance for every process, and memory partitioned statically between them.

However, the OS doesn't quite finish the job. The need for VMs arises from design shortcomings at the OS level and above. Here are a few:

1. You can't install an app and all its dependencies and configuration by simply copying from one host to another. On Linux especially, apps have an insane number of dependencies
2. Process migration
3. Using certain port numbers for certain services (most services don't portmap, and firewalling rely heavily on port number assumpions)

It would be nice to fix these at the OS level instead of just piling one protected memory mechanism atop another (java VM atop a virtual machine atop a protected memory CPU architecture and OS).

Re:I call shenanigans

[AlXtreme]

Even if it was $300/machine with 20VMs/machine it would be quite costly to reserve 500 machines.

They raise the price because they can't scale that much on a dime. They probably have to add hundreds of machines a day in order to keep up with the demand for EC2 instances, you can't expect them to keep thousands of machines ready in case someone wants to figure out how high the cloud really scales. It would simply cost too much.

No matter the cloud-hype, in the end Amazon and every other hosting supplier have to limit the amount a customer can provision. Want to go above that limit? No problem, but we'll have to hook up some additional machines in advance.

The cloud is a leaky interface.

Re:How is using so many VMs more efficient?

[slim]

So use 1 server and have 10 client logins on it FFS.

1 client wants RHEL 4.
1 client wants RHEL 5.
2 clients want Windows Server, both want a weekly reboot, but during different maintenance slots.
2 clients want stable Debian, but one wants a weekly 'apt-get dist-upgrade', the other wants it monthly ... etc.

Give each one a VM, and you can deliver all this on one physical machine very, very easily.

Re:How is using so many VMs more efficient?

[slim]

When did installing multiple apps on 1 server go out of fashion?

When it became clear it's a management headache.

"Hi it's ops. You know your foo server sits on the same box as the bar server? Yeah, well the bar guys have found out they need a kernel with a higher filehandle limit, so we're going to be rebooting that box. You'll need to tell your users about the outage. Oh, and you'd better have QA test the foo server with the new kernel too."