"All problems in computer science can be solved by another layer of indirection [except the problem of too many layers of indirection]".
-- David Wheeler
A "layer of indirection" in the quote above can refer to any additional layer of software for the purpose of abstracting a system. This includes subprograms at the most basic level, classes in object-oriented programming, packages in package managers, containers, etc.
Containers are a powerful tool and valuable addition to available software management methods. A container is an isolated environment in which software runs, separated from software running on the host system and software running in other containers. As such, containers are a highly valuable tool for sharing system resources in a secure manner. For example, we can run many web servers on one machine, all completely isolated from each other, so that if any one of them gets hacked, the others and the host system itself should remain safe (barring security leaks in the container system used). Containers are also useful for doing test builds of software in a pristine environment, where no extraneous software is installed that might interfere with the build. For example, before being committed to the official collection, virtually all FreeBSD ports are tested using a tool called poudriere, which performs software builds in a sophisticated container system called a FreeBSD jail.
Containers have, unfortunately, become a trendy solution looking for problems, and as such have found their way into many areas of outside their legitimate uses. There are legitimate use cases for containers in research. Unfortunately, though, they have also become popular as an alternative to quality software development and build systems. Rather than writing portable software that works with mainstream libraries and is easy to build and install alongside other applications, many developers have recently chosen to containerize software so that it can continue to use outdated libraries (often with known bugs and security holes), and poorly designed build systems that end-users would struggle with on their own. Developers build and install poor quality software inside a container, and users download the container rather than try to build and/or install the software directly on their computer. There are a several major problems with this approach, including, but not limited to the following:
It removes motivation to improve the software, keeping it working with the latest libraries and other dependencies for the sake of reliability and security.
All users must use the same container system into which the software was packaged. This is added overhead for systems managers and users alike. There are many container systems available, and developers don't all support the same ones.
It limits the portability of the software, since the end-users can only use the containers on platforms compatible with the build. E.g., if a program is compiled in a container under Ubuntu Linux on x86_64 processors, that container will not work on other operating systems such as BSD, macOS, and likely not even other GNU/Linux systems such as Redhat Enterprise Linux. It also will not work on processors other than x86_64, such as ARM, Power, etc.
This is especially a problem when developers don't agree on which platforms to support. End-users may end up having to maintain multiple computers and/or virtual machines in order to use different software containers.
Maintaining the software and build system to make it easy to build and install on any POSIX operating system and any CPU architecture eliminates these issues, and in the long run, results in less work for both developers and end-users alike. This is especially true if the software can be installed via a package manager.
The containerization fad has faded somewhat in recent years as people have begun to see the down side of added overhead, and removing the motivation to fix problems and keep software up-to-date. You may find that they remain the only viable option to installing certain software, however. Adding such software to package collections is often difficult, since the developers are not always cooperative about accepting patches to bring it up-to-date with modern libraries, etc. More on this in Chapter 40, Software Management.
Are containers "good"?