Arkitektur og teknologi for skytjenester

Valgene man tar rundt arkitektur og teknologi fungerer som virksomhetens digitale ryggrad. En gjennomtenkt arkitektur sikrer at applikasjoner kan snakke sammen, at data flyter trygt mellom ulike miljøer, og at din virksomhet unngår unødvendig kompleksitet som kan føre til økte kostnader og sikkerhetshull.

Cloud og Cloud-native: Hva er forskjellen?

Et av de viktigste konseptene å forstå er skillet mellom å være i skyen og det å ta bruk tjenester som er designet spesifikt for skyen. Cloud (Sky-basert) betyr ofte at man har flyttet eksisterende systemer fra egne servere til en skyleverandør (også kjent som lift-and-shift). Man drar nytte av at andre drifter maskinvaren, men applikasjonen fungerer i stor grad som før. Cloud-native (Sky-optimalisert) handler om hvordan applikasjonen er bygget. En cloud-native løsning er designet spesifikt for å utnytte skyens unike egenskaper, som automatisk skalering, selvhelbredelse og hyppige oppdateringer. Ved å bruke teknologier som containere og mikrotjenester, oppnår man en langt høyere grad av fleksibilitet og redundans.

Valg av leveransemodell

Det første steget i den tekniske planleggingen er å velge riktig leveransemodell. Dette valget styres av virksomhetens behov for kontroll, regulatoriske krav og innovasjon. Vi skiller mellom fire hovedmodeller:

Modell	Beskrivelse	Passer best for
Allmenn sky	Leverandøren (AWS, Google, Oracle eller IBM) eier og drifter alt.	Rask innovasjon, skalering og standardiserte applikasjoner.
Privat sky	Dedikert infrastruktur for din virksomhet. Kan driftes hos leverandør eller i eget datasenter.	Strenge regulatoriske krav og svært sensitive data.
Hybrid sky	Kombinasjon av ulike miljøer. Dersom du har både lokale servere (on-premise) og allmenn eller privat sky, er dette en hybrid modell.	Gradvis migrering eller systemer som må forbli lokale.
Multisky	Bruk av flere skyleverandører samtidig for å løse ulike oppgaver.	Redusere leverandøravhengighet og øke redundans.

Delt ansvarsmodell

En av de vanligste fallgruvene i en skyreise er antakelsen om at skyleverandøren overtar alt ansvar for sikkerhet og drift idet man flytter ut av eget datasenter. For at arkitekturen skal være robust, må virksomheten ha et klart forhold til den delte ansvarsmodellen. Det handler om å forstå grensesnittet mellom leverandørens plikter og virksomhetens egne oppgaver.

Hvor denne grensen går i praksis, avhenger av om man velger å leie maskinkraft (IaaS), plattformer for utvikling (PaaS) eller ferdige programvaretjenester (SaaS). Uansett modell vil ansvaret for selve informasjonen og dataene alltid ligge hos virksomheten selv.

Tekniske nøkkelbegreper

For å velge riktig arkitektur, må man vurdere flere tekniske faktorer som påvirker brukeropplevelsen og driften:

• Arbeidslast (Workload): Hvilken type oppgave skal løses? En tung database krever andre ressurser enn en enkel nettside.
• Forsinkelse (Latency): Tiden det tar for data å reise fra brukeren til serveren og tilbake. Ved tidskritiske tjenester må arkitekturen plassere ressursene geografisk nær brukeren.
• Virtualisering og containere: Virtualisering gjør det mulig å kjøre mange maskiner på en fysisk server. Containere tar dette et steg videre ved å pakke applikasjonen og alt den trenger i en lettvektig enhet som kan kjøres hvor som helst.
• Multi-tenant og single-tenant: I en multi-tenant modell deler du ressurser med andre, noe som er billigere. I en single-tenant modell trenger du ikke å dele ressurser, noe som gir mer kontroll men til en høyere pris.

Moderne arkitekturprinsipper

For å utnytte skyens fulle potensial, må vi gå bort fra tradisjonelle servere til fordel for cloud-native teknologier:

• Mikrotjenester: Ved å dele opp store applikasjoner i mindre, uavhengige deler, kan vi oppdatere en funksjon uten å påvirke hele systemet
• Serverless: Du betaler kun når koden faktisk kjører. Dette fjerner behovet for å administrere servere og gir automatisk skalering.
• Infrastruktur som kode (IaC): All konfigurasjon skrives som kode. Dette sikrer at miljøene er identiske, versjonerte og fri for manuelle feil.
• Horisontal skalering: Istedenfor å gjøre en server større, legger vi til flere instanser. Dette sikrer høy tilgjengelighet og redundans.

Hybrid integrasjon og trygg dataflyt

I et hybridmiljø er koblingen mellom det lokale datasenteret og skyen avgjørende. En robust integrasjon krever fokus på fire områder:

1. Nettverk: Valget mellom kryptert VPN over internett eller en dedikert forbindelse.
2. Identitet: Et felles identitetssystem sørger for at brukere kun trenger en pålogging for begge miljøer.
3. Data: Bruk av databasereplikering og synkronisering for å sikre at informasjonen er konsistent på tvers av plattformer.
4. Applikasjoner: Bruk av API Gateway eller Message Queue for sikker og asynkron kommunikasjon mellom lokale systemer og skymiljøet.

Veien til skyen: migreringsstrategier

Ikke alle applikasjoner skal flyttes på samme måte. Basert på Gartners modell for migrering må du vurdere hver tjeneste individuelt for å finne den optimale strategien.

Strategi	Innsats	Gevinst	Når velger du denne?
Avvikle	Minimal	Høy	Systemet er utdatert eller brukes ikke lenger
Beholde	Ingen	Ingen	Systemer med for høy risiko eller kompleksitet for flytting
Flytte	Lav	Middels	Behov for rask migrering med minimale endringer (Lift-and-shift)
Erstatte	Middels	Høy	Når det finnes en ferdig hyllevare (SaaS) som dekker behovet bedre.
Optimalisere	Middels	Høy	Når små justeringer lar deg utnytte plattformtjenester (PaaS)
Ombygge	Høy	Høy	Strategisk viktige systemer som designes helt på nytt for skyen

Veien videre: hvordan gå frem?

Når prinsippene innen arkitektur er forstått, handler det om å operasjonalisere dem. En god arkitektur skal fungere som en veiledning for tekniske valg i hverdagen.

For å sikre en strukturert overgang anbefaler vi følgende steg:

• Gjør en analyse av porteføljen: Bruk migreringsmatrisen over for å kategorisere eksisterende applikasjoner.
• Etabler en landingssone: Sett opp det virtuelle nettverket, sikkerhetsregler og identitetsstyring før de første arbeidslastene flyttes.
• Sørg for en exit-strategi: Definer hvordan data kan hentes ut og flyttes igjen, for å unngå uønsket leverandørlåsning.
• Bruk tilgjengelig veiledningsmateriell: Arkitektur og teknologi kan blant annet leses for å få mer innføring i ulike leveransemodeller for skytjenester og arkitekturprinsipper med mer.