title: VMs, containers, config control or all of the above? link: https://onemoretech.wordpress.com/2015/12/07/vms-containers-config-control-or-all-of-the-above/ author: phil2nc description: post_id: 10242 created: 2015/12/07 12:36:08 created_gmt: 2015/12/07 17:36:08 comment_status: closed post_name: vms-containers-config-control-or-all-of-the-above status: publish post_type: post

VMs, containers, config control or all of the above?

In the never ending quest for the perfect solution to keeping development in sync with production, there are a lot of products in flight. Which one is best? First there were virtual machines: VMware, Xen, libvirt (KVM). Then containers: FreeBSD jails, Solaris zones, Docker. Then, configuration control: configuration as code products like Puppet, Chef, Ansible. And, finally, hybirds like Vagrant that combine elements of all three. Virtual machines had an obvious appeal to data centers strapped for physical space, and offered some nice amenities like snapshots. But each VM runs its own kernel in its own system memory. Containers, most recently Docker, promise segregation of application environments without the overhead of multiple machines. But most Docker containers are not designed to be upgradable and, more importantly, can wind up consuming as many resources as a traditional VM. A system kernel simply doesn't take up that much CPU and memory in the background. It's system services (Apache, Tomcat and MySQL) and applications that use the most resources, and a typical Docker container will have both in abundance. Configuration control systems, while fairly complex, seem to be on the right track. Like Vagrant, which leverages whatever existing VM technology at hand, they let you set out the environment configuration you want in advance. But to be really useful, those configurations need to be detailed and well thought out. The main point is that none of these products is a silver bullet. Further, simply layering them on top of each other is going to be a waste of resources that will lead to such horrific complexity that even the original authors won't be able to parse things out. There is no best solution, but there is a need to find the most applicable, most efficient solution that works a specific need. Vagrant has promise as a means of building out developer workspaces, but will probably need to be combined with some kind of more granular configuration control. For those of us with the freedom to supply our developers with our own standard virtual machine images, Vagrant will probably be unnecessary, or even confusing (although I will encourage my devs to look into the Vagrant image repositories in anticipation of someday posting a generic workstation image there some day). I'm still not quite sure about Docker. The argument that it's easier on resources than distinct virtual machines seems a stretch, especially in places where you're dealing with constrained CPU and RAM resources and have even a passing concern for the need to keep things patched in the interests of security (this is also a concern with Vagrant -- those pre-packaged images are pretty ad hoc in nature and no one seems to address the maintenance issue). In the end the most important thing most sysadmins, devops, and their managers, will need to grapple with is the question of what will give them the most "bang for the buck", with "bucks" representing not only license and maintenance fees, but also man-hours spent planning, deploying and supporting whatever solution (or set of solutions) gets put in place.

Copyright 2004-2019 Phil Lembo