Containerization in Practice
Part One: Critical Q&A for better understanding of Docker and Container Orchestration
Let's take a look at some important whys and hows on virtualization, containerization, Docker, and container orchestration. The post is not intended to explain the concepts itself, but to answer some of the key questions required for a better understanding of the underlying technologies and to introduce practical use cases.
Questions I examine in the post are:
- What is the relation between containerization and virtualization?
- What is containerization and how containers differ from virtual machines?
- Why is Docker the number one containerization technique?
- What container orchestration enables and how it differs from Docker compose?
Virtualization vs Containerization
In a nutshell, virtualization brings an extra level of abstraction above a system, allowing more efficient resource utilization. It also enables creation of many useful tools and services, like Docker containers, which are an example of OS-level virtualization, or cloud computing, which delivers virtualization of resources of different types and on multiple levels.
Indeed, virtualization is an extensively useful concept (and much more abstract than containerization) we get in touch with daily. Here are few other examples, which might ring a bell:
- Virtual Machines (VMs), which are an example of hardware virtualization
- Virtual Private Networks (VPNs), which exemplify network virtualization
- Softwares like Dropbox and Google Drive, which implement storage virtualization
- Tools such as virtualenv for Python, which creates per-project language runtime environment
Virtual Machines vs Containers
Those are very different realizations of a very similar idea — an efficient, isolated environment. In the case of VM, the environment is a complete OS. On the contrary, a container is more like a programming environment, which uses the host OS kernel. Both are defined by images, but containers have more light-weighted images, which makes them more portable. Meanwhile, VMs enable a higher level of isolation (sharing hardware only) and thus provide a potentially safer environment.
Nowadays, containers are mainly used to
- easily apply, share and reuse infrastructure implemented as a code
- implement microservice-like architectures
- on-click apply/try out a software
- implement testing environments (sandboxes)
Overall, to optimize development and deploying process. Meanwhile, VMs are applied:
- to imitate an OS of any flavor
- to perform software testing in a completely isolated environment
- by cloud providers to serve isolated computational environments for users
- for desktop sharing
It is true that some of the functions, earlier performed by the VMs, are now a clear use case for containers. But, as it is mentioned above and as it will be discussed further, VMs sometimes are being preferred over containers. Check out (1) How is Docker different from a virtual machine?, (2) What is the difference between a process, a container, and a VM?, and (3) Containers vs Virtual Machines (VMs) — A Security Perspective for further comparison.
Why Docker is the Most Popular Containerization Software Anyway?
Back in 2013, when Docker released its solution, no other company was a direct competitor. Indeed, other containerization frameworks existed, but only Docker software was able of the technology democratization. It made containers easier and safer to deploy and use than previous approaches. While previous providers kicked off the concept of OS virtualization, Docker implemented it (basing on the existing solutions) so that everyone was able to integrate it into their technology stack.
It also fit perfectly with the DevOps ecosystem (the idea of which started to spread around 2009) as a tool facilitating development and testing and enabling faster release cycles. This is, the timing was just perfect which led to crazily fast integration of the tool into companies’ technology stack. The following graph points out the correlated popularity of DevOps and Docker and emphasizes dropping interest in VMs with emerge of Docker.
Nowadays, Docker is not the only solution, but so far it remains the most widely used one. Check out The Evolution of Linux Containers and Their Future for more dates and historical facts.
When are VMs More Suitable than Containers?
Unlike VMs, containers share OS kernel with the host. This brings some advantages, but some drawbacks as well.
Importantly, it shrinks the user’s choice on containers OS distro. It is not an issue on Windows, but if your machine runs on any other OS you can select only between Linux distros. Hence, if you need more flexibility in OS preferences, use a VM instead. Sometimes you don’t want to share a kernel between your environments. Separate kernels assure hardware-level isolation and, thus, enhanced security. Again, Windows provides a solution for Linux containers named Hyper-V isolation, but there is no option for Docker running on Linux, as far as I know.
Truly intriguing is that Windows for its users implements solutions to both of the mentioned shortcuts using … VMs! Check out the technical post for more information.
What is Container Orchestration?
As one of the main use cases, containers are applied to implement microservice-like architectures. Such an application is split into several loosely coupled components, which are developed, versioned, executed, and scaled independently. Those components cooperate to deliver the final result but overall they behave as separate applications.
Now, container orchestration comes into play to help you manage and optimize such a system. With orchestration, you describe the desired state of your application, set load balancing and scaling conditions, dictate behavior in case of a failure and many more. For a detailed explanation of how container orchestration works check out What is container orchestration? post.
In practice it works in the following way: imagine you deliver a web application. Using orchestration, you may state that you need exactly one container hosting your frontend, whatever happens. You may also set automatic scaling in and out for your backend container based on income traffic. Depending on the context, scaling may be horizontal (adding container instances) or vertical (adding more resources, like CPU and memory to the container). In the world of microservices, horizontal scaling is the leading option. An orchestration software like Kubernetes then does its best to keep the application in the specified state.
Container Orchestration vs Docker Compose
While functions of those two tools intersect, they serve a different purpose after all.
The Docker compose is used for multi-container applications to describe how to assemble and run the application. A docker-compose.yml file contains things you might specify in a Dockerfile (like environment variables, volumes, network configuration, etc.), and additionally defines deployment configuration. For instance, it states whether to build an image before a container launching, which container to start before which, and if to restart a container in case of a failure. The Docker compose also enables to run the complete application by a single command, instead of starting containers one by one.
While Docker compose runs an application on a single host, container orchestration tools, such as Docker Swarm and Kubernetes, can (and mostly are used to) deploy an application across multiple hosts. Additionally to things a compose tool is capable of, it provides fault-tolerance, on-demand scaling, multiple options for load balancing, seamless deployment and more. Overall it automates deployment and describes infrastructure as a code (things Docker compose does as well), but also optimizes resource allocation and increases the reliability of the system.
Overall, you might see how powerful and wide-spread virtualization is, how containerization and Docker, in particular, revolutionized the way we think and develop applications.
Those tools (Docker included) are enormously useful, but also trendy. Unfortunately, companies apply them here and there without a deep understanding of the prospects. While it is useful to understand how you can benefit from the technology, it is also important to think when it is not suitable and what are cases when you really need to avoid technologies like our beloved Kubernetes and Docker. This is exactly what I am going to investigate in my next post of the series “Containerization in Practice”.
