systemd is great. I used it successfully for operations on many projects that I ran. It provides the standardized way to reliably run and manage services on a single machine. I also agree with opponents that shell was the de facto standard way to orchestrate things, allowing you to go from dev to prod without significant changes. I was a fan of runit as a process manager before systemd took over the space.

That said there is a problem when you want to run things on multiple machines. What then? Unix and systemd were not designed as an OS for machine clusters, even though it won't be hard to imagine the concepts to be stretched even to this realm.

The docker/kubernetes crowd has been targeting the multi-machine OS scene much sooner and better, even though the solution of let's pack all dependencies, the entire machine and then some to a fat package and then have it run by a scheduler complex as f seems not like the ultimate future of the space.

I took a look at Nomad as a replacement for Kubernetes, which is much much simpler and you can get up and running with a single binary within 2 hours using this tutorial [0]. Nomad supports not only docker as a backend, but you can run raw_exec backend as well - that is any binary, such as shell script, that you wish to run without packaging the entire world with it. Now imagine if only you could schedule to run systemd units using Nomad. You'd scale from a single machine OS to cluster OS just like that.

I predict that Kubernetes will NOT be the ultimate answer as many are hoping for, betting their careers on it. It is too complex and not supporting other than docker runtimes makes it much inferior product than Nomad. Simple solutions usually win ultimately, so Nomad or systemd extended for multi machine services or even just vanilla linux process management extended to cluster level seem like much saner approaches.

[0] https://medium.com/hashicorp-engineering/hashicorp-nomad-fro...