Velge programvareversjoner for distribusjon

Noe jeg ser diskutert svært ofte i IT-kretser er «hvilken versjon av programvare bør jeg installere.» Dette kan gjelde en database, en applikasjon, fastvare eller, kanskje oftest, operativsystemer, og med den kommende slutten på støttelivssyklusen for Windows XP har temaet nådd kokepunktet.

Det er i praksis to sider i denne diskusjonen. Den ene siden mener at den nyeste og antagelig beste programvaren alltid bør brukes. Den andre mener at programvare trenger å modnes og inntar en «vent og se»-tilnærming, eller anser til og med hver versjon som et annet produkt og ikke en kontinuitet i utviklingen.

Begge tilnærminger har sine fordeler, og ingen av dem bør eksistere helt uten den andre. Å oppdatere programvare blindt og ukritisk er ikke klokt, og det er heller ikke klokt å unngå oppdateringer uten grunn. Nøye vurdering av faktorene og empati for programvareutviklingsprosessen er viktig å ha i bakhodet når man tar disse beslutningene.

Først og fremst er det to helt forskjellige scenarier å ta hensyn til. Det ene er oppdatering av eksisterende, nåværende programvare. Forutsetningen er at den nåværende tilstanden er «fungerende», med den aksepterte muligheten for at «fungerende» kan innebære en sikkerhetseksponering som er oppdaget og krever oppdatering for å lukkes. Det andre scenariet er en ny distribusjon der det ikke finnes noe fra før, og vi starter fra scratch.

La oss starte med det andre tilfellet, ettersom det er langt enklere å gi veiledning om.

I tilfelle av nye programvaredistribusjoner (eller nye operativsystemer) bør man alltid bruke den nåværende, nyeste versjonen av programvaren, med mindre det er en klart kjent teknologibegrensning som hindrer det – som kjente feil eller programvareinkompatibiliteter.

Programvare er ikke som andre typer produkter, spesielt ikke i dagens verden med nettbaserte oppdateringsutgivelser. Jeg antar at mentaliteten om at gamle versjoner av programvare kan være å foretrekke fremfor nåværende, stammer fra en kombinasjon av fysiske produkter (klokker, biler, serviser, møbler, vin) der et bestemt år eller modell kan være overlegent et nyere for ulike årsaker, og fra eldre programvareleveringsmåter der ferdige programvareprodukter bare ble «kastet over veggen» og den endelige tilstanden rett og slett var den endelige tilstanden uten rimelige muligheter for oppdateringer, patching eller rettelser. Ingen av disse tilfellene gjelder for moderne forretningsprogramvare (med bare de sjeldneste unntak.)

Programvareutvikling er grovt sett en kontinuitet. Normale utviklingsprosesser har ny programvare bygget oppå gammel programvare enten direkte (ved å lage oppdateringer til en eksisterende kodebase) eller indirekte (ved å bygge om basert på kunnskap tilegnet fra å ha bygget en tidligere versjon av programvaren.) Ideen er at hver påfølgende versjon av programvare er overlegen den foregående. Dette er ikke garantert, selvfølgelig; det finnes konsepter som regresjonsfeile og rett og slett dårlig utvikling, men i store trekk forbedres programvare over tid – spesielt når vi snakker om programvare av enterprise-klasse som brukes i bedrifter og er under aktiv utvikling. Ny programvare er ikke bare neste fase av den gamle programvaren; den representerer i nesten alle tilfeller også den nåværende tilstanden av oppdateringer, feilrettinger, vedlikehold og, når nødvendig, endringer i tilnærming eller teknikk. Ny programvare, fra seriøse utviklingsmiljøer, er nesten utelukkende bedre enn gammel programvare. Programvare utvikler seg og modnes.

Utover kvaliteten på selve programvaren er det konseptet å investere i fremtiden. Programvare er ikke noe som kan stå på hyllen for alltid. Den må i en viss grad holdes oppdatert, ellers slutter den å fungere fordi plattformen den kjører på endres, nye artefakter kommer til syne, sikkerhetshull oppdages eller behov endres. Å installere gammel programvare betyr at man investerer i fortiden – en investering i å installere, lære, bruke og støtte gammel teknologi. Dette kalles «teknisk gjeld.» Denne gamle teknologien kan vare i år eller til og med tiår, men gammel programvare mister verdi over tid og blir stadig dyrere å støtte, både for leverandørene, om de fortsetter å støtte den, og for sluttbrukerne, som må støtte den.

Det samme konseptet om teknisk gjeld gjelder for de aktuelle programvareleverandørene. Det er svært høye kostnader forbundet med å lage programvare, og spesielt med å vedlikeholde flere versjoner av den programvaren. Programvareleverandører har stor incentiv til å redusere støtten for eldre versjoner for å fokusere ressurser på nåværende programvareutgivelser (dette er en viktig grunn til at SaaS-distribusjoner er så populære – leverandøren kontrollerer tilgjengelige versjoner og kan eliminere eldre versjoner gjennom oppdateringer.) Hvis kunder krever støtte for gamle versjoner, må kostnaden absorberes et sted, og ofte absorberes den både i form av monetær innvirkning på alle kunder og en redusert fokus på det nye produktet ettersom utviklingsteamene må deles for å støtte patching av gamle versjoner i tillegg til utvikling av det nye.

Innenfor rammen av det jeg allerede har sagt, er det viktig å snakke om kodemodning. Ofte nevnes kodemodning som en grunn til å distribuere «gammel kode», men jeg tror dette er en IT-misforståelse av programvareutviklingsprosesser. Hvis vi tenker på en utgitt kodelinje, gjør det den ikke mer moden bare fordi den er utgitt og i bruk. Kode endres ikke i naturen, den sitter bare der. Dens modning er «låst» den dagen den utgis. Hvis den patches, ja, da vil den «modnes» etter utgivelse. Senere versjoner av den samme programvaren, basert på den samme kodebasen men mer oppdatert, er virkelig den mer «modne» koden ettersom den har blitt gjennomgått, oppdatert, testet osv. i større grad enn den tidlige utgivelsen av den samme koden.

Dette er motstridende intuitivt i forhold til for eksempel en bil, der hver utgivelse er noe ferskt med nye muligheter for mekaniske problemer og ulike pålitelighetshensyn – der det å vente noen år gir deg sjansen til å se hvilke pålitelighetsproblemer som avdekkes. Programvare er ikke slik. Så konseptet om å ønske mer moden programvare vil presse deg mot å distribuere «det nyeste og beste» snarere enn det «velprøvde og pålitelige.»

Hvis vi tenker på programvareversjonsnumre mer som aldre, kommer dette frem. Linux 3.1 er mye eldre, i form av programvaremodning, enn Linux 2.4. Det har et tiår med ekstra utvikling.

La oss bruke et virkelig eksempel som er svært relevant i dag. Du er i ferd med å installere dine første server(e). Windows Server 2012 R2 er nettopp utgitt. Bør du installere Windows Server 2008, 2008 R2 (2010), Server 2012 eller Server 2012 R2 (sent 2013)?

For mange virksomheter høres dette ut som om vi snakker om et sted mellom to og fire helt forskjellige produkter som sannsynligvis har ulike grunner for å velge hvert enkelt. Dette er i stor grad usant. Hver nyere versjon er rett og slett en oppgradering, oppdatering, patch og funksjonsøkning av den foregående. Hver er i sin tur mer avansert og moden enn den foregående. Hver ny versjon drar nytte av arbeidet som ble gjort på den originale utgivelsen av forgjengeren, samt feilrettinger, oppdateringer og funksjonstillegg gjort i mellomtiden mellom den originale utgivelsen og etterfølgerutgivelsen. Hver ny utgivelse er i realiteten en «mindre utgivelse» av den foregående. Hvis vi ser på kjernerevisjonsnumrene i stedet for markedsnavnene på utgivelsene, gir det kanskje mer mening.

Windows Server 2008 var Windows NT 6.0. Windows Server 2008 R2 var Windows NT 6.1, åpenbart en mindre revisjon eller til og med en «patch» av den foregående utgivelsen. Windows Server 2012 var Windows NT 6.2 og vår nåværende Windows Server 2012 R2 er Windows NT 6.3. Hvis vi skulle bruke revisjonsnumrene i stedet for markedsnavnene, høres det nesten galt ut å med vilje installere en eldre, mindre moden, mindre oppdatert og mindre patchet versjon. Vi ønsker de nyeste oppdateringene, de nyeste feilrettingene og at de nyeste sikkerhetsproblemene er adressert.

For nye programvaredistribusjoner gir nyere programvare som installeres den beste muligheten til å utnytte de nyeste funksjonene og mest tid før uunngåelig foreldelse tar sin toll. All programvare eldes, så det å installere nyere programvare gir den beste sjansen for at den programvaren vil vare lengst. Det gir best fleksibilitet for en ukjent fremtid.

Å følge denne tankegangen kan føre oss til å føle at distribusjon av forhåndsversjon eller til og med betaprogramvare ville gi mening. Og selv om det kan finnes spesifikke tilfeller der dette er fornuftig, for eksempel i «testgrupper» for å sjekke ut programvare før den utgis til hele selskapet, er det generelt ikke tilfelle. Naturen til forhåndsversjonsprogramvare er at den ikke støttes og kan inneholde kode som aldri vil bli støttet. Å bruke slik kode isolert kan være nyttig, men for generell bruk er det ikke anbefalt. Det er viktige prosesser som følges mellom forhåndsvisnings- eller beta-utgivelser og endelige utgivelser av kode uansett hvilket modningsnivå det samlede produktet er på.

Det bringer oss til den andre situasjonen – den der vi oppdaterer eksisterende programvare. Dette er selvfølgelig et helt annet scenario enn en fersk installasjon, og det er mange, mange flere faktorer involvert.

En av de største faktorene for de fleste situasjoner er lisensering. Regelmessig oppdatering av programvare kan medføre lisensavgifter som må innregnes i fordeler- og kostnadligningen. Noen produkter, som det meste av åpen kildekode-programvare, har ikke denne kostnaden og kan oppdateres så snart nye versjoner er tilgjengelige.

Den andre virkelig store faktoren i oppdatering av programvare er den menneskelige innsatskostnaden ved oppdatering – i motsetning til ved en fersk installasjon, der innsatsen for installasjon i praksis er en jevn fordeling mellom gammel og ny programvare. I virkeligheten er ny programvare ofte lettere å installere enn gammel programvare, rett og slett på grunn av forbedringer og fremskritt. Å vedlikeholde en enkelt versjon av programvare i et tiår betyr at ressurser ikke ble dedikert, i løpet av den tiden, til oppgraderingsprosesser. Å oppgradere årlig i den perioden betyr at ressurser ble brukt ti ganger for å gjennomføre separate oppgraderinger. Det gjør oppdatering mye vanskeligere å kostnadsrettferdiggjøre. Men det er mer enn bare innsatsen i selve oppdateringsprosessen; det er også den kontinuerlige opplæringen som trengs for sluttbrukere som vil bli tvunget til å oppleve flere endringer, oftere, gjennom hyppige oppgraderinger.

Dette kan gjøre oppdatering av programvare til å høres negativt ut, men det er det ikke. Det er rett og slett en ligning der begge sider må veies. Regelmessige oppdateringer betyr ofte små, trinnvise endringer i stedet for store sprang, noe som lar sluttbrukere tilpasse seg mer naturlig. Regelmessige oppdateringer betyr at oppdateringsprosesser ofte er enklere og mer forutsigbare. Regelmessige oppdateringer betyr at teknisk gjeld alltid håndteres og at fordelene ved de nyere versjonene – som kan være funksjoner, effektivitetsforbedringer eller sikkerhetsforbedringer – er tilgjengelige tidligere, noe som lar dem utnyttes over lengre tid.

Basert på det vi har lært fra de to scenariene ovenfor, er det imidlertid en annen viktig lærdom å finne her. Når beslutningen om å utføre en oppdatering er tatt, er spørsmålet ofte «til hvilken versjon oppdaterer vi?» I realiteten er imidlertid enhver oppdatering som er mer enn en standard patchingprosess, egentlig som en miniatyrutgave av en «ny programvare»-kjøpsbeslutning, og logikken for hvorfor vi «alltid» installerer den nyest tilgjengelige versjonen ved en fersk installasjon gjelder også her. Så når vi utfører en oppdatering, bør vi nesten alltid oppdatere så langt vi kan – forhåpentligvis til den nåværende versjonen.

For å anvende Microsoft-eksemplet igjen kan vi ta en organisasjon som har Windows XP distribuert i dag. Virksomheten bestemmer seg for å investere i en oppdateringssyklus til en nyere versjon, ikke bare fortsatt patching. Det finnes flere versjoner av Windows-skrivebordsplattformen som fortsatt er under aktiv støtte fra Microsoft. Disse inkluderer Windows Vista, Windows 7, Windows 8 og Windows 8.1. Å oppdatere til en av de mindre nåværende versjonene resulterer i kortere tid til den versjonens slutt på levetid, noe som øker organisasjonens risiko; bruk av eldre versjoner betyr fortsatt investering i allerede gammel teknologi, noe som betyr økt teknisk gjeld og mindre tilgang til nye funksjoner som kan vise seg å være fordelaktige når de er tilgjengelige. I dette spesifikke eksemplet anses nyere versjoner også å være mer sikre og kreve færre maskinvareressurser.

Hver virksomhet må finne den rette balansen for seg selv når det gjelder eksisterende programvareoppdateringssykluser. Hver virksomhet og hvert programvarepakke er forskjellig. Enterprise-programvare som Microsoft Windows, Microsoft Office eller en Oracle-database følger disse modellene svært godt. Små programvareprosjekter og de som nærmer seg skreddersydd-området kan ha en mer dynamisk og uforutsigbar utgivelsessyklus, men vil generelt fortsatt følge de fleste av disse reglene. Vurder å anvende empati for programvareutviklingsprosessen for å forstå hvordan du og din programvareleverandør best kan samarbeide for å levere størst mulig verdi til din organisasjon, og kombiner det med ditt behov for å redusere teknisk gjeld for å utnytte programvareinvesteringen din på best mulig måte for din organisasjon.

Men tommelfingerreglene er relativt enkle:

Når du distribuerer nytt eller oppdaterer, sikt mot den nyeste rimelige versjonen av programvaren. Bruk enhver distribusjonsmulighet til å eliminere teknisk gjeld så mye som mulig.

Når programvare allerede eksisterer, veie faktorer som menneskelig innsats, lisenskostnader, miljøkonsistens og kompatibilitetstesting mot fordeler innen funksjoner, ytelse og teknisk gjeld.