Below is a message I sent to an executive-level person when asked about containerization.
I omitted some technicalities (for instance, containers are not just zip files–they’re compressed layers conforming to the Open Container Initiative specs), but the details are good enough for someone who sees a new technology every five minutes and needs to keep up with it all without knowing every little detail.
Conceptually, a container is just a zip file with a program and all of that program’s dependencies inside. That’s it! When you run a container, you’re just running a program. Don’t let the marketers tell you that it’s anything magical.
So why are containers such a big deal if they’re just programs? The reason is mostly because of how portable they are and how easy it is for developers and IT operators to work with them. Creating a container image involves making a file literally called “Dockerfile” at the base of a project repository and putting some Docker-flavored script in it. Then you can run a command with that file as input, and an image is built on your local machine. You can test with it and make changes as needed by modifying the Dockerfile and rebuilding the image. When you’re happy with it, you can push that image to a container registry, which is just a big repository for container images (https://hub.docker.com/ is the main, official registry most people use). Once that image is pushed, then anyone else with permission can pull and run that image on their own infrastructure, whether it’s a laptop or HPC cluster. Portability is the killer feature of containers.
The other nice thing about containers is self-containment, as the name implies. A container is not impacted by files and libraries on the host machine; it includes all of the libraries it needs to run. This may seem like a waste of space (and it is), but container images can be highly compressed. A container’s compressed size can be as low as 5 MB for very simple applications, but typically a good container weighs less than 200 MB and ideally less than 100 MB. In one way, we might say that what’s old is new again—dynamically linked libraries (or shared objects in Linux) were created to save space—but now that space is no longer at a premium for the most part, we can go back to including everything with a program instead of dealing with shared library version control issues (“Do I need Java 1.8.115u25 or Java 1.8.119u14?” is no longer an issue). Still, if needed, you can map files and libraries from the host OS into a container very easily.
You may hear people talk about the differences between containers and VMs, and while they can solve similar problems (i.e. running a service in a more-or-less isolated manner), it’s really an apples-to-oranges comparison. A virtual machine is an environment with its own operating system kernel, which is why you can run a Linux VM on a Windows host and vice versa. A container, on the other hand, uses the same OS kernel as its host—it’s just a program, after all. This is why you can’t run a Windows container on a Linux machine and vice versa (though Windows can get around this by running a Linux VM in the background).
It’s not all wonderful, though…Since containers share the OS kernel, there are potentially greater security concerns. Also, the portability of containers comes at a cost of complexity for developers (in that they now have to write and maintain a Dockerfile and eventually a continuous integration pipeline for automatic image builds). There can also be issues with architecture mismatches, e.g. I can’t run a container image that was built for x86 on an ARM or Power9 machine (again, it’s just a program, and a program has to be built for the architecture it will be run on). These drawbacks are generally seen as minimal for developers who are trying to share their code more consistently to a very wide audience.
I could go on and on about it, but those are the main reasons why (in my opinion, anyway) containers have taken the industry by storm over the past five years. It’s all about portability and ease of use.