As a engineer I do not have time to get into this new VM/container thing. I fail to see how it leads to anything productive ( no offence ).
Call me a simpleton but I am happy with better package management and config systems.
Call me a simpleton but I am happy with better package management and config systems.
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.
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.
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.