Read my lips, says Docker: Containers aren't VMs

A major form of confusion about containers says that they're a next-generation, lightweight replacement for VMs. But container advocates say that's never been the goal

Repeat after me: Containers are not "lightweight VMs." Nor are they meant to replace VMs. Not now, and not anytime soon, either.

That's one of the key messages -- sometimes subtly stated and sometimes not so subtly -- that Docker and its cohorts have been broadcasting for some time about their brave new (well, not totally new) technology.

And now that containers have moved from the "wait, what's this?" to the "what's the best way to use this?" phase, maintaining the distinction between containers and VMs has become even more important to proponents of container tech.

Docker's CEO, Ben Golub, made this point in a luncheon for media held at DockerCon 2016 in Seattle this week. When asked what he saw as the single biggest misunderstanding about Docker, he replied: "people thinking of Docker as a lightweight VM." That implies --  wrongly, in his view -- that they are in competition with VMware or attempting to replace them.

"That's missing the point of Docker," Golub said.

The point, emphasized by Docker creator Solomon Hykes in the show's Monday keynote, is that Docker isn't even about containers per se, but about making applications portable and orchestratable. Containers and VMs are simply ways to make that happen, in different ways and to different ends.

Docker tech evangelist Mike Coleman made a similar point in a panel entitled  "Containers and VMs and Clouds: Oh My." Containers aren't "lightweight virtualization," he stated -- not least of all because VMs are highly stateful and containers have traditionally not been repositories of state.

"Moving to a container doesn't release you from the responsibility of understanding how your app exists and works in the environment," Coleman said. He also noted that there are still some things that virtualization does better than containers -- at least for now -- e.g., live migrations, although there are plans on the table to make live-migrating containers a working feature before much longer.

Containers bring with them fast startup times, simple dependencies, a unified tool chain, and many other bonuses, Coleman noted. But VMs offer better pools and quotas, and the kind of strong isolation that some people can't live without. (Or as he put it: "Maybe some workloads just shouldn't share a kernel with anyone else.")

Another area where Docker is seeking to heighten the distinction between containers and VMs is by not tying itself excessively to the hardware. Virtualization's boom drove Intel and AMD to add instruction-level support for it to new generations of processors, and now Intel's experimenting with a container variant that leverages Intel hardware acceleration technology.

But Docker's less enamored of this path than Intel. "There's the silicon lifecycle, and the open source application lifecycle," Golub said. "What we don't want to do is build optimizations for Docker that cause it to be difficult to move a workload from one place to another."

The mythology of containers killing or supplanting VMs makes for a tempting narrative, one in which a few lumbering incumbents (mainly VMware) have the rugs yanked out from under them by scrappy upstarts -- e.g., Docker, but also OpenStack.

Such a storyline, though, assumes too many things. The biggest assumption is that every workload, every environment, and every set of customer or departmental demands are covered as elegantly and completely by containers as they were by VMs.

Philosophical considerations aside, there are good practical reasons not to see Docker as "VMs: The Next Generation." The biggest  reason is differentiation, especially as other products -- including VMware itself -- add container support. If everyone's "doing containers," what's the appeal of Docker versus any competing technology that now also runs them?

Docker's answer, so far, is to provide a toolset that's minimal and application-focused, something small enough that most organizations can wrap their minds (and devops teams) around it without excessive overhead. If the ecosystem that arises replaces VMs for some people, great -- but the stated mission is to build an app-delivery system that's as potentially distinct from VMs as VMs were distinct from all that came before. After all, it isn't as if VMs completely killed bare metal, either.

Copyright © 2016 IDG Communications, Inc.

How to choose a low-code development platform