Background
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 rhelblog.redhat.com. 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.
Conclusion
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”….
4 comments on “Container Myths Debunked (Redux)”