Gentænkning af Long Term Support-udgivelser

Traditionelt har Long Term Support-operativsystemudgivelser været rygraden i enterprise-implementeringer. Dette er den model, der bruges af IBM, Oracle, Microsoft, Suse og Red Hat, og har været den konventionelle tankegang omkring operativsystemer siden begyndelsen af supporttilbud for mange årtier siden.

Det har tidligere været almindeligt for både servere og desktop-operativsystemudgivelser at følge denne model, men specifikt i Linux-verdenen begyndte vi at se dette blive rystet op, hvor mindre formelle produkter var frie til at eksperimentere med hurtigere, ustøttede eller simpelthen ustrukturerede udgivelser. I det primære produktrum tilbød openSuse, Fedora og Ubuntu kortsigtede supporttilbud eller hurtige udgivelsestilbud. I stedet for udgivelsescyklusser målt i år og supportcyklusser på næsten et årti, kortede de udgivelsescyklusser ned til måneder og support til blot måneder eller et par år på det meste.

I desktop-verdenen gav det ofte mening at få nye funktioner og applikationer hurtigere i stedet for primært at fokusere på stabilitet, som var almindeligt på servere – og det medførte den ekstra fordel, at nye teknologier eller tilgange kunne testes på hurtigere udgivelsescyklusprodukter, inden de blev integreret i Long Term Support-serverprodukter. Fedora er for eksempel en testbane for teknologier, der efter at have bevist sig selv vil finde vej ind i Red Hat Enterprise Linux-udgivelser. Ved at bruge Fedora får slutbrugere funktioner hurtigere, lærer om RHEL-teknologier tidligere, og Red Hat får testet produkterne i stor skala, inden de implementeres på kritiske servere.

Over tid er stabiliteten af kortsigtede udgivelser forbedret dramatisk, og disse systemer ses i stigende grad som levedygtige muligheder for serversystemer. Disse systemer får nyere forbedringer, funktioner og opgraderinger hurtigere, hvilket ofte ses som en fordel.

En stor fordel ved ethvert operativsystem er deres supportøkosystem, herunder de pakker og biblioteker, der understøttes og leveres som en del af basisoperativsystemet. Med langsigtede udgivelser ser vi ofte kritiske pakker ældes dramatisk i løbet af udgivelsens levetid, hvilket kan forårsage problemer med ydeevne, kompatibilitet og endda sikkerhed i ekstreme tilfælde. Dette tvinger naturligvis brugere af Long Term Release-operativsystemer til at vælge mellem fortsat at leve med begrænsningerne i de ældre komponenter eller at integrere nye komponenter selv, hvilket ofte underminerer den grundlæggende værdi af Long Term Release-produktet.

Fordi målet med en langsigtet udgivelse er at have stabilitet og integrationstestning, betyder det at erstatte komponenter i produktet for at “arbejde udenom” begrænsningerne i en LTS, at disse komponenter ikke behandles på en LTS-måde, og at integrationstestning fra leverandøren sandsynligvis ikke længere sker – eller hvis det gør, ikke i samme grad. I virkeligheden bliver dette et selvbygget kortvarigt udgivelsesprodukt, men med ældre kernekomponenter og mindre tilsyn.

I realiteten er dette i de fleste henseender værre end at gå direkte til et kortvarigt udgivelsesprodukt. At bruge et kortvarigt eller hurtigt udgivelsesprodukt giver leverandøren mulighed for at opretholde den antagne testning og integration, blot med en hurtigere udgivelses- og supportcyklus, så den generelle værdi af Long Term Release-konceptet opretholdes og med alle komponenter i operativsystemet – snarere end blot et fåtal – der opdateres. Dette giver mulighed for mere standardisering, branchetestning og delt viden og integration end med en delvis LTS-model.

Måske er det tid til at gentænke værdien af Long Term Support for operativsystemer. Det synes, at værdien af denne tilgang i for lang tid blot blev antaget og fulgt, og den havde og har bestemt fortjenester; men operativsystemverdenen har ændret sig siden denne tilgang først blev introduceret. Behovet for opdateringer er steget, mens ændringsraterne for ting som kerner og biblioteker er bremset dramatisk. Mere kraftfulde servere har rykket kompatibilitet højere op i stakken, og i stedet for at software skrives til et OS, skrives det ofte til en specifik version af et sprog eller en runtime eller et andet abstraktionslag.

Kortere udgivelsescyklusser betyder, at systemer får funktioner, fra top til bund, oftere. Opdateringer mellem “større” udgivelser er mindre og mindre indgribende. Ændringer fra opdateringer er mere inkrementelle, hvilket giver en mere organisk lærings- og tilpasningskurve. Og vigtigst af alt bliver behovet for at erstatte systemkomponenter, der er omhyggeligt testet og integreret, med tredjeparts leverede versioner i praksis uhørt.

Stabilitet for softwareleverandører forbliver en værdi for langsigtede udgivelser og vil medføre, at der fortsat vil være behov for brugen af Long Term Releases i lang tid fremover. Men for systemadministratoren synes værdien af denne tilgang at falde, og jeg føler personligt, at den har fundet et inflektionspunkt i de seneste år. Det plejede at synes forventet og normalt at vente to eller tre år på, at pakker blev opdateret, men i dag føles dette unødigt besværligt. Det synes stadig mere almindeligt, at komponenter på højere niveau er bygget med et krav om nyere underliggende komponenter – en forventning om, at operativsystemer enten er mere aktuelle, eller at dele af operativsystemet opdateres separat fra resten.

En stærk afhængighed af containeriseringsteknologier kan i visse henseender vende denne tendens, men på måder, der altid reducerer værdien af Long Term Releases på samme tid. Containerisering reducerer behovet for omfattende kapaciteter i basisoperativsystemet, hvilket gør det lettere og mere effektivt at opdatere hyppigere for forbedret kerne-, filsystem-, driver- og containerunderstøttelse, mens biblioteker og andre afhængigheder efterlades i containerne – hvilket giver applikationer, der har brug for Long Term Support-afhængigheder, mulighed for at blive imødekommet på den måde, og applikationer, der kan drage fordel af nyere komponenter, adresseres på den måde.

Virtualisering har naturligvis spillet en rolle i at reducere værdien af Long Term Support-modeller ved at gøre hurtig gendannelse og duplikering af systemer trivielt. Stabilitet, som vi har haft brug for Long Term Support-udgivelser til at adressere, adresseres delvist af virtualiseringslaget; hardwareabstraktion forbedrer driverstabilitet på meget vigtige måder. I samme ånd reducerer devops-style supportmodeller også behovet for Long Term Support og gør serverøkosystemer mere agile og fleksible. Tendenser i systemadministrationsparadigmer er ved at favorisere mere moderne operativsystemer.

Tiden vil vise, om tendenserne fortsætter i den retning, de er på vej. For mig selv har det seneste år været et øjenåbnende, der har set mig flytte mine egne arbejdsbelastninger fra et årti med stærk støtte til meget langsigtede supportprodukter til hurtige udgivelsesprodukter – og jeg må sige, at jeg er meget glad for forandringen.