If you're having trouble deciding between virtual machines or containers, Jack Wallen boils down this choice to two simple bullet points.
For years, virtual machines (VMs) were all the rage. They made perfect sense: Instead of having a room filled with servers, you can deploy all of those systems on a single piece of (impressive) hardware. VMs work very well, can save serious money, and make failover easier. Your server goes awry, spin up a recent snapshot and you're back up and running.
But what about containers? They aren't really all that new (chroot came into play in the late '70s), but have recently enjoyed a major spotlight from the IT crowd. There's a good reason containers have garnered so much attention: They're very cost effective, easy to use, highly scalable, portable, and enable companies to easily expand their offerings.
The big question is simple: Which should you use? The answer may not be quite as obvious. Hopefully, I can help you strip away the complexity of both technologies, so you can make this choice with ease. I'm going to do this by making a case for both virtual machines and containers; in the end, you decide which is right for your needs.
The case for VMs
I make use of VMs on a daily basis. Why? They make testing incredibly simple. I create a new VM, install whatever operating system I need, and get to work. I like this system because I know exactly what I'm getting and have to do little work to get it up and running. It's familiar, requires very little learning curve and gives me a complete foundation with which to work. With the help of VirtualBox, I can clone a VM or create snapshots that allow me to roll back to a working iteration of the machine.
VMs also give me the ability to "pile on" applications into a single machine. In other words, I could spin up a Ubuntu Server as a virtual machine (making sure to give it enough in the way of system resources) and install any and all services I need. If a deployment requires a full-on LAMP stack, but then (later on) should the necessity for an additional service (such as a mail server, FTP server, etc.) come up, all I have to do is install the new service onto the running guest VM and I'm good to go. With this system, I can create a contiguous platform, that offers all of the services I need. And that is probably the single biggest factor that will sway you to choosing a VM over a container.
Virtual machines make perfect sense when you have a beast of a host server that can handle the load of multiple guests and you need to know that, at any given moment, you can spin up a host snapshot, should something go wrong.
The case for containers
And now we have a technology that is currently the most popular kid on the playground. Containers can make life easy, especially when you need to deploy multiple instances of a single application (or service). Say you need more than one Apache or NGINX server deployed quickly; containers make this far more efficient than working with VMs. Because you're deploying single services (as opposed to a full-blown server environment), the container doesn't make nearly the hardware demand as does a VM. Deploying multiple web servers via containers would require significantly less hardware than would doing so via virtual machines.
But hardware requirements aren't the only factor on the side of containers. Thanks to the likes of swarm mode (found in the docker engine), it is possible to create a cluster of docker engines and manage them as a single, virtual system. A docker swarm adds high-availability and failover into the mix; this means, when you're looking to deploy at scale (with ease), you'll probably want to work with containers.
Easier than you thought?
At this point, you're probably thinking, That's a much easier choice than I thought. In that thinking, you would be correct and the choice can be boiled down to these two bullet points:
- Do you need a full platform that can house multiple services? Go with a virtual machine.
- Do you need a single service that can be clustered and deployed at scale? Go with a container.
Question posed and answered. What do you think? Is the choice between VMs and containers truly this simple; or would you add a layer of complexity into the mix?
- How to create a docker image and push it to Docker Hub (TechRepublic)
- How to make working with docker containers easier with Simple Docker UI (TechRepublic)
- How to export VirtualBox virtual machines as appliances (TechRepublic)
- How to automate VirtualBox snapshots with the VBoxManage command (TechRepublic)
- Docker LinuxKit: Secure Linux containers for Windows, macOS, and clouds (ZDNet)