What's the deal with containers?

Why are they everywhere now? Are they just tiny VMs?

Well, kind of.

The key thing about containers is that they're fast.

Like virtual machines, they let you create a simple, isolated world for your application or process to run in. Unlike virtual machines, they start in seconds, rather than minutes or more.

"A few minutes" might not seem like a lot of time but it's a huge difference if you're trying to keep your deploys below "coffee break" speed – about fifteen minutes. Automated deployment to production typically involves deploying your application several times across several environments. AWS EC2 instances can take anywhere between one and six minutes to start up. Spin up a test environment, deploy a canary instance, and then update the rest of your production instances and whoops, now your deploy has taken nearly twenty minutes and that's not even counting tests.

With containers, you're just using the host OS, so your startup costs are rounds-to-zero, and you get to spend those minutes doing more important things, like running tests, or starting the JVM over and over as it loads certificates. (Not joking. Real thing that software I have worked on does.)

What are containers, anyway?

People will occasionally talk about containers as "small VMs" or as a "virtualization technology" and while this is a reasonable metaphor for many purposes, it's also technically wrong. Containers are so fast because unlike virtual machines there's no virtualization. They don't simulate anything, and they don't have to start up a whole operating system.

Containers are a little bit hard to give a crisp and technically accurate definition because they're very abstract but essentially what they "are" is a set of rules that an operating system applies to a process (or a set of processes). Those rules are implemented with kernel features – namespaces and cgroups – that let the kernel limit what resources a process can access and what other processes and parts of the filesystem that process can "see."

Containers allow you to give a process an environment to run in that's almost indistinguishable from being on its own isolated host, but that's an illusion that's only visible to that process. From the kernel perspective, the process running in the container is just another process, and it can be started and stopped at process speed.

Tell me about some software you've hated

I'm working on a thing about prototypes and design how to tell when you need to rewrite software because it's not maintainable and it's currently very operationally oriented. I'd like to hear from folks who have experience writing code on a project that was originally a hack day project, or produced under a tight deadline, and really showed it. What was hard about working on that system? You can reply to this e-mail or send me a note at nat @ this website.

This is a standing invitation, too – I basically never get tired of hearing about software project goofs, foibles, and disasters of all kinds, so bring 'em on if you've got 'em.