Containers vs. VMs: It comes down to state management, networking and sprawl

Understanding the key differences

fight boxing vs

Although vendor-written, this contributed piece does not advocate a position that is particular to the author’s employer and has been edited and approved by Network World editors.

From certain angles, containers and virtual machines look to solve similar problems and they do have many similarities. But would you fault a screwdriver for not being a better hammer? Probably not, they are different tools with their own specific uses.  As technology professionals we need to understand each tool's strengths and weaknesses and pick the right tool for the job.

There's another dimension that also must be factored into the discussion: technology maturity. Server virtualization on the x86 architecture has been in the mainstream since roughly 2001 when VMware introduced its first server software - GSX and ESX. However, the concepts have been around since the late 1960s, with production deployments since the early 1970s.  This is a long time for technology maturation to occur and for a robust ecosystem to develop. Since 2005, VMware has made no less than 20 acquisitions, filling in its technology gaps.

Depending on how you keep score, container technology was also around before VMware existed, but it really didn't go mainstream until, well, now. The container ecosystem is starting to take shape and the first generation of tooling is just now becoming generally available. Acquisitions are also starting to happen more frequently, as vendors jockey for position.

Before diving into my thoughts on comparing VMs and containers, let me say that healthy debate is always a good thing. As technologists, we should aim to make informed decisions and avoid the lemming effect.

There are three areas I want to call out: state management, networking, and sprawl. I'll tackle them in reverse order.

* Container sprawl is more likely than VM sprawl. Sprawl sounds like a bad thing. Who wants sprawl? Sprawl results in complexity. But sprawl is only a bad thing if unplanned or left unattended. Decoupling systems and breaking apart monolithic applications and services has many benefits including scalability and greater deployment velocity. Remember, every change introduces risk. The more isolated the change, the easier it can be rolled back, equating to less risk. If deployments carry less risk they can be done more often. This increases delivery velocity - which is a good thing; it puts features and bug fixes into the hands of users and customers sooner!

It took a while for the manageability tooling for VMs to reach an enterprise-level of maturity. The same will be true for containers, although I bet it'll happen more quickly than VMs as many of the VM management patterns apply to containers. We're already seeing several solutions come available. From Docker is the Universal Control Plane and the recently acquired Tutum. For orchestration we have Kubernetes and Rancher, to name a couple more tools. I suspect we'll see other tools arise before broader consolidation will occur.

* VMs have a broader set of network capabilities. True. For containers this is an area of heavy development. Last March Docker acquired SocketPlane to help fill this gap. The vision is to provide an out-of-the-box solution that also supports extensions. I've watched a few presentations by the SocketPlane guys who are now at Docker -- it's a smart group and they're innovating fast. Docker 1.9 introduced native overlay networking. Is it perfect? Nope. Did I mention they're moving fast? With the help of partners, the networking gap will close quickly.

* Suspend and maintain memory state is not possible with containers. True. VMs are really good at being suspended and unsuspended, whereas containers are not. Containers, specifically Docker containers, were designed for stateless applications, thus there was no need to implement this capability. Interestingly enough, in a recent survey by Robin Systems, three out of four information technology professionals are interested in running stateful applications in Docker containers. In Docker v1.9 pluggable storage volume capabilities were introduced. Flocker, an open source project, provides a data volume manager for Docker. The point here is, with strong interest in stateful containers, enterprise grade solutions are not far behind.

Just as VMs didn't completely eliminate bare metal deployments, I don't anticipate containers to completely supplant VMs. After all, it's often the case that containers are deployed onto VMs. It's not an either-or situation, it's about having the right tools in your toolbox and picking the right one for the job at hand.

DanJones (@kwikstx) is Director of Product Management at Skytap, a public cloud service provider that extends enterprise Cloud and DevOps strategies to traditional on-premises applications. He has held key product and program management roles over a 20+ year career at Nordstrom, Microsoft, IBM Rational and others, with a focus on better integration of development and IT operations for faster software delivery with high performance and reliability.

Must read: Hidden Cause of Slow Internet and how to fix it
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies