Container Myths Debunked (Redux)



So lately, I have been hearing a lot about containers vs. virtual machines and I wanted to get in on the action. I saw the a recap of Alex Polvi’s session at OpenStack Silicon Valley and I was inspired. I agree with Alex, and for fun, I wanted to state all of his points in a different way. Let’s rephrase all of his points with the word “container” replaced with the word “process”, I’ll tell you why below.


Containers vs. Processes

I recently published Architecting Containers Part 2: Why the User Space Matters on In the first and second articles of this series, I explain how containers are really just processes with extra protections and data structures in the kernel (see the clone() system call).

So, understanding that containers are just really fancy processes, let’s restate all of Alex’s points in a fun way:


Processes Replace Virtual Machines (VMs)

So, can processes replace virtual machines? Well, there are times when it’s really convenient to have a full virtual machine, like when you are doing kernel development that just happens to crash the kernel a lot. Or, how about when you need two different versions of a kernel? Or, how about when you need to test the upgrade of a kernel? I think you see the pattern. If you are doing something with the kernel, a virtual machine can be useful, not strictly necessary, but definitely convenient. Another valid use case for a full virtual machine is tenancy, see security below.

Legacy Apps Don’t Work [with Processes]

Well, this one gets really fun. So, you mean to tell me that legacy applications won’t work with processes? Really? I think people ask this question thinking of traditional, monolithic applications and get nervous. Well let’s look at where containers started – Solaris Zones were built to run when today’s legacy applications were still cutting edge. Kernel based containers are pretty much processes, so yeah (in voice from Office Space), traditional applications will work.

You Can Only Run Stateless Apps [with Processes]

I believe this is a perception with Docker because it uses copy on write, but I would argue, that as long as you have good separation of code, configuration, and data, you can run almost anything in a Docker style container using bind mounts. The mount namespace was designed to do this….with processes 🙂 Databases, identity management solutions, and systems management solutions are all fair game. Most traditional applications actually have pretty good separation of code, configuration and data – Think about MySQL (/var/lib/mysql /etc/my.cnf)… Furthermore, containerizing these applications gives you atomic update/rollback capabilities, flexibility in when, where, and how long it takes to deploy them.

Processes are Not Secure

So, who would ever say that processes are not secure enough? What does that even mean? Are there any other options? In a modern, multitasking computer based on a Von Neumann architecture, I don’t think there is any other option but processes, so this framing of the question is a straw man argument. Yes, there are times when kernel based containers (aka processes) do not provide a sufficient level of isolation for multi-tenancy. Heck, there are times when a virtual machine or VLAN doesn’t provide enough isolation. Actually, come to think of it, there are times when two data centers that are affected by the same weather patterns don’t provide enough isolation. I think these perceptions change based on use case, sensitivity to security, and particularly over time. There was a time when processes were all we had on multi-user Unix or Mainframe system, and the world didn’t fall apart. OpenShift Online has been running a multi-service, multi-user platform as a service with millions of applications, based on containers, for years…So, long story short, sometimes processes (containerized or not) are enough isolation, sometimes they are not. It depends, but often they are enough isolation.


So, for fun, I replaced the word container with the word process and many of these questions got a lot more interesting. I hope this helps debunk some of the myths and also helps you ask yourself the right questions as you think about deploying containers.

If you want to join the fun, leave a comment below. I would love to hear your container questions rephrased with the word “process” instead of “container”….

Tags: , ,


  1. Container Tidbits: When Should I Break My Application into Multiple Containers? – Red Hat Enterprise Linux Blog - March 16, 2016

    […]  Separation of code, configuration and data will also play into your ability to break your application into multiple containers (or not). If your application has good separation of code, configuration and data, it should be easy to decompose the application. If your application is very old and not well understood – it may make (unwanted) changes to your file system and could be very difficult to decompose. Note that this is OK (!), you don’t have to re-write your application to containerize it. You can still get the benefits of the Docker container format by putting your application into a single container. You will then be able to easily move it around (using a registry server) and deploy it (using docker run). […]

  2. Architecting Containers Part 4: Workload Characteristics and Candidates for Containerization – Red Hat Enterprise Linux Blog - April 21, 2016

    […] are really just “fancy processes” that run in their own pristine user space, so with enough time, money, and willpower almost any […]

  3. Contianer Tidbits: The Tenancy Scale – Red Hat Enterprise Linux Blog - September 8, 2016

    […] We often compare the security of containers to virtual machines and ask ourselves “…which is more secure?”  I have argued for a while now that comparing containers to virtual machines is really a false premise – we should instead be comparing containers to processes. […]

  4. From Checkpoint/Restore to Container Migration – Red Hat Enterprise Linux Blog - September 26, 2016

    […] it is not as fatal as it sounds. For example, when using CRIU to migrate a container (i.e. a “fancy process”) the container will often include not only the actual application to be migrated – it will […]

Leave a Reply