Att välja programvaruversioner för driftsättning

Något som jag mycket ofta ser diskuteras i IT-kretsar är “vilken version av programvaran ska jag installera”. Detta kan gälla en databas, en applikation, fast programvara eller, troligen oftast, operativsystem, och i och med det stundande slutet på supporten för Windows XP har ämnet nått en febrig intensitet.

Det finns i praktiken två sidor i denna diskussion. Den ena sidan anser att den senaste och, förmodas det, bästa programvaran alltid bör användas. Den andra anser att programvaran behöver mogna och intar en avvaktande hållning, eller betraktar till och med varje version som en separat produkt snarare än ett kontinuum av utveckling.

Båda synsätten har sina förtjänster och inget bör existera helt utan det andra. Att blint uppdatera programvara på måfå är inte klokt, och att undvika korrigeringar och uppdateringar utan anledning är inte heller klokt. Noggrant övervägande av faktorerna och förståelse för programvaruutvecklingsprocessen är viktigt att hålla i minnet när dessa beslut fattas.

För det första finns det två helt olika scenarier att överväga. Det ena är uppdateringen av befintlig, redan installerad programvara. Antagandet är att det nuvarande tillståndet “fungerar”, med den accepterade möjligheten att “fungerar” kan innefatta en säkerhetsexponering som har upptäckts och kräver uppdatering för att åtgärdas. Det andra scenariot är en ny driftsättning där det inte finns något i nuläget och vi börjar från noll.

Låt oss börja med det andra fallet, eftersom det är betydligt enklare att ge vägledning kring.

När det gäller nya programvarudriftsättningar (eller nya operativsystem) ska man alltid använda den aktuella, senaste versionen av programvaran, om det inte finns en tydligt känd teknisk begränsning som hindrar det – såsom kända buggar eller programvaruinkompatibiliteter.

Programvara är inte som andra typer av produkter, särskilt inte i dagens värld med korrigeringar och uppdateringar som släpps online. Jag antar att tankesättet att äldre programvaruversioner skulle kunna vara att föredra framför aktuella härrör från en kombination av fysiska produkter (klockor, bilar, porslin, möbler, vin) där en viss årgång eller modell kan vara överlägsen en nyare modell av olika skäl, och från äldre sätt att leverera programvara där färdiga programvaruprodukter helt enkelt “kastades över muren” och det slutgiltiga tillståndet, helt enkelt, var det slutgiltiga tillståndet utan några rimliga möjligheter till uppdateringar, korrigeringar eller åtgärder. Inget av dessa fall gäller för modern affärsprogramvara (med endast de allra sällsyntaste undantagen).

Programvaruutveckling är i grova drag ett kontinuum. Normala utvecklingsprocesser innebär att ny programvara byggs ovanpå gammal programvara, antingen direkt (genom att skapa uppdateringar av en befintlig kodbas) eller indirekt (genom att bygga om utifrån kunskap som vunnits av att ha byggt en tidigare version av programvaran). Tanken är att varje efterföljande version av programvaran är överlägsen den föregående. Detta är förstås inte garanterat – det finns sådana begrepp som regressionsfel och helt enkelt dålig utveckling – men på det stora hela förbättras programvara över tid, särskilt när vi talar om programvara i företagsklass som används i företag och som är under aktiv utveckling. Ny programvara är inte bara nästa fas av den gamla programvaran; den representerar också, i nästan samtliga fall, det aktuella tillståndet av korrigeringar, buggfixar, uppdateringar och, vid behov, förändringar i tillvägagångssätt eller teknik. Ny programvara från kvalitetsverkstäder är nästan undantagslöst bättre än gammal programvara. Programvara utvecklas och mognar.

Bortom programvarans egen kvalitet finns begreppet att investera i framtiden. Programvara är inte något som kan ligga på hyllan för evigt. Den behöver, till viss grad, hållas uppdaterad, annars slutar den att fungera eftersom plattformen den körs på förändras, någon ny omständighet uppdagas, säkerhetshål upptäcks eller behoven förändras. Att installera gammal programvara innebär att man investerar i det förflutna, en investering i att installera, lära sig, använda och stödja gammal teknik. Detta kallas “teknisk skuld”. Denna gamla teknik kan hålla i flera år eller till och med decennier, men gammal programvara förlorar i värde över tid och blir allt dyrare att stödja, både för leverantörerna, om de fortsätter att stödja den, och för slutanvändarna, som måste stödja den.

Samma begrepp om teknisk skuld gäller för programvaruleverantörerna i fråga. Det finns en mycket stor kostnad i att skapa programvara och särskilt i att underhålla flera versioner av den programvaran. Programvaruleverantörer har starka incitament att minska supporten för äldre versioner för att fokusera resurser på aktuella programvarureleaser (detta är ett viktigt skäl till att SaaS-driftsättningar är så populära; leverantören kontrollerar de tillgängliga versionerna och kan eliminera äldre versioner genom uppdateringar). Om kunder kräver support för gamla versioner måste kostnaden absorberas någonstans, och ofta absorberas den både i form av monetär påverkan på samtliga kunder och som ett minskat fokus på den nya produkten, eftersom utvecklingsteam måste delas upp för att stödja korrigering av gamla versioner samtidigt som de utvecklar den nya. Ju mer ansträngning som måste läggas på gamla versioner, desto mindre ansträngning kan läggas på nya förbättringar.

Inom ramen för vad jag redan har sagt är det viktigt att tala om kodmognad. Ofta anges kodmognad som ett skäl för att driftsätta “gammal kod”, men jag tror att detta är ett IT-missförstånd av programvaruutvecklingsprocesserna. Om vi tänker på en släppt kodrad blir den inte mognare bara för att den är släppt och i bruk. Kod förändras inte ute i det fria, den bara ligger där. Dess mognad är “låst” den dag den släpps. Om den korrigeras, ja, då skulle den “mogna” efter release. Senare versioner av samma programvara, baserade på samma kodbas men mer uppdaterade, är i sann mening den mognare koden, eftersom den har granskats, uppdaterats, testats och så vidare i högre grad än den tidiga releasen av samma kod.

Detta är kontraintuitivt jämfört med exempelvis en bil, där varje release är något helt nytt med nya möjligheter till mekaniska problem och andra tillförlitlighetsbekymmer – där det att vänta några år ger dig en chans att se vilka tillförlitlighetsproblem som uppdagas. Programvara är inte sådan. Så begreppet att vilja ha mognare programvara skulle driva dig att driftsätta det “senaste och bästa” snarare än det “beprövade och säkra”.

Om vi tänker på programvaruversionsnummer ungefär som åldrar framträder detta. Linux 3.1 är mycket äldre, i fråga om programvarumognad, än Linux 2.4. Den har ett decennium av ytterligare utveckling.

Låt oss använda ett verkligt exempel som är högst relevant idag. Du är på en arbetsplats som står i begrepp att installera sin(a) första server(rar). Windows Server 2012 R2 har just släppts. Bör du installera Windows Server 2008, 2008 R2 (2010), Server 2012 eller Server 2012 R2 (sent 2013)?

För många arbetsplatser låter detta som om vi talar om någonstans mellan två och fyra helt olika produkter, som troligen har olika skäl bakom valet av var och en. Detta är på det stora hela osant. Varje nyare version är helt enkelt en uppgradering, uppdatering, korrigering och funktionsökning av den föregående. Var och en är i sin tur mer avancerad och mogen än den föregående. Varje ny version drar nytta av det arbete som lagts ned på den ursprungliga releasen av sin föregångare, liksom buggfixar, korrigeringar och funktionstillägg som gjorts under tiden mellan den ursprungliga releasen och efterföljarens release. Varje ny release är i själva verket en “mindre release” av den föregående. Om vi tittar på kärnans revisionsnummer i stället för marknadsföringsnamnen på releaserna kan det bli mer begripligt.

Windows Server 2008 var Windows NT 6.0. Windows Server 2008 R2 var Windows NT 6.1, uppenbarligen en mindre revision eller till och med en “korrigering” av den föregående releasen. Windows Server 2012 var Windows NT 6.2 och vår nuvarande Windows Server 2012 R2 är Windows NT 6.3. Om vi skulle använda revisionsnumren i stället för marknadsföringsnamnen låter det nästan vansinnigt att avsiktligt installera en gammal, mindre mogen, mindre uppdaterad och mindre korrigerad version. Vi vill ha de senaste uppdateringarna, de senaste buggfixarna och att de senaste säkerhetsproblemen har åtgärdats.

För nya programvarudriftsättningar gäller att ju nyare programvaran som installeras är, desto bättre möjlighet att utnyttja de senaste funktionerna och desto mer tid innan den oundvikliga föråldringen tar ut sin rätt. All programvara åldras, så att installera nyare programvara ger den bästa chansen att den programvaran håller längst. Det ger den bästa flexibiliteten inför den okända framtiden.

Att följa denna tankegång kan få oss att känna att det även skulle vara rimligt att driftsätta förhandsversioner eller till och med betaprogramvara. Och även om det kan finnas specifika fall där detta är rimligt, såsom i “testgrupper” för att utvärdera programvara innan den släpps till företaget i stort, är det i allmänhet inte det. Förhandsversioner av programvara är till sin natur sådana att de inte stöds och kan innehålla kod som aldrig kommer att stödjas. Att använda sådan kod isolerat kan vara fördelaktigt, men för allmänt bruk avråds det. Det finns viktiga processer som följs mellan förhands- eller betareleaser och slutgiltiga releaser av kod, oavsett vilken mognadsnivå den övergripande produkten befinner sig på.

Det för oss till den andra situationen, den där vi uppdaterar befintlig programvara. Detta är förstås ett helt annat scenario än en nyinstallation, och det finns många, många fler faktorer inblandade.

En av de största faktorerna i de flesta situationer är licensiering. Att uppdatera programvara regelbundet kan medföra licensavgifter som måste vägas in i ekvationen mellan nytta och kostnad. Vissa produkter, som de flesta program med öppen källkod, har inte denna kostnad och kan uppdateras så snart nya versioner finns tillgängliga.

Den andra verkligt stora faktorn vid uppdatering av programvara är den mänskliga arbetskostnaden för uppdateringen – till skillnad från vid en nyinstallation, där installationsinsatsen i praktiken är likvärdig mellan gammal och ny programvara. I verkligheten tenderar ny programvara att vara enklare att installera än gammal, helt enkelt på grund av förbättringar och framsteg. Att underhålla en enda programvaruversion under ett decennium innebär att resurser under den tiden inte ägnades åt uppgraderingsprocesser. Att uppgradera årligen under den tiden innebär att resurser användes tio gånger för att genomföra separata uppgraderingar. Det gör uppdatering mycket svårare att kostnadsmotivera. Men det handlar om mer än bara insatsen för själva uppdateringsprocessen; det finns också den fortlöpande utbildning som behövs för de slutanvändare som tvingas uppleva fler förändringar, oftare, genom ständiga uppgraderingar.

Detta kan få uppdatering av programvara att låta som något negativt, men det är det inte. Det är helt enkelt en ekvation där varje sida måste vägas. Regelbundna uppdateringar innebär ofta små, stegvisa förändringar snarare än stora språng, vilket gör att slutanvändare kan anpassa sig mer naturligt. Regelbundna uppdateringar innebär att uppdateringsprocesserna ofta är enklare och mer förutsägbara. Regelbundna uppdateringar innebär att den tekniska skulden alltid hålls i schack och att fördelarna med de nyare versionerna, vilka kan vara funktioner, effektivitetsvinster eller säkerhetsförbättringar, finns tillgängliga tidigare, så att de kan utnyttjas under en längre period.

Utifrån vad vi har lärt oss av de två scenarierna ovan finns det dock ytterligare en viktig insikt att hämta här. När väl beslutet att genomföra en uppdatering har fattats är frågan ofta “till vilken version uppdaterar vi?” I verkligheten är emellertid varje uppdatering som är mer än en vanlig korrigeringsprocess i själva verket som ett miniatyrbeslut om köp av “ny programvara”, och logiken bakom varför vi “alltid” installerar den senaste tillgängliga versionen vid en nyinstallation gäller även här. Så när vi genomför en uppdatering bör vi nästan alltid uppdatera så långt vi kan – förhoppningsvis till den aktuella versionen.

För att tillämpa Microsoft-exemplet igen kan vi ta en organisation som har Windows XP driftsatt idag. Företaget beslutar att investera i en uppdateringscykel till en nyare version, inte bara fortsatt korrigering. Det finns flera versioner av Windows skrivbordsplattform som fortfarande har aktiv support från Microsoft. Dessa inkluderar Windows Vista, Windows 7, Windows 8 och Windows 8.1. Att uppdatera till en av de mindre aktuella versionerna resulterar i kortare tid innan den versionens slutdatum för support, vilket ökar organisationens risk; att använda äldre versioner innebär fortsatt investering i redan gammal teknik, vilket innebär en ökning av den tekniska skulden och mindre tillgång till nya funktioner som kan visa sig vara fördelaktiga när de väl finns tillgängliga. I just detta exempel anses nyare versioner dessutom vara säkrare och kräva färre hårdvaruresurser.

Varje företag måste finna rätt balans för sig självt när det gäller uppdateringscykler för befintlig programvara. Varje företag och varje programvarupaket är olika. Företagsprogramvara som Microsoft Windows, Microsoft Office eller en Oracle Database följer dessa modeller mycket väl. Små programvaruprojekt och de som ligger nära det skräddarsydda kan ha en mer dynamisk och oförutsägbar releasecykel, men följer i allmänhet ändå merparten av dessa regler. Överväg att tillämpa förståelse för programvaruutvecklingsprocessen för att begripa hur du och din programvaruleverantör bäst kan samarbeta för att leverera störst värde till din organisation, och kombinera det med ditt behov av att minska den tekniska skulden för att utnyttja din programvaruinvestering på bästa möjliga sätt för din organisation.

Men tumreglerna är relativt enkla:

När du driftsätter ny programvara eller uppdaterar, sikta på den senaste rimliga versionen av programvaran. Använd varje tillfälle till driftsättning för att eliminera så mycket teknisk skuld som möjligt.

När programvara redan finns på plats, väg faktorer såsom mänsklig arbetsinsats, licenskostnader, miljömässig enhetlighet och kompatibilitetstestning mot fördelar i form av funktioner, prestanda och teknisk skuld.