Long-Term-Support-Releases neu überdenken

Traditionell waren Long-Term-Support-Betriebssystem-Releases das Bollwerk von Enterprise-Bereitstellungen. Dies ist das Modell, das von IBM, Oracle, Microsoft, Suse und Red Hat verwendet wird, und es ist seit dem Beginn der Support-Angebote vor vielen Jahrzehnten das konventionelle Denken rund um Betriebssysteme gewesen.

In der Vergangenheit war es üblich, dass sowohl Server- als auch Desktop-Betriebssystem-Releases diesem Modell folgten, doch speziell im Linux-Bereich begannen wir zu beobachten, wie dies durcheinandergebracht wurde, als es weniger formalen Produkten freistand, mit schnelleren, nicht unterstützten oder schlicht unstrukturierten Releases zu experimentieren. Im primären Produktbereich boten openSuse, Fedora und Ubuntu allesamt Kurzzeit-Support-Angebote oder Schnellveröffentlichungsangebote an. Anstatt Release-Zyklen, die in Jahren gemessen wurden, und Support-Zyklen, die sich einem Jahrzehnt näherten, verkürzten sie die Release-Zyklen auf Monate und den Support auf nur Monate oder höchstens ein paar Jahre.

Im Desktop-Bereich war es oft sinnvoll, neue Funktionen und Anwendungen früher zu erhalten, anstatt sich in erster Linie auf Stabilität zu konzentrieren, wie es auf Servern üblich war, und es brachte den zusätzlichen Vorteil, dass neue Technologien oder Ansätze auf Produkten mit schnellerem Release-Zyklus getestet werden konnten, bevor sie in Long-Term-Support-Serverprodukte integriert wurden. Fedora beispielsweise ist ein Erprobungsfeld für Technologien, die – nachdem sie sich bewährt haben – ihren Weg in Red-Hat-Enterprise-Linux-Releases finden werden. Durch die Nutzung von Fedora erhalten Endanwender Funktionen früher, lernen RHEL-Technologien früher kennen, und Red Hat kann die Produkte in großem Maßstab testen, bevor sie auf kritischen Servern bereitgestellt werden.

Im Laufe der Zeit hat sich die Stabilität von Kurzzeit-Releases dramatisch verbessert, und zunehmend werden diese Systeme als brauchbare Optionen für Serversysteme angesehen. Diese Systeme erhalten neuere Verbesserungen, Funktionen und Upgrades früher, was oft als vorteilhaft betrachtet wird.

Ein wesentlicher Vorteil jedes Betriebssystems ist sein Support-Ökosystem, einschließlich der Pakete und Bibliotheken, die unterstützt und als Teil des Basisbetriebssystems bereitgestellt werden. Bei Long-Term-Releases erleben wir oft, dass kritische Pakete im Laufe der Lebensdauer des Release dramatisch altern, was Probleme mit Leistung, Kompatibilität und in extremen Fällen sogar Sicherheit verursachen kann. Dies zwingt Nutzer von Long-Term-Release-Betriebssystemen offensichtlich dazu, sich zwischen dem fortgesetzten Leben mit den Einschränkungen der älteren Komponenten und der eigenständigen Integration neuer Komponenten zu entscheiden, was oft den grundlegenden Wert des Long-Term-Release-Produkts zunichtemacht.

Da das Ziel eines Long-Term-Release Stabilität und Integrationstests sind, bedeutet das Ersetzen von Komponenten innerhalb des Produkts, um die Einschränkungen eines LTS zu “umgehen”, dass diese Komponenten nicht auf eine LTS-Weise behandelt werden und dass Integrationstests vonseiten des Herstellers höchstwahrscheinlich nicht mehr stattfinden – oder, falls doch, nicht in gleichem Umfang. Im Ergebnis geschieht Folgendes: Dies wird zu einem selbst zusammengebauten Kurzzeit-Release-Produkt, jedoch mit veralteten Kernkomponenten und weniger Aufsicht.

In Wirklichkeit ist dies in den meisten Belangen schlechter, als direkt zu einem Kurzzeit-Release-Produkt überzugehen. Die Verwendung eines Kurzzeit- oder Schnellveröffentlichungsprodukts erlaubt es dem Hersteller, die vorausgesetzten Tests und die Integration aufrechtzuerhalten, nur eben mit einem schnelleren Release- und Support-Zyklus, sodass der allgemeine Wert des Long-Term-Release-Konzepts erhalten bleibt und alle Komponenten des Betriebssystems aktualisiert werden, nicht nur einige wenige. Dies ermöglicht mehr Standardisierung, branchenweite Tests sowie geteiltes Wissen und Integration als bei einem partiellen LTS-Modell.

Vielleicht ist die Zeit gekommen, den Wert von Long-Term-Support für Betriebssysteme neu zu überdenken. Zu lange, so scheint es, wurde der Wert dieses Ansatzes schlicht vorausgesetzt und befolgt, und gewiss hatte und hat er seine Vorzüge; doch die Betriebssystemwelt hat sich verändert, seit dieser Ansatz erstmals eingeführt wurde. Der Bedarf an Updates ist gestiegen, während sich die Änderungsraten von Dingen wie Kerneln und Bibliotheken dramatisch verlangsamt haben. Leistungsfähigere Server haben die Kompatibilität weiter nach oben im Stack verlagert, und anstatt dass Software für ein Betriebssystem geschrieben wird, wird sie oft für eine bestimmte Version einer Sprache oder Laufzeitumgebung oder einer anderen Abstraktionsschicht geschrieben.

Kürzere Release-Zyklen bedeuten, dass Systeme von oben bis unten häufiger Funktionen erhalten. Updates zwischen “großen” Releases sind kleiner und weniger einschneidend. Änderungen durch Updates erfolgen schrittweiser und bieten eine organischere Lern- und Anpassungskurve. Und am wichtigsten: Die Notwendigkeit, sorgfältig getestete und integrierte Systemkomponenten durch von Drittanbietern bereitgestellte Versionen zu ersetzen, wird praktisch unbekannt.

Stabilität bleibt für Softwarehersteller ein Wert von Long-Term-Releases und wird dafür sorgen, dass noch lange Zeit ein Bedarf an der Nutzung von Long-Term-Releases bestehen wird. Doch für den Systemadministrator scheint der Wert dieses Ansatzes abzunehmen, und ich persönlich habe das Gefühl, dass er in den letzten Jahren einen Wendepunkt erreicht hat. Früher schien es erwartet und normal, zwei oder drei Jahre auf die Aktualisierung von Paketen zu warten, doch heute fühlt sich das unnötig umständlich an. Es scheint zunehmend üblich zu sein, dass höhere Komponenten mit der Anforderung neuerer zugrunde liegender Komponenten erstellt werden; eine Erwartung, dass Betriebssysteme entweder aktueller sein werden oder dass Teile des Betriebssystems getrennt vom Rest aktualisiert werden.

Eine starke Abhängigkeit von Containerisierungstechnologien könnte diesen Trend in mancher Hinsicht umkehren, jedoch auf eine Weise, die den Wert von Long-Term-Releases gleichzeitig stets verringert. Containerisierung reduziert den Bedarf an umfangreichen Fähigkeiten im Basisbetriebssystem, was es einfacher und effektiver macht, häufiger zu aktualisieren, um Kernel-, Dateisystem-, Treiber- und Container-Unterstützung zu verbessern, während Bibliotheken und andere Abhängigkeiten in den Containern verbleiben, sodass Anwendungen, die Long-Term-Support-Abhängigkeiten benötigen, auf diese Weise bedient werden können und Anwendungen, die von neueren Komponenten profitieren können, auf jene Weise adressiert werden können.

Natürlich hat auch die Virtualisierung eine Rolle dabei gespielt, den Wert von Long-Term-Support-Modellen zu verringern, indem sie die schnelle Wiederherstellung und Duplizierung von Systemen trivial gemacht hat. Die Stabilität, für die wir Long-Term-Support-Releases benötigt haben, wird teilweise durch die Virtualisierungsschicht adressiert; die Hardware-Abstraktion verbessert die Treiberstabilität in sehr wichtiger Weise. In gleicher Weise reduzieren auch DevOps-artige Support-Modelle den Bedarf an Long-Term-Support und machen Server-Ökosysteme agiler und flexibler. Trends in den Paradigmen der Systemadministration tendieren dazu, modernere Betriebssysteme zu bevorzugen.

Die Zeit wird zeigen, ob sich die Trends in der eingeschlagenen Richtung fortsetzen. Für mich war dieses vergangene Jahr ein augenöffnendes, in dem ich meine eigenen Workloads von einem Jahrzehnt standhafter Unterstützung für sehr langfristige Support-Produkte auf Schnellveröffentlichungsprodukte umgestellt habe, und ich muss sagen, ich bin mit der Veränderung sehr zufrieden.