Att ompröva utgåvor med långtidsstöd

Traditionellt har operativsystemsutgåvor med långtidsstöd varit ryggraden i företagsdriftsättningar. Detta är modellen som används av IBM, Oracle, Microsoft, Suse och Red Hat och har varit det vedertagna tänkandet kring operativsystem sedan supporterbjudanden började erbjudas för många decennier sedan.

Det har tidigare varit vanligt att utgåvor av både server- och skrivbordsoperativsystem följde denna modell, men specifikt inom Linux-området började vi se detta skakas om, där mindre formella produkter var fria att experimentera med snabbare, ostödda eller helt enkelt ostrukturerade utgåvor. Inom det primära produktområdet erbjöd openSuse, Fedora och Ubuntu alla korttidsstödserbjudanden eller snabbutgåveerbjudanden. I stället för utgivningscykler mätta i år och supportcykler som närmade sig ett decennium förkortade de utgivningscyklerna till månader och supporten till bara månader eller som mest några få år.

Inom skrivbordsområdet var det ofta logiskt att få nya funktioner och applikationer tidigare, i stället för att primärt fokusera på stabilitet som var vanligt på servrar, och det medförde den extra fördelen att nya tekniker eller tillvägagångssätt kunde testas på produkter med snabbare utgivningscykler innan de integrerades i serverprodukter med långtidsstöd. Fedora är till exempel en provningsplats för tekniker som, efter att de bevisat sig, kommer att ta sig in i utgåvor av Red Hat Enterprise Linux. Genom att använda Fedora får slutanvändare funktioner tidigare, får lära sig om RHEL-tekniker tidigare, och Red Hat får testa produkterna i stor skala innan de driftsätts på kritiska servrar.

Med tiden har stabiliteten hos korttidsutgåvor förbättrats dramatiskt, och i allt högre grad ses dessa system som gångbara alternativ för serversystem. Dessa system får nyare förbättringar, funktioner och uppgraderingar tidigare, vilket ofta ses som fördelaktigt.

En stor fördel med vilket operativsystem som helst är dess stödekosystem, inklusive de paket och bibliotek som stöds och tillhandahålls som en del av basoperativsystemet. Med långtidsutgåvor ser vi ofta att kritiska paket åldras dramatiskt under utgåvans livstid, vilket kan orsaka problem med prestanda, kompatibilitet och i extrema fall till och med säkerhet. Detta tvingar uppenbarligen användare av operativsystem med långtidsutgåvor att välja mellan att fortsätta leva med begränsningarna hos de äldre komponenterna eller att själva integrera nya komponenter, vilket ofta bryter sönder det grundläggande värdet hos en produkt med långtidsutgåva.

Eftersom målet med en långtidsutgåva är att ha stabilitet och integrationstestning, innebär det att byta ut komponenter inom produkten för att “kringgå” begränsningarna hos en LTS att dessa komponenter inte hanteras på ett LTS-mässigt sätt och att integrationstestningen från leverantören med största sannolikhet inte längre sker, eller om den sker, inte i samma grad. I praktiken blir resultatet att detta blir en egenbyggd produkt med korttidsutgåva, fast med föråldrade kärnkomponenter och mindre tillsyn.

I verkligheten är detta, i de flesta avseenden, värre än att gå direkt till en produkt med korttidsutgåva. Att använda en produkt med korttids- eller snabbutgåva gör att leverantören kan upprätthålla den förväntade testningen och integrationen, fast med en snabbare utgivnings- och supportcykel, så att det allmänna värdet hos konceptet med långtidsutgåvor bevaras och med alla operativsystemets komponenter, snarare än bara några få, uppdaterade. Detta möjliggör mer standardisering, branschtestning samt delad kunskap och integration än med en partiell LTS-modell.

Kanske har tiden kommit att ompröva värdet av långtidsstöd för operativsystem. Alltför länge tycks värdet av detta tillvägagångssätt helt enkelt ha tagits för givet och följts, och det hade och har förvisso sina förtjänster; men operativsystemsvärlden har förändrats sedan detta tillvägagångssätt först introducerades. Behovet av uppdateringar har ökat samtidigt som förändringstakten hos sådant som kärnor och bibliotek har avtagit dramatiskt. Kraftfullare servrar har flyttat kompatibiliteten högre upp i stacken, och i stället för att mjukvara skrivs för ett operativsystem skrivs den ofta för en specifik version av ett språk eller en körtid eller något annat abstraktionslager.

Kortare utgivningscykler innebär att system får funktioner, från topp till botten, oftare. Uppdateringar mellan “större” utgåvor är mindre och har lägre påverkan. Förändringar från uppdateringar är mer inkrementella, vilket ger en mer organisk inlärnings- och anpassningskurva. Och allra viktigast: behovet av att byta ut systemkomponenter som är noggrant testade och integrerade mot versioner som tillhandahålls av tredje part blir, i praktiken, något oerhört ovanligt.

Stabilitet för mjukvaruleverantörer är fortsatt ett värde med långtidsutgåvor och kommer att skapa ett behov av att använda långtidsutgåvor under lång tid framöver. Men för systemadministratören tycks värdet av detta tillvägagångssätt minska och har, anser jag personligen, nått en brytpunkt under de senaste åren. Det brukade kännas förväntat och normalt att vänta två eller tre år på att paket skulle uppdateras, men i dag känns detta onödigt omständligt. Det tycks bli allt vanligare att komponenter på högre nivå byggs med ett krav på nyare underliggande komponenter; en förväntan om att operativsystem antingen kommer att vara mer aktuella eller att delar av operativsystemet kommer att uppdateras separat från resten.

Ett starkt beroende av containeriseringstekniker kan på vissa sätt vända denna trend, men på sätt som samtidigt alltid minskar värdet av långtidsutgåvor. Containerisering minskar behovet av omfattande funktionalitet i basoperativsystemet, vilket gör det enklare och mer effektivt att uppdatera oftare för förbättrat stöd för kärna, filsystem, drivrutiner och containrar, samtidigt som bibliotek och andra beroenden lämnas kvar i containrarna, vilket gör att applikationer som behöver beroenden med långtidsstöd kan tillgodoses på det sättet och applikationer som kan dra nytta av nyare komponenter kan hanteras på det viset.

Naturligtvis har virtualisering spelat en roll i att minska värdet av modeller med långtidsstöd genom att göra snabb återställning och duplicering av system trivialt. Den stabilitet som vi har behövt utgåvor med långtidsstöd för att åstadkomma tillgodoses delvis av virtualiseringslagret; hårdvaruabstraktion förbättrar drivrutinsstabiliteten på mycket viktiga sätt. I samma anda minskar även devops-baserade supportmodeller behovet av långtidsstöd och gör serverekosystem mer agila och flexibla. Trender inom systemadministrationsparadigm tenderar att gynna modernare operativsystem.

Tiden får utvisa om trenderna fortsätter i den riktning de är på väg. För egen del har det gångna året varit ett ögonöppnande år som har fått mig att flytta mina egna arbetslaster från ett decennium av orubbligt stöd för produkter med mycket långt långtidsstöd till produkter med snabbutgåva, och jag måste säga att jag är mycket nöjd med förändringen.