Ich bin eigentlich Softwareentwickler im Bereich Middleware und viel in Integrationsprojekten in Unix-lastigen Branchen unterwegs.
Dadurch bin ich reichlich in Kontakt mit solchen Problematiken unter diversen Betriebssystemen (Linux, Solaris, AIX, aber auch gelegentlich Windows) konfrontiert, die zur Umsetzung der Integrationsprobleme in den Griff gebracht werden müssen.
Unterschätze nicht die gigantische Menge an Individualsoftware, die genau solche Probleme hat, weil sie über Jahre und Jahrzehnte gewachsen ist, immer wieder angepasst wurde und entsprechende Abhängigkeiten zu externen Systemen hat. Ich war schon in vielen Unternehmen unterwegs, die mehr Individualsoftware in Betrieb haben als FreeBSD Ports hat.
Die Software mag oftmals alt, nicht besonders sexy und nach heutigen Maßstäben in vielen Fällen hoffnungslos veraltet sein.
Es ist aber auch die Software, mit der ein beträchtlicher Teil der Unternehmen ihr Geld verdient. Natürlich wäre es schön, diese Software in aller Ruhe auf der grünen Wiese neu zu entwickeln, aber dabei landet man sehr schnell bei astronomischen Kosten - für Software, die erstmal nicht mehr kann als der Vorgänger. Von Integrationstests, Migrationen und sonstigen Risiken ganz zu schweigen. Und dafür soll ein Unternehmen dann mal eben Millionen oder - je nach Größe - Milliarden ausgeben, mit ungewissem Ausgang?
Wärst du mal in namhaften Firmen unterwegs, würdest du erschrecken, wieviel hochkarätige Leute an vermeintlich schlechter Software arbeiten, die aber hier, jetzt und heute funktioniert und dafür sorgt, dass das jeweilige Unternehmen überhaupt existiert. Für die es keine Alternativen gibt, weil sie genau die Aufgaben löst, die dieses Unternehmen hat. Für die es keine vergleichbare Software am Markt gibt und deren Ablösung unbezahlbar ist. Wie soll hier die Alternative aussehen?
Es gibt reichlich Software, die historisch gewachsen ist und dadurch einfach Macken hat, die sich mit vertretbarem Aufwand nicht beheben, sondern nur in den Griff kriegen lassen.
Software, für die vielleicht ein Nachfolger in Sicht ist, dessen Produktionsreife sich aber noch Jahre (oder auch ein Jahrzehnt) hinziehen wird. In der Zwischenzeit muss die Software funktionieren.
Mit systemd kann man eben viele Konstellationen, die man vorher nur mit reichlich 3rd-Party-Software und Skripts in den Griff bekommen hat, rein deklarativ lösen - mit deutlich weniger Aufwand und höherer Zuverlässigkeit.
Es wird natürlich auch bei systemd das eine Prozent Spezialfälle geben, bei denen man zusätzlich ein Skript haben möchte - deren Integration hat systemd aber auch vorgesehen.
Das reicht eben für einen professionellen Betrieb oftmals nicht aus. Warum gibt es wohl so viele Projekte (launchd, upstart, openrc, systemd, smf, etc.), die sich genau solchen Problemen widmen?
Der klassische SysVinit/BSDinit reicht nur für triviale Fälle aus und wird heutigen Anforderungen nicht mehr gerecht.
Die Toleranz wächst mit der Distanz zum Problem.
Auch daran wurde in systemd gedacht, die Flexibilität hat man. Mittels ExecStopPost kannst du auch beliebige Kommandos (inklusive Auswertung des Exitcode) ausführen, falls die umfangreichen deklarativen Möglichkeiten nicht ausreichen.
Nein - man möchte unendliche Flexibilität haben, wenn man sie braucht. Ansonsten möchte man möglichst keinen Code schreiben. Jede Zeile Code muss geschrieben, verstanden, debugged und gewartet werden.
Aus all diesen Gründen und vielen mehr: Why systemd is winning the init wars and other things aren't.
