4 ms·
The point is better hardware utilization. Part of the "isolation" that containers provide is resource allocation. You assign limits to the CPU cycles, RAM, disk
by cwp 11y ago
The point is better hardware utilization. Part of the "isolation" that containers provide is resource allocation. You assign limits to the CPU cycles, RAM, disk IO, network IO etc that each container can use.
Without any kind of virtualization, i.e. processes in an OS running on bare metal, processes can starve each other of resources - hog the CPU, fill up the disk etc. Virtual machines like kvm and Xen limit the resource usage of guest operating systems, but that comes with a lot of overhead. Each VM has to run its own kernel and a bunch of user-space programs in addition to the the service you're trying to provide. The disk images have to include a full operating system as well - config files, libraries, executables and so on.
With containers you get the best of both worlds: the resource limits of virtual machines with the low overhead of processes sharing an OS. That means you can run multiple services per machine without them interfering with one another, and you can pack more of them onto each machine than if you were using virtual machines.
So if you're Google (which did the initial kernel work to support containers in Linux) you can get a lot more computation out of your 100K-server data centre if you package all your software as containers and write sophisticated software to distribute them to server and shuffle them around as load fluctuates and batch jobs get run.
For those of us that don't run our own data centres the benefit is much less clear. Running containers on top of virtual machines seems like a pretty terrible idea. With all that overhead, performance suffers and you end up running more containers to compensate, which just makes everything more complicated and more expensive.
I think the current container craze boils down to two things: first, no matter what ugly, undocumented, unspecified process you use to build a container image, once you have the image you can deploy it in a repeatable, consistent way. That's a big improvement over Chef/Puppet right there. Second, fashion. Doing ops the Google way is cool, and it'll make my resume look good even if I'm not currently in a position to reap the benefits that Google does. Being a Puppet expert is so passé.
- TheIronYuppie 11y agoDisclaimer: I work at Google on Kubernetes Portability, as you mentioned, is huge - but beyond that there is also binpacking benefits. You can basically cut your serving costs by 50% or more by using lots of single process containers instead of poorly utilized VMs.
- cwp 11y agoYeah. This is what I meant by "better hardware utilization".