Kubernetes and Docker, where did the popularity come from?
In part 1 of this blog series, we explained the difference between containers and virtual machines, which is important to understand since container usage forms the foundation of Kubernetes. In this blog, we dive deeper into the origins of Kubernetes and Docker and why both became so popular over the years.
Kubernetes, not as new as you might think
For some, Kubernetes may sound relatively new, but the technology behind it has existed longer than you might expect. The first spark dates back to 1979 with the introduction of the chroot function. This function allows you to change the root directory of a process to separate the file system from the rest. A container, with no extra configuration, cannot access your files on the host system.
After a long silence, the idea was picked up again in 2000, and interestingly, by a small hosting company. They introduced FreeBSD jails to separate their customers' services for security reasons. These services also had their own IP address. In the following years, other companies developed more and more functionality. Google played a big role here with the development of process containers. With these, you can limit the resources of containers, which later became part of the kernel under the name cgroups. The company LXC provided the first complete implementation. Warden, Let me container that for you, and Docker followed shortly after.
Why Docker?
How did Docker emerge as the most popular solution? Tough question. Why is Linux the most popular Linux kernel? Docker might not have had the best technical implementation, but timing certainly played a big role. When Docker emerged, virtual machines were already a given. Change is good, even in technology.
Docker is an open-source project, so it quickly became very popular. By strongly focusing on marketing and with the help of funding, a large community was built from the start, which helped quickly spot bugs and implement many features. DockerCon is a clear example of this—a convention that attracts a massive number of visitors annually. Even at the first edition, they managed to attract big companies like Google, Amazon, and IBM. Containers have a certain cool factor, and that naturally attracts even more attention when such big names back the technology.
The idea of placing all applications in containers thus grew more and more. And with a very clear use case, Docker played this well: build, ship, and contain. This means you run the application on your local machine, but also on your staging and even production environments. Docker developed a whole ecosystem for this, which made the step to containers much smaller. Docker repositories contain images that you can simply pull from the internet, often including a full installation of your software. Dockerfiles also make it easy to add extra steps to your installation.
Putting your application in Docker certainly brings several advantages. Containers are easy to start and stop. They're small, making it faster to move them to other environments. It doesn’t matter where they run as long as the host system has Docker. This provides some consistency for certain procedures, such as adjustments or installations on your production environment. Since everything is segregated, you can only affect your own application. If it works locally, it should work in other environments too. Well, almost always :).
Now that the technology is more widely known, companies are searching for alternatives that might be faster and better. In Kubernetes, you also have the option of using other container technologies. So Docker is certainly not the holy grail.
Why Kubernetes?
What is the step between containers and Kubernetes? Anyone who has started a container knows that this is often done through the command line. This is fine for five containers, but what if you have 20? In that case, you could use docker-compose to store all the container configurations in files. But what if you have 100 containers that you want to distribute across 4 systems? Here, Kubernetes, or what we call a container orchestration system, provides the solution. We don’t orchestrate all the instruments in an orchestra, but all the containers in your environment. This way, you can easily place a container on a system that has the most resources available. What is the status of my container, and what kind of logs is it generating?
Kubernetes is certainly not the only technology of its kind, but it stands alone at the top. In its early years, there was some competition from rivals like Apache Mesos and Swarm. But this competition was quickly settled, and today, there’s little demand for these alternatives. In some cases, other technologies even use Kubernetes behind the scenes.
The company behind Kubernetes is none other than Google, a name that has gained a lot of credibility over the years in terms of technological advancement. In other areas, however, it’s a bit less impressive. In 2003, Google created a system called Borg, which would later form the basis of Kubernetes. This system runs nearly all of Google’s internal processes in containers. It also provides automatic load balancing and scaling for applications using services. After 10 years, Google made the project open-source, which brought Kubernetes to life. If Google can prove that all of its internal processes run on this technology, it naturally builds a lot of trust.
Today, the open-source project is still the most popular on GitHub. Like Docker, Kubernetes has gathered a huge community behind it. The amount of development and pull requests is enormous. The project continues to grow with new features, although this also brings challenges in the release process. But Google being Google, they’ve perfected the process with a fixed procedure, a rotating release team, and informative podcasts.
Read more about this topic in our third part on Kubernetes!
