Hacker News Reader

Comment by CrLf | Hacker News Reader

> Containers allow us to condense workloads in a single OS runtime –while preserving isolation– where otherwise the same workloads would have spanned multiple machines or VMs, each with its overhead and slack (unused resources).

I'm starting to believe that the increased density provided by containerization is a myth, in practice. Both because orchestration tools bring their own overhead (compare all the proxies and filesystem/network overlays with multiple virtualized kernels) but also because containerization goes hand-in-hand with microservices thus increasing the number of components (often times with no real reason other than to be hip).

If you're running 20-30 containers on a beefy VM, you're not really condensing anything. You're just moving from running hundreds of small VMs on a single server to running much less larger VMs.

View on HN

> If you're running 20-30 containers on a beefy VM, you're not really condensing anything. You're just moving from running hundreds of small VMs on a single server to running much less larger VMs.

Of course you are condensing. Those small VMs would have been running a full OS runtime each.

Assuming you relocate those workloads onto a single machine (1 process = 1 container), you no longer run 20-30 copies of an OS, just a single one.

And the container engine takes the place of the hypervisor.

> Of course you are condensing. Those small VMs would have been running a full OS runtime each.

That's something but probably not as much as you think since hypervisors can share identical pages (e.g. the Linux kernel) across guests and the base footprint for a server Linux install is not that high as a percentage of the private data most applications use. Unless you're running a ton of unnecessary services on those guests or have an application which uses almost no RAM you're talking about a fairly modest percentage savings even before you factor in all of the things you might be running for container management and other overhead on that side.

The other thing to remember is that this works both ways: containers are great for being able to upgrade one component independently but that means that e.g. you might have a dozen different versions of a common shared library because not all of your containers are using the same base image & version and with Docker your storage driver might actually force shared libraries to be duplicated across all processes anyway.

> since hypervisors can share identical pages (e.g. the Linux kernel)

With ASLR, I'm now sure the gains are that substantial.

The parent doesn't mean that the hypervisor will merge identical MMU->physical page mappings (like a Copy-on-Write process fork would); they mean that VM pages' underlying host virtual pages literally get periodically hashed for their current content by a background process on the dom0 and merged when they are found to have identical hashes. The underlying virtual page is then made copy-on-write.

Or, to put that another way: the host memory for most modern hypervisors consists of a heap of "new" pages, and then a generational garbage collector that moves said pages, if still alive, into a content-addressible "old" store.

As such, if two VMs each have a process that

1. calls malloc() 1000 times to get 1000 1-page buffers randomly spaced through their memory, the mappings different for each VM; and then

2. uses a fixed PRNG seed to generate random data [but the same random data] to fill those pages;

then those two processes' pages will still get collapsed together for a 50% savings.

I'm not sure that e.g. OpenVZ or LXC would have that much larger a footprint in RAM, even if they do have a full OS runtime. A few more daemons running, that would be it.

Everything else is mapped onto the single Linux kernel, and many pages are shared as a result; I think that even libs are able to be shared across VMs; so if you had 2 identical versions of glibc in 2 VMs, only 1 would be loaded and used.

Doesn't LXC also mean containers? Like, the C literally stands for "Container."

LXC (with LXD) or OpenVZ containers are typically shipping full OS in the container. Docker is different in that it typically only have a few processes per containers.

"Full OS" is confusing here. Let's be explicit:

1. "application containers" are effectively a single process [though that can fork more] with some kernel process-struct fields set to nonzero values, indicating that the kernel should present this process a different view of its environment.

2. "virtual machines" are the processor providing a separate virtualized view of the CPU, on which is then booted another virtualized kernel, which brings up with it virtualized OS services and eventually an app.

3. Between them, "OS containers" are a hybrid: they start up all the userland virtualized OS services that a VM does, but they do so on top of a kernel that's not actually a fresh, separate kernel; but instead a kernel that has been told (through setting tons of containerization process flags) to present to this group of processes a view of the world where this kernel looks like a fresh kernel in a newly-started VM.

"OS containers" are basically a raw optimization over VMs by asking one kernel to pretend to be multiple kernels, and to manage one pool of memory instead of having multiple pools of memory. Anything you can do with raw VMs, you should (in theory, given good inter-container isolation+quota logic) be able to do with OS containers as well.

Containers are an abstraction that exist using cgroups and namespaces for isolation. They use the hosts' kernel, it's not virtualized. Containers are only limited by the capabilities of namespaces and cgroups, unlike vms.

You might be dismissing microservices too quickly. They do have overhead but so does any level of abstract; the benefit of them though is clear separation of responsibilities between services and residency(Swarms, clusters, etc). Both can be achieved with Vms but VMs weren't built with these goals in mind

Using VMs to isolate single processes is like owning multiple toasters, and buying a different house to plug each toaster in.

Nah, that is separate physical machines. For VMs it's more like a multitenant toaster colo, with every toaster in its own asbestos cage, but sharing power and network^Wbread. For containers, it's like putting them all in one house but putting a fuse and RCD on every toaster. A traditional server is building a custom house each time and the toasters are all plugged into the same socket.

I'm not sure the toaster analogy will gain mass acceptance.

What if you're hosting toasters owned by people who might be rude teenagers who want to set any house with a rival toaster in it on fire?

When Docker can safely protect a Minecraft server in one container from a local DoS attack coming from a bot running in a sibling container, I'll reconsider using VMs. :P

Resiliency

Well, at least for our company we definitely see the gains and we absolutely don't see it as a Myth.. Previous project without docker to support all of our dev and QA environments: 9 VMs that we paid for. Most recent project with Docker: 2 VMs we pay for which includes all Dev and QA environments, with natively installed Nginx to hide the port differences.

It really do seem like we can't win. Try to get more control in one place, and things sprawl out of control somewhere else.
containers bundled up libs and binaries in a single package, only for an "app" to come reliant on a zoo of containers doing one little part of the whole.
Makes one wonder if the stack is made of rabbits rather than turtles...

But you can argue the overheads are birthing pains.

Reply on news.ycombinator.com