Virtual Machines Vs. Containers: A Matter Of Scope

Containers are the process and environment isolation facilities of the OS. It just turns out that sometimes it's useful for processes to see each other, and other times it's detrimental. Similar for chroot and filesystems (for environment isolation). It turns out that containerization is nothing more than extremely fine grained control over what processes get to do what in a running system. The name for a fully isolated process/environment is "container" is all.

Docker currently, for the most part, creates a basic userland for use within a container, however LXC doesn't require that at all - instead you can just link the existing userland FS into a directory tree. Heck docker even allows this, but it's harder to do some things than others.

> We should need neither VMs nor Containers. The process isolation and environment virtualization provided by the OS should be sufficient, that's what it is there for.

This is of course assuming that there is a common OS that supports the applications that people actually want to deploy. Virtualization at the x86 level has taken off partly because of the support for mixed operating systems. This has provided operations teams additional flexibility and enabled some consolidation of disparate workloads on shared hardware.

Containers are an extension of that process isolation really, not a replacement for it. They allow control to be more finely distributed in a relatively easy many. They also make coordinating library versions (or, more aptly, removing the need to coordinate them) easier.

They also offer easy ways to move applications between machines and locations, even applications that we never designed with any sort of flexibility like that, and for things that are designed for that sort of thing they can offer better flexible scalability.

Yes, there are other techniques for both of these properties, but the existence of other solutions doesn't make VMs and containers a bad solution.

> expensive

They certainly don't have to be this, assuming you are meaning financially expensive.

> over-engineered

I extrapolate from that (perhaps wrongly) that you thing VMs are a relatively recent invention, when in fact they have been around almost as long as multi-processing has. They seem over-engineered on current common desktop and server hardware because these platforms were not designed with virtualisation in mind and the hypervisor design needs to either account for (or just live with) the deficiencies in this area, but with some hardware that simply isn't the case.

> under-performing

Depending on the solution chosen and your processing and IO loads, yes this can be the case - but often the performance effects are negligible especially if you are using containers/VMs to consolidate light-use services on less hardware. A key problem I find is people underestimating the performance hits seen in VMs, perhaps because they've ready to many promotional brochures and not run any of their own performance/suitability tests before deploying to a given platform.

> mis-applied

This is certainly true in some cases, but that can be said for any technology especially when it is on the current buzzword bingo card (XML and XSLT anyone? Great for what they are great for, but oh so many places they hinder rather than help either because they are not the right tool for the job or are just badly implemented)

> but containers look like a nice, minimal extension to the isolation offered by the OS

Which is exactly what they are, by my understanding, offering more than other existing options such as chroot while not being nearly as heavy as fuller virtualisation.

There is an added benefit to VMs: smaller attack surface.

Your average OS kernel has an abundance of interfaces, all of which may have bugs enabling a malicious program to elevate its privileges. The OS<->hypervisor channel can be much more restricted.

With containers, programs in the container are generally talking directly to the host kernel through the same interfaces as any other program, so you don't get that benefit.

It's pretty easy to write a Dockerfile that isn't completely reproducible, like anything that uses apt-get.

I would also say that VM images should be built in an automated way, although VMs do allow you to shoot yourself in the foot.

VMWare + Vagrant + Puppet + In-house APT repository = fully reproducible

anything + external dependencies = incompletely reproducible

PS: "Please note Docker is currently under heavy development. It should not be used in production (yet)."

PPS: Docker runs anywhere as long as that anywhere is Linux 3.2+ on x86. So to run Docker contained apps on my hosts I'd have to run a VM anyway.

VMs are equally reproducable, e.g. through Vagrant or similar. This doesn't even include using tools like puppet or chef within either containers or VMs, and cloning for either.

I'm not sure I follow, could you elaborate? Are there specific things that you think are harder with Virtual Machines?

What about packer.io? Handles both Docker and VMs.