[tofflos]

I like the tooling better and suspect that many other developers feel the same. Docker is more like managing and configuring software libraries and dependencies. You just declare what type of environment you want and it's there. If you change the version number of a dependency the old image is discarded and a fresh one is created. The Dockerfile is managed with the source code.

VirtualBox feels like installing a regular computer. It takes a long time and is a lot of manual work. If you want to change something you login on the existing VM until you reach a point where you no longer remember all the changes you've made over the years. The machine is unclean.

I realize that there are solutions out there for automating VM deployments but Docker did a good job of catering, and perhaps marketing, to developers.

[sergiosgc]

> VirtualBox feels like installing a regular computer. It takes a long time and is a lot of manual work. If you want to change something you login on the existing VM until you reach a point where you no longer remember all the changes you've made over the years. The machine is unclean.

Unfair comparison. People running on VMs usually rely on configuration management to do the install+config part. Think of stuff like Ansible as a Dockerfile for VMs/bare-metal.

[Spivak]

Config management isn't a magic bullet. At the core every config management platform is manual work in a for loop. Lot's of layers in the case of Salt/Puppet to make it a bit more ergonomic but you're ultimately still on the hook for all the server maintenance. No config management is all-encompassing and so without extreme diligence you will lose the state of your servers over time.

I use Ansible all day every day -- it's not comparable container tooling in the slightest.

[aeorgnoieang]

Containers aren't a magic bullet either. Surely the core of container systems is also "manual work in a for loop". You're right that the default 'ephemerality' of containers is (or can be) a plus but config management tools don't require one to treat one's servers as 'pets'.

> No config management is all-encompassing and so without extreme diligence you will lose the state of your servers over time.

I'm not sure exactly what you mean by "all-encompassing". Surely all of the popular config management systems have 'escape hatches' to let you do anything you could do from a shell, which seems pretty "all-encompassing" to me. But if you mean the config management system don't completely enforce a specific 'state' for managed servers then of course you're correct. Containers don't do that either, beyond periodically replacing running containers with new ones created from a base image (and even that's almost certainly not perfect either).

Unless your container hosts are entirely managed by someone else (and probably even not then, in the fullness of time), you're always going to "lose the state of your servers over time". There's (almost always?) some state somewhere that has to be explicitly managed and thus requires, generally, "extreme diligence".

I do agree that containerization and config management are very different but, like everything, it's 'just' another set of tradeoffs to be made, hopefully depending on one's actual or expected needs and wants.

[notyourday]

> I use Ansible all day every day -- it's not comparable container tooling in the slightest.

Only if you are not actually cleanly managing containers. With containers you just pile the shit into them, close the doors and say "Oh look, we have a clean surface!" which is certainly fine in the dev.

If it is fine in production, then it does not matter if the shit is in containers, VMs, dedicated servers, etc. Container may as well be curl http://mylservice/containername.img followed by dd if=containername.img of=/dev/sdb ; set-boot-flag-sdb ; reboot

[notyourday]

Docker manages dependencies and libraries as well as whoever created the docker images manages those dependencies and libraries.

Most of developers that are suddenly becoming more productive with docker do equivalent of a full install of an distribution that they run in production, call it a container and get the claps from management because "We managed to do it faster". Never mind that the surface for brokenness is now even higher than the surface for brokenness on a VM that the container is going to be ran on had the VM got the full install of of the distribution.

> VirtualBox feels like installing a regular computer. It takes a long time and is a lot of manual work. If you want to change something you login on the existing VM until you reach a point where you no longer remember all the changes you've made over the years. The machine is unclean.

That's because in this approach no one bothered to do equivalent of what one does when creating a docker image - write chef/puppet/salt/ansible baseline configuration so the new VM is nothing other than "base-VM + special config for this function".

[pjmlp]

Might be, on large organisations we just make out an order and get our VM.

I have more experience with VMware and Hyper-V, as type 1 hypervisors, VirtualBox always felt a bit underpowered.