What I find really funny in tech today is that so many people hype up things like Blockchain or AI. While they are two really great technologies, and can potentially solve a lot more problems, there is just too much hype around them in the internet. Let's get to a more interesting topic that EVERY software developer should master as soon as possible in his career - containerization.

Back to the (ch)roots

Containerization was first introduced in 1979, but didn't gain traction until way later when Docker Engine was released in 2013. It has matured since and today we can say that it is a well rounded technology with several benefits. But before we get to those, let's first discuss what container virtualization is exactly. And for that, we will first take a step back to see the bigger picture.

To understand where we are coming from, let's go back to the future. In the past, every developer had to install and configure his own development environment. This is something each and every one of them had to do for themselves. A repeating process that can take hours if something doesn't fit. And we all hate repeating processes. They eat away on our productivity and hinder us at actually building the applications we want to build. No bueno.

Getting to the solution

Alright, how do we fix this inefficiency. Well, it's actually quite simple. Let's discuss container virtualization - or containerization. When we are talking about containerization, we are talking about the virtualization of applications into their own environments, similar to a virtual machine. However, a container doesn't actually have their own operating system like a virtual machine has one. Instead, they are on top of what is called a container runtime (e.g. Docker Engine, CRI-O, containerd, etc.). This container runtime is responsible for managing resources and automating the process of running applications in isolated, lightweight environments.

Our goal is to now automate the whole process of getting a development environment up and running so that the developers don't have to do it themselves. Essentially, we want to define a Dockerfile where we specify all relevant parameters for running our application. Imagine you are in a project right now with a web application, a database and multiple microservices. What you don't want is to download and install all the different software development kits for each developer. Like we said, this is a repeating process. And we don't like that.

Here is where the Dockerfile comes into play. In the Dockerfile, we define the version of our application runtime and all the other things we need for our development environment, and that's it. We would define the version of node, the database and the microservices, making them fixed for every developer. We clean caches, we install the required dependencies and so on. We basically do everything what we would do if we wanted to setup a development environment for a new employee. The only difference here is that we do it in a Dockerfile. Check out (the docker tutorial)[] if you want to learn more about how to create your first Dockerfile.

Making use of your Dockerfile

Great, we created our Dockerfile with all relevant information and parameters. Now what?

Now the only things we have to do is to create a docker-compose.yaml and a devcontainer.json, and we are good to go! We won't go into more detail on how to create those two, but if you want to learn more, check out the documentation for (docker compose)[] and (devcontainers)[]. They are fairly easy to create, I promise.

Those two files give us the ability to open the Dockerfile we created before in a code editor like Visual Studio Code. For that, you need the Dev Containers extension from Microsoft. After you installed the extension, you can open the project inside a devcontainer, which is the same as if you ran docker compose up in the command line. Whatever commands you now execute into the devcontainer, you do so in the Dockerfile environment that you created.

Benefits of containerization

The first and obvious benefit is the automation of installing the dependencies and versions for our developers. There also won't be any bugs because of version mismatch, since every developer will develop on the same image with the same parameters, making a version mismatch impossible.

Second, it makes continuous delivery much easier. The syntax for Dockerfiles is relatively easy, and because you can use base images, half of your work is already done before you started it. Replacing the Dockerfile in your production Kubernetes cluster is also a piece of cake. All you have to do is to execute this simple command:

kubectl set image deployment/nextjs-deployment nextjs-container=my-nextjs-app:2.0

No more upload scripts. No multiple jobs in your GitHub Actions workflow. Just this one command, and that's it. The image is updated, and so is your live app in the web. The size of your CI/CD pipeline is reduced by 50% and the complexity by 80%. BIG THANK YOU for all the people at Docker that made this possible and open source.

And last but not least, it is a step in the direction to the cloud. When we use Docker, we are automatically one step closer to using Kubernetes and other cloud providers like Azure or Amazon Web Services. Infrastructure as Code, another very hot topic that also requires knowledge in containerization. Those technologies have already become the cornerstones of IT today. They are vital for every lead developer position.

Conclusion

The IT landscape has evolved dramatically over the last years. LLMs have basically exploded and there is one crypto boom after the other. But we should never forget what containerization has done for our industry.

The sheer efficiency boost and the extensively shortened time to marked are vital to so many IT projects. We get to spend less time troubleshooting silly errors like version mismatches because the developers are having different environments on their local machines. And we get to spend that time thinking about innovative products and building those.

Because this is what this job is actually about. Building.