Think of both as ways to get a consistent baseline system which your configuration will be applied to. It's faster to spin up a VM or container than it is to do a fresh install on bare metal so you can realistically test that you really could do a clean install from the documented starting point.

Containers add even faster startup time and the option of isolation so you can have multiple containers which think they're writing to the same location but actually aren't. That's not terribly important in a one-app-per-system model but it's awesome for testing or running multiple instances of an insufficiently-configurable app on the same system.

> Call me a simpleton but I am happy with better package management and config systems.

Fundamentally (in terms of process, not technical implementation) that's all containers really are.

Run this, with this config file, and everything is pre-packaged for you in a bundle you can ship to your prod server if you like (or not, run it locally, whatever).

It's quite nice. I shared the skepticism ("so.. it's just VM's then? So what?") but having switched to a dev toolchain using it - it's actually a LOT simpler than developing locally normally.

"I do not have time to get into this new .... thing" is pretty much the kind of thing that leads to problems like the original article.

Containers are pretty flexible (unfortunately?). They can be used as a stop-gap to everyone jumping ship to Nix (we can only pray to god) somewhere down the line in that they let you get some decent isolation properties out of existing package management.

Since you can pretty much use any config management system you like with containers, they also play nice with that too.

There is one other ancillary benefit in that they enforce a little bit tighter process isolation than you might get if you just installed a bunch of stuff on a given server. So that lets you do things like overcommit available resources (put more on the server than it can run at one time, but stochastically, it can probably handle) and it helps ensure you have "livestock" and not "pets" (servers configured automatically, repeatably, and with no concern with their demise rather than servers you need to baby).

They're pretty much just a (mostly) handy abstraction for a bunch of things that you probably want to be doing but is exceptionally frustrating to set up piece by piece.

"New" VM thing? It's only been around for eons now.

I had similar views, until I did some contract work for distributed systems platform. I have written a demo app that connects to twitter stream api and pushes data to elasticsearch instance running on Apache Mesos. One thing that struck me was separation of concerns principle, starting containers on a cluster with Marathon and Mesos is such a breeze. No complex deployments or package management, everything is isolated from each other very neatly and thoughtfully. Of course, the complexity is by orders of magnitudes higher and this tech comes with its own bundle of "joy", like maintenance difficulties and monitoring issues, but what new tech doesn't?

Basically, it allows you to requisition servers more quickly by providing a baseline system. If you're not doing scalable-on-demand work (and most of us aren't), it's not that useful.

Virtualisation gives you much better use of your physical resources, gives you a heap of flexibility, provides much better remote control of machines, and has been around since before the year in your handle.