Container Virtualization

A program needs more than itself to function. It needs certain helper files, certain settings, and often a very specific version of them. If one of these parts is missing on a different machine, the program crashes. With container virtualization, the program and all these ingredients are therefore packed into a single self-contained package. This package is called a container and runs the same wherever it is copied to. The notorious sentence “But it worked on my machine” thereby loses its basis.

Why software finally moves house with this

Software is rarely run where it was written. A developer codes on their laptop, testing happens on a test server, and in the end it’s supposed to run in a data center. In the past, these three environments differed in hundreds of small details. A container makes these differences invisible, because it brings its own environment along.

This saves not only nerves but above all money. Large providers automatically start up more containers when many users access a service at the same time. When the load drops again, they are shut down. Because a container starts in seconds, this rising and falling works in real time. Only the actually used computing time is paid for.

This is also central in the AI industry. A model often needs exactly matching drivers for the graphics cards it computes on. Setting up such combinations by hand costs hours and can easily go wrong. As a container, the same environment is distributed across a thousand servers in minutes.

A shared core instead of many operating systems

To understand containers, it helps to compare them with the older method, the virtual machine. There, several complete computers are simulated on one machine. Each of them has its own full operating system, that is, the base software that manages programs and hardware. This is very cleanly separated, but costs a lot of memory and takes minutes to start.

Containers proceed more economically. They share the kernel of the operating system that is already running on the machine anyway. Only what belongs on top of that is brought along by each container itself. The operating system ensures that each container only sees its own files and only receives an allotted share of memory and computing power. You can imagine it like apartments in a building: separate doors and separate furniture, but a shared foundation and shared utility lines.

A container is created from a so-called image, an immutable template. Any number of identical containers can be started from an image. Because the separation is weaker than with virtual machines, an important limitation applies: whoever breaks out of a container is closer to the actual machine. For particularly sensitive applications, both methods are therefore combined.

Docker, Kubernetes, and the cloud bills

The best-known software for building and starting containers is called Docker. It made the technology popular starting in 2013, although the underlying building blocks are older. When tech news talks about containers, this format is usually what is meant.

As soon as it’s no longer about five but about five thousand containers, management is needed. This task is handled by Kubernetes, originally developed at Google. It distributes containers across servers, restarts crashed ones, and adjusts the quantity as needed. Almost every major online service you use daily runs on this foundation.

For investors, this topic is relevant because it shapes the cost structure of entire companies. Cloud providers like Amazon, Microsoft, and Google now sell computing power predominantly in the form of containers. When a corporation reports that it has significantly reduced its infrastructure costs, a move to containers is often behind it.