Long Term Support-releases heroverwegen

Van oudsher zijn Long Term Support-releases van besturingssystemen het bolwerk geweest van enterprise-implementaties. Dit is het model dat door IBM, Oracle, Microsoft, Suse en Red Hat wordt gebruikt en het is sinds het ontstaan van ondersteuningsaanbiedingen vele decennia geleden de conventionele denkwijze rond besturingssystemen geweest.

Het is in het verleden gebruikelijk geweest dat zowel server- als desktopbesturingssysteemreleases dit model volgden, maar specifiek in de Linux-wereld begonnen we te zien dat hier verandering in kwam, waar minder formele producten de vrijheid hadden om te experimenteren met snellere, niet-ondersteunde of simpelweg ongestructureerde releases. In de belangrijkste productruimte boden openSuse, Fedora en Ubuntu allemaal ondersteuningsaanbiedingen met een korte termijn of releaseaanbiedingen met een snel tempo. In plaats van releasecycli die in jaren werden gemeten en ondersteuningscycli die richting een decennium gingen, verkortten zij de releasecycli tot maanden en de ondersteuning tot slechts maanden of hooguit enkele jaren.

In de desktopwereld was het vaak zinvol om nieuwe functies en applicaties sneller te krijgen, in plaats van zich primair te richten op stabiliteit zoals gebruikelijk was op servers, en dit bracht het bijkomende voordeel met zich mee dat nieuwe technologieën of benaderingen op producten met een snellere releasecyclus konden worden getest voordat ze werden geïntegreerd in serverproducten met langetermijnondersteuning. Fedora is bijvoorbeeld een proeftuin voor technologieën die, nadat ze zich hebben bewezen, hun weg zullen vinden naar releases van Red Hat Enterprise Linux. Door Fedora te gebruiken krijgen eindgebruikers functies eerder, leren ze eerder over RHEL-technologieën en kan Red Hat de producten op grote schaal testen voordat ze op kritieke servers worden uitgerold.

In de loop van de tijd is de stabiliteit van kortetermijnreleases dramatisch verbeterd en deze systemen worden steeds vaker gezien als levensvatbare opties voor serversystemen. Deze systemen krijgen nieuwere verbeteringen, functies en upgrades eerder, wat vaak als voordelig wordt beschouwd.

Een belangrijk voordeel van elk besturingssysteem is het ondersteuningsecosysteem, met inbegrip van de pakketten en bibliotheken die worden ondersteund en als onderdeel van het basisbesturingssysteem worden geleverd. Bij langetermijnreleases zien we vaak dat kritieke pakketten gedurende de levensduur van de release dramatisch verouderen, wat problemen kan veroorzaken met prestaties, compatibiliteit en in extreme gevallen zelfs beveiliging. Dit dwingt gebruikers van besturingssystemen met langetermijnreleases uiteraard om te kiezen tussen het blijven leven met de beperkingen van de oudere componenten of het zelf integreren van nieuwe componenten, wat vaak de fundamentele waarde van het langetermijnreleaseproduct tenietdoet.

Omdat het doel van een langetermijnrelease is om stabiliteit en integratietests te bieden, betekent het vervangen van componenten binnen het product om de beperkingen van een LTS te “omzeilen”, dat die componenten niet op een LTS-manier worden behandeld en dat de integratietests vanuit de leverancier hoogstwaarschijnlijk niet langer plaatsvinden, of als ze dat wel doen, niet in dezelfde mate. In feite gebeurt het volgende: dit wordt een zelfgebouwd kortetermijnreleaseproduct, maar met verouderde kerncomponenten en minder toezicht.

In werkelijkheid is dit in de meeste opzichten erger dan rechtstreeks overstappen op een kortetermijnreleaseproduct. Het gebruik van een product met een korte termijn of een snel tempo stelt de leverancier in staat de veronderstelde tests en integratie te handhaven, alleen met een snellere release- en ondersteuningscyclus, zodat de algemene waarde van het langetermijnreleaseconcept behouden blijft en bovendien alle componenten van het besturingssysteem worden bijgewerkt, in plaats van slechts enkele. Dit maakt meer standaardisatie, branchebrede tests en gedeelde kennis en integratie mogelijk dan bij een gedeeltelijk LTS-model.

Misschien is de tijd gekomen om de waarde van langetermijnondersteuning voor besturingssystemen te heroverwegen. Te lang, zo lijkt het, werd de waarde van deze benadering simpelweg verondersteld en gevolgd, en zeker had en heeft zij haar verdiensten; maar de wereld van de besturingssystemen is veranderd sinds deze benadering voor het eerst werd geïntroduceerd. De behoefte aan updates is toegenomen, terwijl het veranderingstempo van zaken als kernels en bibliotheken dramatisch is afgenomen. Krachtigere servers hebben de compatibiliteit hoger in de stack geplaatst en in plaats van dat software wordt geschreven voor een besturingssysteem, wordt deze vaak geschreven voor een specifieke versie van een taal of runtime of een andere abstractielaag.

Kortere releasecycli betekenen dat systemen vaker functies krijgen, van boven tot onder. Updates tussen “grote” releases zijn kleiner en hebben minder impact. Veranderingen door updates zijn meer incrementeel, wat voor een meer organische leer- en aanpassingscurve zorgt. En het allerbelangrijkste: de noodzaak om zorgvuldig geteste en geïntegreerde systeemcomponenten te vervangen door door derden geleverde versies wordt in feite ongehoord.

Stabiliteit blijft voor softwareleveranciers een waarde van langetermijnreleases en zal ervoor zorgen dat er nog lange tijd behoefte zal zijn aan het gebruik van langetermijnreleases. Maar voor de systeembeheerder lijkt de waarde van deze benadering af te nemen en, naar mijn persoonlijke gevoel, in de afgelopen jaren een omslagpunt te hebben bereikt. Vroeger leek het verwacht en normaal om twee of drie jaar te wachten tot pakketten werden bijgewerkt, maar tegenwoordig voelt dit onnodig omslachtig. Het lijkt steeds gebruikelijker dat componenten op een hoger niveau worden gebouwd met een vereiste van nieuwere onderliggende componenten; een verwachting dat besturingssystemen ofwel actueler zullen zijn ofwel dat delen van het besturingssysteem los van de rest zullen worden bijgewerkt.

Een sterke afhankelijkheid van containerisatietechnologieën kan deze trend in sommige opzichten omkeren, maar op manieren die tegelijkertijd altijd de waarde van langetermijnreleases verminderen. Containerisatie vermindert de behoefte aan uitgebreide mogelijkheden in het basisbesturingssysteem, waardoor het gemakkelijker en effectiever wordt om vaker bij te werken voor verbeterde ondersteuning van kernel, bestandssysteem, drivers en containers, terwijl bibliotheken en andere afhankelijkheden in de containers worden gelaten, zodat applicaties die langetermijnondersteuningsafhankelijkheden nodig hebben op die manier kunnen worden bediend en applicaties die baat hebben bij nieuwere componenten op die manier kunnen worden geadresseerd.

Uiteraard heeft virtualisatie een rol gespeeld in het verminderen van de waarde van langetermijnondersteuningsmodellen door snel herstel en duplicatie van systemen triviaal te maken. Stabiliteit waarvoor we langetermijnondersteuningsreleases nodig hadden, wordt gedeeltelijk aangepakt door de virtualisatielaag; hardwareabstractie verbetert de driverstabiliteit op zeer belangrijke manieren. In dezelfde geest verminderen ondersteuningsmodellen in devops-stijl ook de behoefte aan langetermijnondersteuning en maken zij serverecosystemen wendbaarder en flexibeler. Trends in de paradigma's van systeembeheer neigen ertoe modernere besturingssystemen te bevoordelen.

De tijd zal leren of de trends zich blijven ontwikkelen in de richting waarin ze gaan. Wat mijzelf betreft, is het afgelopen jaar er een geweest dat mij de ogen heeft geopend en waarin ik mijn eigen workloads heb verplaatst van een decennium van onwrikbare steun aan zeer langlopende langetermijnondersteuningsproducten naar producten met een snel tempo, en ik moet zeggen dat ik zeer tevreden ben met de verandering.