From anti-systemd to pro-systemd in the shortest time

Yes, and because Netflix doesn't do it it must be a stupid idea in general.

For one, even the big cloud services will prefer not having to rebuild a VM if restarting a process will also work (better than it does based on SysV init). For example, even a big cloud service will eventually want to figure out why a service keeps crashing, and obliterating the evidence by rebuilding the VM in question is not exactly helpful in that case.

For another, not every outfit in the world is a big cloud service and has the sort of tooling that lets them rebuild a VM automatically at the snip of a finger. These others often don't have the sort of tooling that will reliably track a service started by SysV init for them, either, and therefore stand to gain from a system that will do it for them out of the box. If anything, the big cloud services tend to have people on staff to sort out things like transparent service restart for them even if that means coming up with a way of rebuilding VMs at short notice, because this is basically how big cloud services make their money, while the IT people at other outfits are often forced to spend their time on other more immediately important issues. We can argue that everybody should think and work like a big cloud service (most of the required pieces are conveniently available, after all) but this is not usually how things pan out in actual practice.

Finally, service restart vs. VM rebuilding notwithstanding, even big cloud-based outfits seem to like systemd. Spotify, for example, has officially come out in support of making systemd the default init system on Debian.

Oh come on now, what he said is true, big "cloud service" shops don't do troubleshooting by hand when there is a failure, they just kill the VM and rebuild it from scratch through their configuration management system.

This is chicken and egg problem: since it was impossible for a long time to reliably separate services without VM these “big "cloud service" shops” went with VM. But guys who though that this approach is just stupid developed another solution. This solution (today we know it under name cgroups) is used today by systemd to manage daemons and services.

Let me repeat once more: underlaying functionality which systemd uses today to manage processes was created specifically for the needs of “large cloud services”. Now, it's entirely possible that some use-cases are covered poorly by this approach (hey guys from Google developed it for Google and different coulds are… well, different) but then it just means that it must be fixed.