[aliguori]

These are all good points and I agree for the most part.

However, I have found that a lot of the benefits of virtualization are often lost because of the flexibility of having a full blown Linux OS. People stick too many services on the host and/or don't know how to properly allocate resources.

I think there is something to a simplified model where you no longer have access to any host environment and can only "fill slots". In practical terms, it makes it easier to implement features, like firmware-style upgrade and rollback of the host, for the masses.

Yes, you can do this with a full blown Linux OS on the host but it requires an operational discipline that most environments don't seem to possess.

I'm not sure I buy the whole "run multiple containers on top of an EC2 instance" thing though. I understand why they're using LXC vs traditional virtualization but it seems to me like it's a case of solving all problems by adding another layer of abstraction.

There are too many different kinds of virtualization so we'll just add another layer of virtualization.

[vidarh]

The "run multiple containers on top of an EC2 instance" is interesting because it is a way of exposing a unified interface for EC2, your local VM, and bare hardware. In practice you'd presumably want to pick instance sizes suitable for your app instead, and keep the number of containers per EC2 vm minimal.

Personally, if I get time, I'm tempted to try to PXE boot CoreOS. Even better if I can do it from Ubuntu's "MAAS", as MAAS supports IPMI for powering servers up/down, and remote control management.

MAAS or another hardware provisioning layer + CoreOS + Docker starts to become very interesting.

[peterwwillis]

I agree that people sometimes mismanage services, in that they might assign too many to a single host, or not make them redundant. I don't know if that's so much to do with a "full blown OS" versus just having a lot of hardware and not knowing what to do with it. The reverse is also terrible, when they spin up a new hypervisor-driven VM for every single puny network service.

The simplified model you're talking about is cloud computing. It doesn't matter if your hosts are virtual or not, the point is having an abstraction layer that manages resources for you so the client application doesn't have to care.

Virt comes into play when you're tailoring your servers to your application. Example: Are you really i/o bound? A thousand 1Us with 4 disks each will deliver more iops than a couple dozen beefy VM host machines, and possibly [read: probably] cheaper than a high-performance SAN. Or, do your services just need segregated resources? LXC (or openvz) will provide that regardless of your hardware, so that may be a good fit too.

The adage 'the right tool for the job' refers not to the most expensive tool, or newest, or the most flexible, or the most anything. It's just the tool that fits right. Could you use a crescent wrench to remove lug nuts from your car? Probably. But it's not the right tool.