"in the end can you really say it’s simpler than what we’ve got for free built in to golang?"
In this cherry picked example with a golang binary, sure. At my job, docker has saved us probably hundreds of man-hours. We don't have to worry about complications like systemd, because I can tell a container exactly how to run. Etcetera.
You can copy the golang binary into an alpine container and instead of having to maintain a server, you now have ephemeral containers that can be destroyed, spun up, scaled...
There is a difference of keeping things minimal and refusing to use industry tools. There is nothing scary about docker or even kubernetes. But they do take time to learn and understand, and yes, the benefits of containerization outweigh using bespoke server setups.
edit: s/systemd init scripts/systemd. We use s6-overlay instead of systemd to manage processes in containers.
> We don't have to worry about complications like systemd init scripts
Setting up a systemd unit file (it's not even a script) doesn't even come close to the complexity of wrapping, maintaining, and potentially orchestrating software within containers.
"Setting up a systemd unit file (it's not even a script) doesn't even come close to the complexity of wrapping, maintaining, and potentially orchestrating software within containers."
I find that the complexity of managing containers is overstated. It does have costs, but the benefits of docker and containerization in general outweigh those costs. Kubernetes is significantly more complicated and is not always a good choice depending on the use case.
"like systemd?"
I find that systemd tries to do far too much for our needs, namely for just managing services in a container. Our images have their services manged by s6-overlay [0], but there are multiple init systems one can use. I do not see the benefit of systemd over i.e. s6 or runit, but that is tangential to this discussion.
Alpine is a common example, but you could use scratch and only copy in exactly what you need. Both of these are extremely lightweight.
Having a full OS is helpful for troubleshooting issues, for starters. If one of the nodes is having an issue, it's helpful to be able to log in and examine the state of things.
One pain point of docker/k8s is figuring out networking, and having a container with dns-utils installed is quite handy.
In this cherry picked example with a golang binary, sure. At my job, docker has saved us probably hundreds of man-hours. We don't have to worry about complications like systemd, because I can tell a container exactly how to run. Etcetera.
You can copy the golang binary into an alpine container and instead of having to maintain a server, you now have ephemeral containers that can be destroyed, spun up, scaled...
There is a difference of keeping things minimal and refusing to use industry tools. There is nothing scary about docker or even kubernetes. But they do take time to learn and understand, and yes, the benefits of containerization outweigh using bespoke server setups.
edit: s/systemd init scripts/systemd. We use s6-overlay instead of systemd to manage processes in containers.