That alternative tools have their own learning curves (which generally compare unfavorably to Docker's, which is exceptionally gentle) and that you have to make decisions about how to fit them together is a very valid and relevant point.
But it struck me that all of your 'just's really didn't seem like a big deal to me.
I set up a Nix installation on a separate BTRFS subvolume on a Debian-based system that I got as a multimedia PC for my uncle as a gift a few weeks ago. I also had to replace the default initial ramdisk image generator with another one to get the subvolume mounted early enough for systemd to automatically launch services that lived on the Nix subvolume on first boot.
It really didn't seem like that big of a deal for me. Each piece of it was just a small step away from a background of Linux administration knowledge I built up as a teenager when I used to distrohop and play around for fun.
All of this is to say that a difference in background is likely behind this gap of perceptions.
Someone with a background in ops is likely invested in traditions that have different strengths and weaknesses than the approach that Docker offers. For people in positions like that, approaches that are perhaps more involved but preserve more of the virtues of those traditional toolsets may seem like a smaller leap than the one to containers.
You've used the word 'just' here to highlight what to you seem unreasonable levels of difficulty or required background knowledge, which makes sense. But couldn't I just as well say that Docker advocates would have us 'just' abandon the very notion of shared libraries, 'just' try to get by without actually knowing how to build or verify our dependency chains, 'just' grab binaries from strangers on the net, 'just' download gigabytes of binary data to perform builds, 'just' virtualize Linux on macOS in order to use software that runs natively on it, etc.?
At the same time, for things like microservices development, Docker also makes some serious demands on time and knowledge, e.g., 'just' refactor all of your legacy services so they can be safely started in any order or 'just' learn Kubernetes so that your can initialize services in order of dependencies.
> It really didn't seem like that big of a deal for me. Each piece of it was just a small step away from a background of Linux administration knowledge I built up as a teenager when I used to distrohop and play around for fun.
> You've used the word 'just' here to highlight what to you seem unreasonable levels of difficulty or required background knowledge, which makes sense.
I mean, it's great that it's easy for you. And it would be great if everyone at my office conveniently had this same kind of the prerequisite knowledge. But the reality is, most don't. And the worse reality is, most don't enjoy having to learn extra tools on top of the rest of the things they need to know for their job.
Docker is one extra thing to learn. It is easier to learn for the majority of developers that don't have, or don't care to have, any Linux admin background. It is a cross-platform solution and has good adoption in the industry, which means I can probably use Docker at one company, and go to another company and use the same Docker.
> But couldn't I just as well say that Docker advocates would have us 'just' abandon the very notion of shared libraries
Why should I want shared libraries though, given I have containers? I can get an update out by rebuilding an image and rolling the container. Immutable infrastructure is a good thing.
> 'just' try to get by without actually knowing how to build or verify our dependency chains, 'just' grab binaries from strangers on the net, 'just' download gigabytes of binary data to perform builds,
Gigabytes is a gross exaggeration for Docker images, but this applies to almost any package manager. Why is a package in a Debian repository (or similar) any better from a trust perspective than an image in Docker repository? Neither of the package/image maintainers are usually authors of the software.
If you need/want to, you can run your own docker registry, where you only upload self-built images, which completely removes all your trust concerns. You could probably even build docker images with nix.
But it struck me that all of your 'just's really didn't seem like a big deal to me.
I set up a Nix installation on a separate BTRFS subvolume on a Debian-based system that I got as a multimedia PC for my uncle as a gift a few weeks ago. I also had to replace the default initial ramdisk image generator with another one to get the subvolume mounted early enough for systemd to automatically launch services that lived on the Nix subvolume on first boot.
It really didn't seem like that big of a deal for me. Each piece of it was just a small step away from a background of Linux administration knowledge I built up as a teenager when I used to distrohop and play around for fun.
All of this is to say that a difference in background is likely behind this gap of perceptions.
Someone with a background in ops is likely invested in traditions that have different strengths and weaknesses than the approach that Docker offers. For people in positions like that, approaches that are perhaps more involved but preserve more of the virtues of those traditional toolsets may seem like a smaller leap than the one to containers.
You've used the word 'just' here to highlight what to you seem unreasonable levels of difficulty or required background knowledge, which makes sense. But couldn't I just as well say that Docker advocates would have us 'just' abandon the very notion of shared libraries, 'just' try to get by without actually knowing how to build or verify our dependency chains, 'just' grab binaries from strangers on the net, 'just' download gigabytes of binary data to perform builds, 'just' virtualize Linux on macOS in order to use software that runs natively on it, etc.?
At the same time, for things like microservices development, Docker also makes some serious demands on time and knowledge, e.g., 'just' refactor all of your legacy services so they can be safely started in any order or 'just' learn Kubernetes so that your can initialize services in order of dependencies.