Container

A program rarely runs alone. It needs certain auxiliary files, certain settings, and often a very specific version of them. If one of these parts is missing, the program either won’t start or will behave incorrectly. A container is a package that bundles the program together with all these ingredients. You copy this package onto another computer, and there everything runs exactly as it did before. The name comes from the shipping container: anything can be inside, but the outer shape is always the same, which is why any crane can handle it.

The end of “But it worked on my machine”

Before container technology, one sentence was notorious in software companies: “It works on my machine.” A developer would write a program, it ran flawlessly for them, and it crashed on the server. The cause was usually trivial. The server had an older version of an auxiliary file or a different setting. Finding such bugs often cost days.

Containers solve this problem at the root. Because the environment travels along with the package, there’s no longer any difference between the developer’s machine and the server. This makes software much faster to deliver. Large providers today release new versions of their services multiple times a day without users noticing anything.

For AI, there’s a second aspect. AI models depend on very precise versions of their computing libraries, meaning the software that carries out the calculations on the graphics cards. Even a slightly different version can lead to different results or to crashes. Anyone who ships a model in a container fixes these versions in place. This makes research results reliably reproducible.

Distinction from the virtual machine

Every computer has an operating system, meaning the base software that manages programs and hardware. That’s exactly what’s meant by Windows or Linux. The older solution to the same problem was the virtual machine: a fully simulated computer complete with its own operating system, running inside the real computer. This works, but it’s cumbersome. A virtual machine quickly takes up several gigabytes and needs a minute to start.

A container takes a leaner approach. It doesn’t bring its own operating system but instead shares that of the host machine. Only the program and its direct auxiliary files are packed in. That’s why a container is often only a few hundred megabytes in size and starts in a fraction of a second. This lets hundreds of containers run side by side on a single server without any trouble.

So that they don’t interfere with each other, the operating system isolates them from one another. Each container only sees its own files and processes. However, this separation is weaker than with a virtual machine. Anyone processing especially sensitive data therefore sometimes combines both.

Docker, Kubernetes, and the cloud

The best-known tool for building containers is called Docker. It made the technology popular starting in 2013, and many people say “Docker” even when they mean containers in general. A developer describes in a short text file what belongs in the package. Docker builds a finished image from this, which can be copied and started.

Once hundreds of containers are involved, some kind of management is needed. This task is usually handled by Kubernetes. The program distributes containers across available servers, restarts ones that have crashed, and spins up additional copies when demand is high. When reports mention scalable cloud infrastructure, it’s almost always this combination behind it.

You encounter this indirectly, but constantly, in everyday life. Streaming services, online shops, and chatbots practically all run in containers. Even someone who wants to try out an AI model on their own computer often downloads it as a container. This saves the tedious work of installing individual dependencies and turns an afternoon of troubleshooting into a single command.