Container orchestration and maybe containers in general: some of us worked with them already, others probably heard about them and for some it’s still a new field. So, what am I talking about and why should you care? For those of us who are still exploring this topic I want to give a brief history of container technologies and sketch where we are at with container orchestration.
Although container technologies as we know them today became widely known with the appearance of Docker, we’ve already learned that containers do not necessarily imply Docker. On the contrary, other containerization concepts emerged already much earlier.
The chroot system call has been existing in Unix since 1979. It restricts the file system access of a process to a given sub directory, effectively making the sub directory the new root filesystem for the process. This is a concept similar to how containers receive their own root file system today. A typical use case was to chroot externally available services like Apache webservers. As time progressed however security became a point of concern.
In 2000 FreeBSD made jails available, introducing virtualization on a process level as we know it from containers today. Every jail provides an isolated compartment inside the same kernel making it essentially a separate FreeBSD instance on the same machine.
Similar solutions were introduced for Linux over time and in 2008 LXC became part of the mainline kernel. In 2013 Docker entered the stage, quickly attracting attention and making containerization popular. But why did it take so long?
Frequently mentioned is Docker’s user-friendliness, having a quick and easy setup procedure which allows for immediate execution of applications. This is also due to the concept of application images and registries. From the very beginning Docker followed the idea of readymade images which are available in a public registry and can be executed with a single command.
Another reason is the emergence of microservice architectures and the DevOps challenges coming with it. Or in other words, Docker came at the right time. The modern concept of microservices was already in the making for some time but around 2013 the term was cemented.
Google trends show both a rise in interest and popularity at a similar time. Yes, we all know correlation does not imply causation. But I see both going hand in hand. To me this is an important factor why container technologies became highly interesting to application developers and architects.
Although microservices in essence mean an architecture “Organized around business capabilities”, a promise often made from a technical point is scalability and resilience of microservice architectures or respectively the microservices themselves. This now leads us to Container Orchestration.
So, what is the purpose of container orchestration and what do we gain in the end?
As we’ve seen before Docker allows for easy execution of single applications. If you have to operate a microservice architecture or multiple applications and also want to reap the promise of scalability and resilience you can end up with 100s of containers. To manually execute, distribute onto a certain machine or node, monitor, and maybe replace them will be a huge effort.
Orchestration tries to abstract this overhead and selects the machines to run the containers on, monitor and restart or replace them if necessary. Scaling and resilience make load balancing on a single machine or over multiple machines necessary, which can also be taken care of. Aside from load balancing, automated scaling based on a defined load metric can be configured.
Depending on the solution many other aspects are taken care of: providing generic health checks of single container instances which can also be customized to detect specific erroneous behavior of an instance, storage volumes, managing configuration to parameterize container images for different use cases.
The term “declarative” is often heard when talking about configuration. This means you define the intended state of your application and the orchestration will do its best to maintain it. An example is the reassignment of containers or services to certain nodes in the orchestrated cluster.
Now that we've seen why Container Orchestration can be of value for you, let's have a quick look at some better-known solutions which are currently on the market.
With Docker there are two solutions that historically need to be differentiated between: Docker Swarm “Classic” is a standalone addition to Docker, whose development began in 2014 but has been stopped. Docker Swarm mode is the clustering solution integrated into the Docker engine and therefore already available with every Docker installation. It provides the basic orchestration functionality like scaling and load balancing. Because of its availability it can be used for quick setups and experimentation.
This small online training gives you starting point for Docker and some basics of orchestration using Docker Swarm mode: https://cognitiveclass.ai/courses/docker-essentials
Kubernetes was initially developed as Google's solution for container orchestration and has since been gifted to the CNCF. For productive use a much more sophisticated setup than Docker Swarm mode is required. Still, there are tools available for setting up a local learning environment. Kubernetes introduces additional logical concepts for structuring your applications containers into so called Pods and Deployments. This makes for a steeper learning curve and requires some additional familiarization.
There is a multitude in different Kubernetes offerings for on-premise installation and offerings for cloud operation. Most notably Rancher and OpenShift as well as Google Kubernetes Engine, Azure Kubernetes Service and Amazon Elastic Kubernetes Service. They introduce their own tools and services for integration into an enterprise environment or allow orchestration over multiple container clusters.
I hope this introduction sheds some light on container orchestration, the different topics and names coming with it and makes you curious to dig deeper. Happy hacking!