Over the past 3-4 years, containers (like Docker) and orchestration (like Kubernetes) have grown in popularity and continue to grow as one of the most important tools in your toolbelt. Containers have helped development teams test faster, package apps faster, and move across the Software Development Life Cycle (SDLC) faster. Orchestration has helped scale and manage those containers so organizations can properly run containers.
Because of the Docker and Kubernetes popularity in recent years, it's easy to believe that containers and orchestration are a new technology.
That's not the case.
In this blog post, you'll learn that containers and orchestration have been around way longer than you think, and of course, the importance of containers and orchestration.
At its simplest, containers are OS-Level virtualization.
When an engineer thinks about typical virtualization, they may be thinking about systems virtualization using tools like VMWare's ESXi, Hyper-V, VMWare player, Oracle VirtualBox, and many more. When you're thinking about virtualization in that aspect, it's systems virtualization. It virtualizes a desktop or a server instead of installing and running on bare metal (some server).
OS-Level virtualization is going up a step further in the stack. Instead of worrying about the system, you're just worried about what OS the application/software is running on.
In the previous blog post, The Starting Point; OS' and Systems, you learned about Windows and Linux. Those are operating systems (OS) that run on systems. That OS can be virtualized and run in a lightweight/watered-down fashion to just run the components you need for the application to work.
The lightweight/watered-down piece is a container.
It's no secret that Docker has been made a household name for containers, but containers were around way before Docker was invented.
Linux Containers (LXC) were created in 2008, and Docker was created in 2013. LXC didn't catch too many eyes because there wasn't a lot of marketing around it. The technology was just as good as Docker (Docker was based on LXC at the beginning, almost identical), but the Linux community is typically more (at least back then) under wraps, and pure Windows folks didn't really play with Linux too much.
In short; LXC was created way before it's time to shine and there wasn't a literal company running the marketing for it like there is for Docker. From a technical standpoint, when Docker was first created, it wasn't any different from LXC under the good.
Docker, however, made a big splash. It became mainstream for container engines and other aspects of containers, which you'll read about next.
When people typically think about Docker, they think that all it is is a container. There are a few different parts to Docker.
For example, the Docker engine (which runs the containers) is not the same thing as a Docker image or a Dockerfile. A Docker image is a prebuilt container image to run an application. You don't need the Docker engine to run a Docker image. In fact, since Kubernetes v1.20, the Docker engine is no longer in Kubernetes, yet people are still running Docker images. That's because to run a container, the Docker engine isn't needed.
Same thing with a Dockerfile. A Dockerfile is used to create a Docker image, but a Dockerfile doesn't require the Docker engine.
Docker engine == run a container using a long-running Daemon process (
If you don't want to use the Docker engine, you can use another containerization engine, like
Just like with Docker, when you think about orchestration, you typically think about Kubernetes. Kubernetes is definitely the victor when it comes to container orchestration, but there are several other orchestrators out there, including:
- LXD (Linux container orchestration)
- Docker Swarm
Although you may not hear about Docker Swarm and Mesos, for example, all that much, it's simply because there is more hype around Kubernetes. It's the "sexy" orchestrator, but that doesn't mean it's doing anything better than the others. In fact, there are several engineers that still use Docker Swarm because, in some aspects, it's easier than Kubernetes.
What is orchestration? It's a way to scale and manage containers. Think of it as implementing high availability for containers.
You may be thinking to yourself well, I have containers.. why do I need orchestration?
The answer is; containers only run one at a time.
When you run a container, with, for example, the
docker run command, one container is being run. What happens if that container goes down? What if you need scalability? What if the container gets bogged down based on too many requests?
The answer is orchestration. With an orchestrator like Kubernetes, you can run the same container, running the same application, in a scaled fashion with Pods. Pods are a collection of containers.
Orchestration takes a containerized application and makes it highly available.