Why bother with containers at all at that scale then?
We keep on using plain old VMs, while watching everyone rush into containers fashion.
We keep on using plain old VMs, while watching everyone rush into containers fashion.
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.
I have more experience with VMware and Hyper-V, as type 1 hypervisors, VirtualBox always felt a bit underpowered.
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.
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
> 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.
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".
It's not like containers are new technology, even on Linux; we were using OpenVZ a decade ago. Now they're just integrated into the mainline.
And we can use native containers if we actually need them, so I see such tooling more as yet another consulting wave.
Using docker images means that we can take the thing that developer A built and that "runs on their machine" (without necessarily having that developer on hand) and have developer B easily launch it on their machine without having any dependency or isolation or reproducibility issues, and after making some trivial changes put it in a new, fresh production server without having to ask the original dev how it was/should be configured.