The topic of how to determine if a workload should exist within a virtual machine or a container — specifically Docker — has been pretty hot around the water cooler lately. As I have given this a good deal of thought, a quote from the movie “Can’t Hardly Wait” kept popping into my head from Seth Green rather early on in the movie.
“Class or sex? What shall I do?”
There is additional context to that quote that I have omitted — which you can research for yourself — but the question posed can be changed to “VM or Docker? What shall I do?” Determining which resource should be utilized for which workloads is going to continue to be debated over the coming months and years as applications begin to take advantage of Docker, Mesos, Marathon, Kubernetes and other emerging tools. That being said, there are a few guidelines which I have been focused on when I am asked the question.
Virtual Machine
- The entity cannot be disposed of or thrown away.
- The entity needs to be managed via a configuration management system (Chef, Puppet, Salt, etc).
- The entity needs to run multiple daemons that are not reliant upon one another.
- The entity needs a SSH daemon to be running on it or provide some sort of shell access.
- The entity needs internalized persistent data.
Container (Docker)
- The entity can be thrown away or disposed of with no impact to the application/service offering.
- The entity exists for seconds or minutes.
- The entity runs a single daemon/process that is exposed as a service.
- No persistent data.
- The entity never requires maintenance or manual intervention. When a newer version of the service is released, the old entities are simply thrown away and new ones are deployed.
These are by no means hard and fast rules, merely a set of guidelines I think about when trying to determine if a workload should be built into a container or a virtual machine. Ultimately the service owner is going to have to make the decision for themselves. It is the responsibility of the cloud provider to be capable of supporting both virtual machines and containers within their environments.
The next six months to a year will be pretty exciting as some of these guidelines are refined and a clearer answer to the question becomes available. I enjoy the debate because it means smart people are thinking about the problems we are facing today in the virtualization space.
