Well at least one thing to note there, is that post is from several years ago... both virtualization technologies have gotten better since then, as well as processors.

I think there are certainly specific web and db loads that aren't going to work as well under VM scenarios, but on the whole our experience has been positive. There will, I imagine, always be a slight 'slowdown' due to VM but with the gigantic push toward 'the cloud' right now, it seems to me one of the last things on the minds of most (and obviously Xen is highly used in that field, which is also what we use).

The bigger question I think is if you are using a highly CPU bound task which VM isn't always very good at. According to Etsy they are very CPU bound, so it makes some amount of sense.

I think, generally speaking, once you start having >10 or >50 servers, VMs just stop making sense. You're getting a lot of hardware because you have a problem that requires it, and for most cloud systems with built-in redundancy, you'd only be running a single VM per machine anyways. Why not just run the machine? You should be using puppet or chef or something so it's not much/any harder to refresh a raw machine than it would be to refresh a VM image.

Well, homogeneous management of applications/appliances on top of heterogeneous hardware is one reason. Another is testing and prototyping (on the same stack as you do production).

I think most shops with a high hardware need would probably have a mix -- things that scale well to the hardware (eg: database servers) might be set up as clusters of physical machines.

Less (performance) critical stuff like mail servers, bug tracking and time sheet appliances, backup domain controllers etc -- might be run as vms.

I agree that if you find yourself running a single vm on a physical box, you should probably reconsider how you are doing things...

Then again, all things considered -- if your (presumably) easy-to-mange vm based setup gives you enough performance -- why not keep it.

If nothing else as you upgrade hardware, if your workload doesn't increase exponentially, you will be able to consolidate on fewer servers. Consider a database service that in 2003 was set up master-slave on two physical pizza boxes. That could probably be run from two vms (on physically different boxes, for redundancy) -- with capacity to spare on either box today.

I think this it where we get back to the CPU vs memory bound tasks. If the task allows you to be running 1/8th of a newer Intel/AMD cpu at any given time (also accounting for bursting), why not look if you can squish some instances together? CPU bound I fully agree with you (although I wonder how hyper-scale type companies like Zynga did an analysis at this level and decided upon their stack... if there's a writeup out their about their decisions I'd love to see it actually... sorry, off-topic slightly).

Most 'cloud' software like Hadoop, Cassandra, clustered Mongo or whatever makes it a point to solve that problem in userspace software, giving you a view of 'one big app' across a bunch of machines. Since that's your level of interaction with the system, VMs tend to not really make a lot of sense, they just give you new opportunities to make mistakes while imposing a small performance tax.

Now, if you have 10 legacy apps on old P4 xeons and want to lump them all onto a sandy bridge server and save a bunch of power and rackspace, then separate VMs on one machine makes sense.

Basically, a cluster of 30 servers, all running exactly one VM doing the same thing is on-its-face silly. Why even have the VM then?

The advantage I see with virtualization is that you could use those servers to run your Hadoop workloads on those 30 servers over the weekend and then repurpose those machines for other workloads during the week.

That sounds really good in theory, but in practice it's less good. There are a number of different types of costs to consider: 1. The cost of server hardware 2. The cost of unused hardware capacity 3. The administration cost (people, skills, etc) 4. Opportunity cost

The Cloud(tm) excels at addressing some of these. You don't have to pay /as/ highly for staff to manage you machines and network (the provider does much of that for you). You can run smaller, cheaper instances much closer to their limits.

The downside is that you pay a premium to the provider (even if you are your own provider). Additionally you lose a great deal of opportunity cost. If you use the "excess" capacity on the weekend for hadoop jobs, and need to stop them because you have a large burst of traffic, you've hurt yourself. Your non-production hadoop jobs can also have unexpected and unintended impact on your production web servers, causing your users pain.

Given these things, if you focus is on keeping the best experience for users then you should split things apart.

The actual gain you get from cramming as much as you can onto one piece of hardware is much, much lower than you might expect. It ends up being easier just to get more hardware and dedicate that hardware for specific tasks.

- Avleen Vig, Staff Operations Engineer, Etsy

How long does it take in practice to swap out VM images in this way for different types of loads? How do you monitor that all 30 are ready to go and working right to spec?

A hypervisor is just a kernel with a more clumsy API dictated by legacy hardware design. If you have eight services that can fit on the box together, eight processes on one good kernel should offer better visibility and control over what's going on than would eight VMs each hosting one process (along with some uninteresting crud).

VMs shine when you're stuck with proprietary software that can't all be ported to run on the same kernel, then what you're paying for is a compatibility shim that's cheaper than another box. I don't see much sense for software you wrote in-house.