People have said many good things about containers. But there is one important thing many beginners overlook. Let’s start with a definition by Docker:
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.
This definition emphasizes the scalability and portability provided by containers. If you are like me who started learning containers by running docker and kubectl commands, you probably already have a good grasp of those flexibilities. However, to truly understand containers, one must also understand the balance between runtime isolation and workload density.
Runtime isolation can be done at different levels such as processes, containers, Hyper-V containers, virtual machines, and dedicated servers. With process-level isolation, the hardware, OS kernel, and system resources (e.g., File System) are all shared. At the other end, with server-level isolation none of those are shared. The container-level and VM-level isolations fall somewhere in the middle. In most cases, container-level isolation implies shared hardware and OS kernel, but not the system resources.
Workload density is about resource utilization, e.g., making the most of the CPU and memory resources on a server in a datacenter. It is defined as the ratio of the resources consumed by one’s workload over the resources one has available to perform that work. The higher the workload density, the more you can do with the computing resources you bought. Simply put, it is about saving money. For many organizations, this is the single most important reason to switch to containers.
Now comes the conflict between isolation and density. The main motivation for isolation is security. For example, if your security requirements mandate isolated File Systems, you need to do at lease container-level isolation since the traditional way of running two separate processes will not work. If your security team recommends isolated OS kernels, you may need to build separate VMs for the different workloads. If a company wants their services to not share the same hardware with any other company, we are looking at server-level isolation. Apparently, the higher the isolation requirements, the more the cost on the extra copies of File System, OS, or server, and the less the room for optimizing resource utilization, in other words, lower density.
The container-based approach strikes a balance between runtime isolation and workload density. This pretty much summarizes this post. As I mentioned at the beginning, there are lots of great things about containers. But it is also worth mentioning that containers are not 100% secure (nothing is) due to the shared OS kernel and hardware. Higher density can also lead to higher risk of hardware failure (for example, when the cooling system fails). However, these are issues we can handle separately. In practice, containers prevail.
Originally published at: https://link.medium.com/exQfMwgka9
Top comments (0)