I understood that their point was not that Docker makes it slow, but that if it needs Docker to run, it probably needs a complicated environment which makes it slow.
I’m not using docker to deploy things because the things I’m deploying need a complicated environment, I’m using it because it’s an incredibly easy and consistent way to deploy things. It’s an immutable image that is highly convenient to distribute, update, and manage, which is pretty much the opposite experience of installing software on virtual machines.
Dropping a docker compose file into Portainer and I’m up and running with a new service in a few seconds. I’ve removed the overhead and spin up time of VMs, there’s no more running Chef/Ansible to do basic VM management for every single service I’m running, no more cookbooks/playbooks or manual SSHing to get software updated, no more minutes to hours of fixing configuration management that never seems to work the first time, no more bad in-place upgrade states, etc.
> it’s an incredibly easy and consistent way to deploy things
I keep seeing people saying this but my experience has always been otherwise.
Docker makes it really difficult to tinker with the internals of the container. They call it a development environment but you can’t easily edit a file and restart a service. There is bind mounts but the IO performance is terrible, necessitating use of volumes. Every base image is opinionated in how things are done, where things are stored even for the same software.
Since it’s so difficult to tinker with the internals most vendors will provide a web interface abstraction on top of their software (like NPM for nginx) and if you so much so veer off the happy path by 1 inch the abstraction can no longer track the state of things and breaks, necessitating a full reinstall or editing the config manually.
Of course this is in the context of self hosting. If you’re paid in your day job to maintain a tower of babel then by all means fire up all those dynos.
Why do I need to tinker with the internals of the container?
Even if I need to do that, the existence of a Docker image doesn’t stop me from making my own implementation as long as the application in question provides some kind of alternate distribution.
E.g., if there’s an RPM/DEB package, binary executable, JAR file, source code, etc, I can just make my own docker container with my own implementation and mess around with the internals as much as I want.
I don’t think of it as a “development environment” so much as a “deployment environment.” Yes, it is more difficult to “tinker” with a running container. And for services that are just supposed to run and not be tinkered with, that’s wonderful. I’ve deployed services that run on literally tens of thousands of containers and needing to tinker with the innards at this point is kind of a smell, like if you said “yeah, but I need to be able to add oil to my car while driving down the street because you never know when it’s all gonna suddenly leak out,”
