On a previous blog post called Kubernetes ! = Cloud Native, you learned about the differences between cloud native and what Kubernetes truly is. In this blog post, you're going to learn about debunking the notion that containerization == Docker.
Many organizations, products, platforms, and engineers use Docker. Many platforms fully support Docker and very few other containerization engines, but why?
What Is Containerization
Before diving down the path of what Docker is, you first must understand what containerization is. Below is the definition:
"A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. Available for both Linux and Windows-based applications, containerized software will always run the same, regardless of the infrastructure."
Let's break down the definition bit by bit.
"A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another."
What the above is saying is you have an application, like a Go or Python app. Every one of those apps written in those languages will have some sort of dependencies or requirements, which are typically libraries. Those libraries must ship with the application because the application requires it to run. With containers, you can easily (or more-so than VM-based environments) package up dependencies and run those dependencies on any environment. You don't have to worry about whether it's Windows or Linux because the Docker image already has the dependencies packaged.
"Available for both Linux and Windows-based applications"
What the above is saying is all containerization applications can be made up of both Windows and Linux apps, meaning, there's no dependency on a specific operating system. There are Python containers, Go containers, .NET containers, .NET Core containers... the list goes on and on.
"containerized software will always run the same, regardless of the infrastructure."
For the final breakdown - what the above is saying is regardless of what operating system or infrastructure the application is running on (bare metal, virtualized, cloud, etc.) the application will run the same. You can install Docker on a bare-metal Linux server right now and run a containerized application. You can take that same container (the container is based on an Image) and run it in a cloud-based container service, like ECS in AWS or ACI in Azure.
TLDR; Containers are a way to easier-than-other-ways package up an application and run it anywhere.
What Is Docker
Docker is a containerization engine, meaning, it runs containers (like the containers explained in the section What Is Containerization), but with its own way of doing so.
There are a ton of containerization engines, each having it's own way of running containers. To name a few:
- containerd
- CRI-O
- Podman
- runC
- rkt
- LXC
And a few others..
With that, the question typically becomes - so then why is everyone running Docker?
The answer is quite simple - because it's the most popular containerization engine. It hit the technology market at the right time, it was easy to use, and they had a great marketing team.
In fact, LXC (a containerization engine on Linux) was released all the way back in 2008! Which was 5 years earlier than Docker.
It's not that the technology didn't exist before (the first few versions of Docker were actually based off of LXC), it's that they simply hit the market at the right time and in-turn, was able to gain the capital to expand quickly.
Why Docker ! = Containers
When engineers and marketers in today's world don't fully understand what containerization is thinks about containers, the first thought is Docker.
Why?
- It's what is popular today
- It's supported everywhere because of it's popularity
Docker isn't/wasn't doing anything different, conceptually, then the others. For example, with Kubernetes API version 1.20 and above, it's not supporting the Docker engine anymore, only containerd and CRI-O.
That means that Docker won't be running the containers on Kubernetes, which means Docker isn't actually needed, and in-turn debunks the notion that Docker == containerization or it's the only containerization engine that can be used.