The Franconian
Coder Studio

Docker was released 12 years ago and has been a loyal companion ever since. Containers offer an incredibly simple and lightweight way to isolate processes and limit resources. Personally, I used to rely on KVM, OpenVZ, or chroot jails. Docker brought a breath of fresh air to application operations—especially when you needed to run multiple applications on a single host in a controlled manner.

The Technical Foundations of Containers

The basis of containers is surprisingly simple. Linux kernel features like namespaces and control groups (cgroups) provide the necessary isolation, as well as the limitation and monitoring of system resources. Capabilities allow targeted access to the host system. A union filesystem enables filesystem layers, making it possible to share base image layers and save storage space.

Technologically, containers are a very simple concept—one could even recreate them manually. Similar effects can be achieved with systemd or Ubuntu’s snaps. However, these abstractions often lead to the fundamentals of this technology receiving little attention, especially among younger colleagues. They are taken for granted. And often, even more abstraction is demanded—usually in the form of Kubernetes, which abstracts even further.

Kubernetes and the Abstraction Trap

Kubernetes is often seen as a universal solution for efficient and scalable application operations, frequently equated with cloud environments. In reality, it is completely independent of them. Personally, I expect that in the coming years, there will be a renewed focus on the basics. Using the underlying technologies, powerful and flexible environments can be created that don’t need to hide behind Kubernetes—on the contrary, they often have advantages: less black box, more control, lower costs, and fewer dependencies. Back to the roots! Unfortunately, abstraction all too often means that the underlying foundation is no longer understood—and that often comes at a high price.

Containers in Development

For many use cases, a simple container solution is entirely sufficient, both for operations and development. Containers nearly eliminate the “works on my machine” phenomenon. If even the build process happens in containers, the environmental conditions are clearly defined. Such containers then truly run “anywhere.” Additionally, complex toolchains don’t need to be installed locally—they are simply provided via suitable images. This way, containers create a harmonious development and operational environment.

Docker Compose for Complex Setups

If you have dependencies on other services, such as databases, more complex setups can also be created effortlessly. Docker Compose is an elegant solution for defining dependencies. It considers startup order, checks health status, and even allows scaling services—not automatically, but through configuration and commands. A Docker Compose setup isolates an entire environment, even on the network level, creating replicas of large environments, for example, for intensive testing.

The Twelve-Factor App and Secrets

In the context of container applications, The Twelve-Factor App is often discussed. This concept, developed by Heroku as early as 2011, generally makes absolute sense. I’d like to briefly touch on III. Config here. Unfortunately, this principle is often used to inject secrets into containers, which can cause security problems. Ideally, an environment variable would only reference a file where the secret is stored. Environments like Kubernetes or Docker Compose offer native ways to provide such files from the outside. The _FILE suffix has established itself as a de facto standard here, as can be seen in images from MySQL or Postgres.

Recommendation: Understand the Fundamentals

I recommend everyone familiarize themselves with the basics of these technologies. It’s worth manually setting up a more complex container setup, experimenting with networks and different permissions. Depending on the use case, alternatives like systemd can also be used. Understanding the fundamentals not only creates control but also the freedom to develop tailored solutions—without depending on excessive abstraction.

Have thoughts on this article? Join the discussion on —I’d love to hear your perspective!