Disclaimer

systemd is a contentious issue in the Linux world, you don't need
to go far to read arguments for or against systemd. This article is not
about whether it's good or bad, but in the interests of full disclosiure,
I feel it is important to declare that I am a systemd contributor,
as at the time of writing I have 1 line of code in systemd. Hence I am
biased, as I wouldn't waste my time on something I didn't think was
worthwhile.

What's with the title?

One of the lead developers wrote an article series called systemd for
administrators. The goal of which is to explain how useful systemd
is for system administrators, but the systemd project has widened in
scope since then, and the full scope of what systemd provides is
not common knowledge.

What is systemd

systemd is both the name of a project to provide the boring bits
needed to have a working Linux system, and the name of the init process
systemd(1), which is the first process run in a Linux system, and
is responsible for starting all others.

systemd as PID 1

systemd.service(5) files are a DSL for all the tricky start-up
configurations that were previously encoded in fragile init scripts,
and generalises the on-demand service start-up in inetd(8)
into socket activation.

One of the trickiest parts of start-up is ensuring correct dependency
ordering, so services that depend on other services are started
after they are ready.

To handle this, you can set Before= in the service file you depend
on, or After= in your unit file, and ensure that your services
set the right Type= section to notify when the service is ready.

For one-off commands that you'd still like to benefit from
systemd's service management, you can use systemd-run(1).

Conclusion

I emphasised the difference between systemd the project and
systemd(1) the daemon that inhabits PID 1, because there are other
services provided by the former than just the latter, which will be
descibed in future articles.