USA, europeisk sky eller on-prem: Sånn vurderer du alternativene
Med arkitekt Magnus Eldens metode, kan du vurdere en USA-exit etter kritikalitetsnivå. – Den har vist seg særlig nyttig i dagens landskap.
Bruken av amerikanske skytjenester har lenge vært en selvfølge i teknologilandskapet. I kjølvannet av økende geopolitisk spenning og regulatoriske endringer, har mange begynt å stille spørsmål ved hvorvidt dette fortsatt er et trygt og bærekraftig valg.
Denne artikkelen handler imidlertid ikke om å reagere på en krise.
Metoden jeg presenterer her er noe jeg har utviklet og brukt over flere år. Det er en generell tilnærming til arkitektur og risiko, uavhengig av hvilke leverandører man bruker eller hvilken politisk situasjon man opererer i. Den har vist seg særlig nyttig i dagens landskap, men styrken ligger nettopp i at den er tidløs og fleksibel.
Likevel er det klart at den politiske utviklingen de siste årene har aktualisert behovet for mer bevisste og differensierte arkitekturvalg. Håpet er at ved å skrive dette ned der alle har tilgang kan hjelpe folk som sitter med akkurat denne problematikken nå.
Selv om denne metoden ikke er revolusjonerende i seg selv, har jeg sett få konkrete rammeverk eller veiledninger som faktisk systematiserer dette perspektivet. Den har likhetstrekk med Business Impact Analysis og ulike former for tjenesteklassifisering, men skiller seg ved å kombinere tekniske, regulatoriske og forretningsmessige hensyn i en samlet modell for arkitekturvalg.
Det er et perspektiv, ikke en ferdig mal, som har hjulpet meg med å holde oversikt over det viktige i enhver løsning.
Rask oppsummering av problemstillingen
Usikkerheten rundt bruk av amerikanske skytjenester ble for alvor (igjen) aktualisert etter, blant annet, at Trump-administrasjonen valgte å utfordre tidligere forpliktelser til transatlantiske avtaler om klimautslipp, og personvern og databehandling, og etter man innså at USA kan true Danmark med deres egen infrastruktur i Amerikansk sky.
Samtidig ser vi at avhengigheten til amerikanske aktører som Microsoft, Google og Amazon kan bli stadig mer kostbar, både økonomisk og politisk.
Dette har etterlatt mange virksomheter i en situasjon der de må velge mellom kosteffektivitet og hvor enkelt det er å komme i gang, og risikominimering, etikk, og robusthet.
Det er i dette landskapet behovet for en ny og mer robust tilnærming til skyarkitektur melder seg – en som tar høyde for geopolitisk risiko, regulatorisk usikkerhet og krav om digital suverenitet.
Hvilke kritiske aspekter man må sikre i skyløsninger?
Når man designer skyløsninger i et moderne og geopolitisk utfordret landskap, er det avgjørende å sikre visse fundamentale egenskaper utover det man kanskje vanligvis tenker på:
Autonomi – Løsningen må kunne operere uavhengig av eksterne parter ved behov, spesielt i krisesituasjoner eller dersom tilgangen til leverandørkonsoller faller bort.
Risikostyring – Det må være tydelig hvilke risikoer som bæres hvor, og hvordan disse kan kontrolleres og reduseres gjennom tekniske, prosess-, og organisatoriske tiltak.
Eierskap – Både data og operasjonell kontroll må forvaltes på en måte som sikrer virksomheten mot ukontrollerte juridiske og tekniske bindinger.
Avhengighetsrobusthet – Arkitekturen må være designet slik at man kan isolere eller miste komponenter uten at hele systemet kollapser. Det handler om å bygge løsninger som tåler komplett bortfall av selv tungt brukte integrasjoner og avhengigheter.
I en verden der ledende teknologileverandører også innebærer juridisk og politisk risiko er det vanskeligere enn noensinne å ta kloke valg og designe systemer "rett". Når man i tillegg kan forvente større endringer til hva som er lovlig, er de fire aspektene over mye viktigere å få til riktig.
Min metode for å imøtekomme de nye utfordringene er det jeg kaller design etter kritikalitetsgrenser.
Design etter kritikalitetsgrenser
Siden en stor del av problemet kommer fra at vi har kritiske komponenter som kjører på plattformer som vi ikke har kontroll på eller stoler helt på, må vi balansere risikoer deretter.
Min metode for å imøtekomme de nye utfordringene er det jeg kaller “design etter kritikalitetsgrenser”.
Det er noe overlap med andre konsepter som Business Impact Analysis, Service Tiering og Domain-Driven Design, men fokuset og fremgangsmåten er forskjellig. Dette er heller ikke en mal man kan følge, men et arkitekturisk perspektiv som hjelper med å ta gode valg. Det må balanseres opp mot standard arkitekturmessige hensyn.
Fokuset her er å kartlegge forretningsdomenet og eksisterende systemer og klassifisere dem på kritikalitetsnivåer. Standardsettet jeg bruker er:
Livsviktig
Kritisk for kjernefunksjonalitet
Nødvendig for sidefunksjonalitet
Kan leve foruten
La oss gå gjennom dem en om gangen, sett i lys av en nettbutikk som eksempel.
#1: Livsviktig
Dette er kategorien for de mest kritiske aspektene ved en løsning, i.e. komponenter som, dersom de kompromitteres eller forsvinner, vil kunne føre til virksomhetens umiddelbare sammenbrudd.
Det kan være juridisk, økonomisk eller tillitsmessig umulig å komme tilbake etter et slikt tap. Dette er ikke komponenter du må ha tilgang til eller kan restore fra backup, det er komponenter du må ha suveren kontroll over, uten mulighet for at tredjeparter kan innhente, slette eller endre innholdet.
Her ligger virksomhetens «kronjuveler»: eksempelvis oppskriften på Coca-Cola, identiteter til etterretningsagenter, eller kundefortegnelser og transaksjonsdata i en bank. Hvis noe i denne kategorien blir eksponert eller slettet, er det ikke tilstrekkelig å kjøre disaster recovery fordi det er i praksis over. Man må bare håpe at man kan minimere konsekvensene og starte på nytt.
Det er verdt å merke seg at svært få komponenter bør havne i denne kategorien. Ikke tenk på hva som er viktig eller verdifullt for din organisasjon, men tenk mer på hva som er uerstattelig og katastrofalt å miste.
#2: Kritisk for kjernefunksjonalitet
Denne kategorien omfatter komponentene og funksjonene som må være operative for at virksomheten i det hele tatt skal kunne fungere. Det handler ikke om bruker komfort eller optimalisering. Tenk basal drift. Hvis disse delene svikter, stopper virksomheten helt.
For en nettbutikk inkluderer dette blant annet nettsiden som kundene bruker for å handle, ordrehåndtering som behandler kjøpene, og kanskje lagerstyring som sikrer at varer faktisk kan sendes ut. Uten disse fungerer ikke kjernetjenesten, og det finnes ingen realistisk måte å opprettholde virksomheten på.
Typiske eksempler i denne kategorien er permanente datalagre for ordredata, kundeinformasjon og transaksjoner. Med andre ord, informasjon og funksjonalitet du er juridisk og operasjonelt avhengig av. Hvis en komponent i denne kategorien feiler, vil det nesten alltid kreve full katastrofegjenoppretting (disaster recovery) for å komme tilbake i drift.
Dette er den mest omfattende kategorien i mange løsninger, og det er ofte her man må prioritere redundans, sikkerhetskopiering og aktiv overvåkning for å sikre stabil og kontinuerlig drift.
#3: Nødvendig for sidefunksjonalitet
Denne kategorien inkluderer komponenter som gir betydelig verdi for både virksomheten og brukerne, men som ikke er helt nødvendige for at de mest grunnleggende prosessene skal fungere. Selv om brukere vil merke det, og konsumenter må kanskje operere i en begrenset kapsitet, så kan de falle vekk midlertidig eller permanent uten at det stopper hele tjenesten.
Disse funksjonene bidrar ofte til en bedre brukeropplevelse, mer effektive arbeidsprosesser, eller et bredere tjenestetilbud. Eksempler kan være:
Handlekurver som lar brukeren samle flere varer før betaling
Personlige anbefalinger
Ordrehistorikk og sporingsinformasjon
Automatisk genererte PDF-kvitteringer (ordredataene og kvitteringene selv er Kritisk for kjernefunksjonalitet)
Mulighet for å velge leveringstidspunkt
I motsetning til "Kan leve foruten", som i stor grad handler om optimaliseringer på toppen av eksisterende funksjonalitet, gir disse funksjonene reell merverdi og kan være forventet av brukerne. Likevel er de ikke avgjørende for kjernevirksomheten. Det er mulig å operere uten dem i kortere perioder; for eksempel ved feil, migrasjon eller leverandørbytte; men det bør være et tydelig mål å få dem tilbake i drift så raskt som mulig.
Disse delene er ofte integrasjonstunge og kan ligge nært både kjerne- og hjelpefunksjoner, noe som gjør det ekstra viktig å kartlegge deres avhengigheter riktig under arkitekturarbeidet.
#4: Kan leve foruten
Denne kategorien dekker funksjoner og komponenter som forbedrer brukeropplevelsen, øker effektiviteten eller gir løsningen et profesjonelt preg, men som ikke er nødvendige for å opprettholde funksjonalitetsbredden til tjenesten.
De bidrar til kvalitet og konkurransedyktighet, ja, men ikke til selve evnen til å levere alle funksjonelle aspekter av tjenesten.
Eksempler på slike elementer kan være:
Ytelsesoptimalisering (e.g. lavere responstid, raskere prosessering, større båndbredde)
Automatisk oversettelse av valuta eller språk
Personalisering av innhold basert på brukeratferd
Anbefalingsmotorer for mersalg
Dynamisk sortering eller visuelle forbedringer i grensesnittet
Dersom slike komponenter blir utilgjengelige, vil systemet fortsatt fungere, dog kanskje noe tregere eller med lavere brukerengasjement, men ikke på en måte som utløser en beredskapssituasjon.
Dette er funksjonene du skrur av først når du skal kutte kostnader, redusere kompleksitet eller gjøre systemet mer robust. De kan ses på som luksuslag i løsningen.
Kritikalitetsperspektivet kommer fra tre steg
Nå som vi har gått gjennom hva design etter kritikalitetsgrenser er for noe, kan vi begynne å se hvordan man kan generere et slikt perspektiv. Det er tre steg som kreves:
Kartlegg hvilke funksjoner og assets dere har, og hvor viktig de er.
Kartlegg hvordan de er koblet sammen for å avdekke avhengigheter og total systempåvirkning.
Grupper funksjonene og assetsan i de nivåene dere bruker, e.g. de fire nevnt over.
Har man kommet hit kan man starte å diskutere balansen mellom risikostyring, kostnader, leverandøruavhengighet, flyttbarhet, sikkerhet, robusthet, og alle andre ting som fører til gråere hår.
Vekting av hensyn per kritikalitetsnivå
Hvert nivå innebærer egne kriterier og en egen nøkkel for å vektlegge standardbekymringene i et IT initiativ.
Kostnad er vektlagt mye tyngre under Kan leve foruten enn under Livsviktig, mens flyttbarhet kanskje ikke er det. Denne nøkkelen er en av de viktigste dimensjonene å ha et bevisst forhold til.
En annen dimensjon er hvilke leverandører av, for eksempel, IaaS, PaaS, SaaS og FaaS man vurderer å bruke. Hver leverandør har fordeler og ulemper.
Noen gir deg full kontroll, men prisskaleringen er mye brattere. Andre gir deg veldig liten fleksibilitet, men er veldig enkel å ta i bruk. Andre igjen er fantastiske å jobbe med, men de har ikke størrelsen, modenheten, og økonomien til å håndtere store risikoer.
Ut i praksis
Har man kartlagt disse to dimensjonene kan man begynne å argumentere for hva som kan leve hvor.
Man kan da si at livsviktige komponenter må leve på en nasjonal norsk sky eller onprem, at kjernefunksjonskritiske komponenter kan leve i en europeisk sky, og at de komponentene man kan leve foruten kan man hoste på en amerikansk skyleverandør som Azure eller AWS.
Det er også viktig å påpeke at man kan bevege seg til venstre, ref. diagrammet under, uten noe problem fordi nivåene legger kun begrensinger på hva man kan tillate seg. De er ikke regler som må følges. La oss si at vi har mappet de fire nivåene beskrevet over mot de følgende leverandørene av infrastruktur:
Livsviktig -> On-prem
Kritisk for kjernefunksjonalitet -> Europeisk cloud
Kan leve uten -> Azure
Det er da ikke slik at alle funksjoner og assets må hostes hos en europeisk skyleverandør, fordi man kan gjerne hoste de on-prem, for eksempel, hvis det er gode argumenter for det. Derimot kan man ikke hoste det på Azure uansett hvor gode argumentene er.
Er det slik at det gjør for vondt å ikke hoste det på Azure er det en indikasjon på at den funksjonen eller asseten er plassert på feil nivå, eller at mappingen mellom nivået og leverandørene har mangler.
For å konkludere
Vi har vært innom flere konsepter som kan oppleves som både komplekse og abstrakte.
I håpet om å binde det hele sammen har jeg under laget en enkel, illustrativ oversikt over ressurser og funksjoner i en tenkt webshop:
Oversikten er ikke uttømmende, men den gir et tilstrekkelig grunnlag for å visualisere arkitekturen og prinsippene vi har diskutert.
Dersom du ønsker en dypere gjennomgang eller har spørsmål, er du hjertelig velkommen til å ta kontakt eller legge igjen en kommentar.
