i feel the same way, systemd also has some comprehensive sandboxing capabilities built-in.... i have my gripe with systemd too though. mostly with journald because it is slow, likely due to its on disk format, really could have used sqlite for this...
Re:Avoiding Complexity with Systemd
by christophilus on Sunday June 27, 2021 @08:49AM
(#27651169)
Same. I deployed a fleet of transcoding servers with the worker logic being a simple Go program. It was super simple with systemd.
Without docker also:
* have a production outage because your libc was updated and now your go apps (which are dynlinked against it by default) won’t start
* mess around with low level cgroup settings if you need to oversubscribe safely
* cry in a corner the second you also need some python libs installed to do some machine learning or opencv or whatever on the side
Without (Docker) containers it is:
- build Go binary and install it in production server
- write and enable the systemd unit file
With (Docker) containers it is:
- write Dockerfile
- install Docker in production server
- build Docker image and deploy container in production server
I get the appealing of containers when one production server is used for multiple applications (e.g., you have a Golang app and a redis cache), but the example above I think containers a bit of an overkill.