– Mangel på mangfold gjør oss utsatt
– For den neste store hendelsen kan ramme skyleverandøren eller biblioteket nettopp din applikasjon er avhengig av, advarer Kent Inge Fagerland Simonsen.
En nydelig julidag i 2024, den 19. i rekken, var jeg på vei hjem til Norge etter et noen uker på en spansk kyst.
Vi leverte leiebilen, sjekket inn og ante fred og ingen fare til vi plutselig stod som sild i tønne i avgangshallen.
Samtlige fly var forsinket, og mange var kansellert. Vi var heldige og kom hjem bare et par timer etter skjema. Mange andre fikk ufrivillig utvidet sine ferier betydelig når 4-5% av flyvningene i verden den dagen ble innstilt.
Hjemme fant jeg ut hva som hadde skjedd: Crowdstrike hadde slått til. En oppdatering til IDS-en Crowstrike for Windows hadde ført til blåskjermer verden over, med mange langt mer alvorlige konsekvenser enn litt forsinkede turister.
Programvare feiler
Om vi går litt dypere, så kan vi ane at det ligger et lag bak IDS-er og OS-er:
At så store deler av vår infrastruktur verden over er avhengig av at en gitt kombinasjon av IDS og OS skal fungere.
Og, som vi kan ane av IT-historien de siste tiårene, programvare feiler av og til.
Om vi tar dette for gitt, blir problemet at vi har gjort oss så avhengige av enkeltkombinasjoner av programvare.
Og dersom vi tar for gitt at det ikke finnes perfekt programvare som kan kjøre helt uten risiko for å feile, så blir en mulig løsning for å unngå denne typen problemer å bruke flere programvarekomponenter til å gjøre samme ting – det vil si å innføre litt mangfold i programvaren vi bruker for en gitt jobb.
Mangel på mangfold, eller monokulturer, kan gjøre oss utsatt for slike feil.
Mangfold beskytter
Dersom halvparten av check-in-terminalene som ble slått ut av Crowdstrike-feilen hadde kjørt en eller annen kombinasjon av IDS og OS, ville flere flyplasser holdt åpent den dagen, og kaoset kunne vært betydelig redusert på flyplasser verden over.
Med andre ord: Litt mangfold kan beskytte mot store systemiske tjenesteavbrudd.
Og motsatt: Mangel på mangfold, eller monokulturer, kan gjøre oss utsatt for slike feil.
Hvordan kan vi så skape litt mangfold i våre applikasjoner uten at det går for mye på bekostning av kost og stabilitet?
Dette spørsmålet har mange mulige svar for mange mulige situasjoner.
Robust frontend
For frontend-er kan det bety å prøve å unngå server-side rendering.
For web-applikasjoner som kan sendes til browseren som kun filer, så er det veldig enkelt å endre hvor disse serveres fra – om det er fra FreeBSD-maskinen under trappa eller fra en Azure Storage Account, så er det bare DNS-pekeren som må byttes for å vekse mellom dem.
Om server-side rendering er nødvendig, så kan man sørge for at det er mulig å kjøre webapplikasjonen på open source-infrastruktur, som ikke er avhengig av enkeltversjoner av underliggende biblioteker og plattformer.
I selve webapplikasjonen kan det være lurt å tenke over hvilke tredjepartskomponenter man gjør seg avhengig av, og hvordan man kan fjerne dem eller bytte over til andre komponenter ved behov.
Robust backend
Når det gjelder backend, kan risiko for redusert tilgjengelighet mitigeres ved å gjøre seg uavhengig av spesifikke backender.
En måte å gjøre det på er ved å bruke SOLID, som vi skrev litt om i en tidligere artikkel.
Når det ikke er mulig å unngå en dedikert backend, er det likevel mulig å redusere risiko ved å innføre litt mangfold i backend-koden og i den soft-/hardware-en den kjører på.
Om man har store krav til oppetid og frykter at .NET kan bli en utfordring, så kan det være en ide å skrive en versjon i Java i tillegg. Men dette kan fort bli dyrt.
Mitigerende tiltak kan være å modellere applikasjonen i et modelleringsspråk som gjør det mulig å lage, for eksempel, både Java- og .NET-implementasjoner mer eller mindre automatisk, basert på modellen.
Om man ikke ønsker å endre koden, er det også mulig å benytte en “diversity engine” som kan endre koden i applikasjonen på umerkbart vis, men som gjør at samme sårbarhet ikke nødvendigvis lar seg utnytte på samme måte i hver versjon.
Har man har store krav til tilgjengelighet, kan det uansett være fordelaktig å sørge for at koden kan gjøre på mer enn én plattform. Dette er mulig å oppnå, for eksempel ved å bruke OCI-containere og kjøre applikasjoner i Kubernetes heller enn å bruke en eller annen sky-leverandør sine spesialiserte systemer.
Slik er det mulig å ikke bare migrere mellom leverandørene, men også å kjøre hos flere samtidig.
Microsoft og Google
Men vi lager jo ikke all programvare vi bruker helt selv.
Så også når det gjelder tredjepartprogramvare, inkludert SaaS-løsninger, er det nok lurt å tenke på hva man kan gjøre uten disse.
Hva om, for eksempel, Microsofts Office-programmer ikke lenger kunne stoles på eller brukes av en eller annen grunn? Store deler av landets virksomhet ville i dag få problemer med å håndtere en slik situasjon.
Og når vi tenker på at Microsoft og Google sammen har så godt som et monopol på slik programvare, kan det være at vi gjør lurt, som samfunn, å investere litt i noen backup-planer – om det er NextCloud, LibreOffice + Linux, eller tilpassede løsninger med Solid som datalager (eller aller helst, alt sammen, for bedre mangfold).
Uansett hvilken situasjon man er i og hvilken tilgang man velger, kan det være lurt å tenke over hvordan man kan beskytte seg mot sjeldne, men veldig store nedetidshendelser på internett.
Den neste store hendelsen kan ramme nettopp den skyleverandøren eller det programvarebiblioteket som nettopp din applikasjon er avhengig av.
