I find kubernetes - systemd overlap angle as a very valid point. When I first started to learn kubernetes more often than not I was thinking 'hey, we can do that with systemd as well!'
https://en.wikipedia.org/wiki/Beowulf_cluster
https://en.wikipedia.org/wiki/MOSIX
That is the thing with repeating history.
...and they also create lock-in wrt k8s.
Actually said company makes packaging tools and Linux packages are fairly simple so we started with the ability to make server packages that use systemd.
That support is still there and makes it fairly easy to build a signed apt repository from build system outputs (e.g. jars, native binaries), or even by re-packaging an existing server download [1]. What you get out is debs that start up the service on install, ensure it starts automatically at boot, restarts it across upgrades and shuts it down cleanly if the machine shuts down. Such packages can be built from any machine including Windows and macOS. The nice thing about doing packaging this way is you can specify dependencies (both install and service startup) on things like postgresql, and you get a template nginx/apache2 reverse proxy config as well. Unfortunately there doesn't seem to be a way to make those templates 100% usable out of the box due to limits in their config languages, but it's still nice to have.
There's also pre-canned config snippets for sandboxing, setting up cron jobs and other useful systemd features [2]. We package and run all our servers this way. One big rented colo machine is sufficient right now. If there was a need for clustering we'd just point the machines at the same apt repo and use some shell scripting or Ansible, I think.
There's lots of tools for making Docker containers out there already, but I never really clicked with Docker for various reasons. Conveyor is mostly focused on desktop apps but perhaps there's more demand for easily making systemd using packages than I thought. The server side support is there and we dogfood it, but isn't really advertised and it lacks a tutorial.
If someone is building say an embedded system that has to run different services (say a NAS, or a router), it's pretty compelling alternative to a bit more heavy weight containers like docker.
Many sandboxing features require a relatively modern systemd and will do nothing on older distros (we run RHEL9).
Also like the "negative" commented out config, that's something I often do myself with footguns that feel "obvious".
That was still early days for systemd-nspawn, folks would be using docker containers under systemd services. And that caused heaps of other problems because docker was aspiring to do PID 1's jobs as well.
But does systemd do these things in a user-friendly way? Or at least as friendly as Kubernetes?
Unfortunately, no.
Don't underestimate the importance of UX.
No one should ever confuse kubernetes for user-friendly.
Kubernetes is user-friendly, specially when compared to each and any of its alternatives.
And moreso when compared with systemd.
We live in a day and age where it's possible to get a whole web app up and running in a Kubernetes cluster from a fresh Ubuntu install with a single snap installation and a kubectl apply -k <kustomize dir>. How long would it take to get systemd to containerize a single app?
Anyway, you're right in the general case, but specific cases really depend on how complicated your app actually is. If we're allowed to introduce extra tools then gosh darn it I'm going to promote Conveyor again because in that case it gets easier to use systemd too. Here's what a server config looks like:
https://gist.github.com/mikehearn/5485a7343d9fe838d33d0b0281...
All of ~25 lines, some of which is just optional demo stuff. To use it you'd compile your app (a JVM app in this case), run "conveyor make debian-package", upload the resulting package and install it with "apt install ./whatever.deb". Or alternatively upload it to a static file server (s3 bucket or whatever) and then run "apt-get update && apt-get upgrade" on each host. The server will start/restart automatically. It's not containerized in the Docker sense but it does run in a lightweight sandbox using the DynamicUser feature, and you can lock it down further if you want by setting the right systemd keys.
Now, you're going to say that Kubernetes does a lot more for you, that it can deploy many kinds of apps simultaneously, configure networking, let replicas find each other etc and so it's easier to use for 'real' apps. Granted, all true. The above workflow isn't optimized, does less and would need more work to be competitive. Also the resulting packages assume there's an apt repository somewhere, which takes a bit of work to set up (this isn't strictly needed in the server case and we'll fix it at some point).
Still, whilst maybe it's better for everyone to just learn Kubernetes at some point, but a lot of us have learned Linux/UNIX in the past and have needs that can be met cheaply with that toolset.