Arkitektur og teknologi

Leveransemodeller

Leveransemodeller definerer hvor infrastrukturen befinner seg, hvordan den deles, hvem som eier den og hvem som er driftsansvarlig. Det finnes fire leveransemodeller for skytjenester; allmenn, privat, hybrid og multisky. Markedsplassen for skytjenester benytter definisjonene angitt NIST Cyber Security Framework v.1.1 (NIST CSF).

Allmenn sky

I allmenn sky er det skyleverandøren som eier infrastrukturen. Det er de som er ansvarlig for driften og ressursene deles mellom flere kunder. Denne modellen er best egnet for prosjekter uten eksisterende infrastruktur, utvikling, testing, rask skalering, standard arbeidslaster som databaser og web-applikasjoner. Dersom du har arbeidslaster med strenge krav til latens, sensitiv data og maskinvare så kan de andre modellene være mer egnet for dette.

Dersom du tar i bruk allmenn sky, er det viktig at du klassifiserer data og velger riktig region for lagring. Du må implementere tilgangsstyring og sikre at avtaler om databehandling er på plass. Det lønner seg å sette seg inn i prismodellene til skyleverandøren. Normalt sett betaler du kun for det du bruker, men leverandørene tilbyr som regel oppsparingsplaner hvor du reserverer eller forplikter deg til ressurser mot lavere priser.

Fordeler:

• Ingen behov for å investere i maskinvare, dermed ingen kapitalkostnader
• Mulighet for å skalere opp og ned etter behov
• Raskt å etablere ettersom ressurser er tilgjengelig på noen minutter
• Leverandør har ansvar for drift av underliggende infrastruktur og oppdatering av plattformen
• Tilgang til global infrastruktur med datasentre i flere deler av verden

Ulemper:

• Du kan ikke endre underliggende infrastruktur og har derfor mindre kontroll
• Du må dele ressurser med andre kunder
• Du er avhengig av internett for tilkobling til ressurser
• Du må forsikre deg om at plassering av data er i henhold til regulatoriske krav

Privat sky

Privat sky innebærer at infrastrukturen er dedikert til kun én virksomhet. Det vil si at den deles ikke med andre kunder som det gjøres i allmenn sky. Infrastrukturen kan være lokalt hos dere eller hos en leverandør. Hvis infrastrukturen ligger hos dere, er det dere som eier og drifter datasenteret, men dersom dette leveres av en leverandør er det de som er ansvarlig.

Denne modellen er egnet for virksomheter som har strenge regulatoriske krav, behov for spesifikk maskinvare og sensitiv data som ikke kan forlate organisasjonen. Den er mindre egnet for virksomheter med behov for rask innovasjon og nye teknologier.

Fordeler:

• Dere har full kontroll på infrastrukturen
• Dedikerte ressurser som betyr at de ikke deles med andre
• Data kan bli liggende lokalt dersom det er ønskelig
• Enklere å møte strenge regulatoriske krav for databehandling

Ulemper:

• Du må investere i maskinvare. Du kan gå til innkjøp av det selv eller leie det hos en leverandør, men det blir likevel en høy kapitalkostnad
• Det er dere som er ansvarlig for driften (selv om driften kan leveres av leverandør eller tredjepart)
• Muligheten til å skalere er begrenset av den fysiske kapasiteten
• Lengre tid å etablere ettersom utstyret må anskaffes og installeres

Hybrid sky

Hybrid sky er en kombinasjon av allmenn og privat sky. Data og applikasjoner deles mellom miljøene, og de orkestreres på tvers for sømløs bevegelse av arbeidslaster. Når du implementerer hybrid sky, innebærer det at du har et eksisterende datasenter i kombinasjon med en eller flere skytjenester, med tilkobling via VPN(Virtual Private Network - sikker tilkobling fra annet nettverk) eller en dedikert link. Denne modellen er best egnet for systemer som må forbli lokalt, har krav om datasuverenitet for enkelte datatyper eller virksomheter med store eksisterende investeringer.

Fordeler:

• Muligheten til å velge miljøet som passer best for arbeidslasten
• Du kan migrere til sky i eget tempo
• Du kan beholde sensitiv data lokalt
• Du får både kontroll og skalerbarhet

Ulemper:

• Komplekst å administrere
• Krever god forbindelse og arkitektur
• Påvirker sikkerheten ettersom det blir flere angrepsflater
• Risiko for inkonsistente data hvis replikeringen ikke fungerer optimalt
• Både kapital- og driftskostnader
• Krever kompetanse på begge miljøer

Hybrid sky er en kombinasjon av lokalt datasenter og et skymiljø. Det gjør at du kan ha et midlertidig hybrid miljø i det du gradvis migrerer tjenester til et skymiljø, men du kan også ha en permanent hybridløsning hvor enkelte systemer må forbli lokalt. Grunnen til at enkelte systemer må forbli lokalt kan være regulatoriske krav, spesifikke integrasjoner eller eldre systemer som ikke er egnet til å kjøre i et skymiljø.

Multisky

Multisky må ikke forveksles med hybrid sky. Multisky innebærer å ta i bruk flere skyleverandører, hvor hybrid sky bruker både allmenn og privat sky. I et miljø som benytter seg av denne modellen så må arkitekturen designes for å distribuere arbeidslasten. Du kan ha en ustrukturert multisky, hvor forskjellige team velger forskjellige leverandører og det ikke er noe form for sentral styring. Eller du kan ha en strukturert multisky hvor det blir tatt en strategisk beslutning om å bruke flere leverandører og det er klare kriterier for hva som skal kjøre hvor, med sentral styring.

En primærleverandør eller multisky

En av de første strategiske beslutningene er om din virksomhet skal ha en primær skyleverandør eller flere. Begge valgene har betydelige konsekvenser for kompleksitet, fleksibilitet og kostnader. Å ha en primærleverandør vil si at mesteparten av arbeidslastene og tjenestene skal kjøre hos denne leverandøren, mens andre brukes for spesifikke behov.

Fordeler med en primærleverandør:

• Enklere drift og forvaltning:
  • Ett sett med tjenester å mestre
  • Alt i en portal eller et grensesnitt
  • Mindre kompleksitet i nettverksoppsett
• Dypere kompetanse:
  • Enklere å bli eksperter på en plattform
  • Problemløsning kan være raskere
  • Bedre utnyttelse av tjenester som er spesifikt for leverandøren
• Lavere kostnader:
  • Mindre behov for verktøy som er uavhengig av plattform
  • Mindre behov for lisenser

Ulemper med en primærleverandør:

• Leverandøravhengighet
  • Utfordrende å bytte leverandør senere
  • Sårbar for leverandørens prisøkninger
• Enkeltpunkt for feil
  • Hvis leverandøren har nedetid påvirker det hele virksomheten
  • Strømbrudd kan ramme alle tjenester
• Begrenset tilgang til best rangerte tjeneste
  • Hvis en annen leverandør tilbyr bedre tjenester basert på en teknologi, er det utfordrende å benytte seg av det

Dersom din virksomhet er i oppstartsfasen med skybruk, har begrenset kapasitet innen IT, ønsker å bygge kompetanse raskt eller har en leverandør som dekker mesteparten av behovene, er det anbefalt å kun ha en primærleverandør.

Multisky vil si at du bruker flere skyleverandører aktivt. Arbeidslaster og tjenester fordeles jevnt basert på hvor de er best egnet.

Fordeler med multisky:

• Bruke hver leverandør til det de briljerer på
• Resiliens:
  • Hvis en leverandør har problemer, så kan du bruke en annen
  • Geografisk spredning

Ulemper med multisky:

• Økt kompleksitet:
  • Flere portaler og konsoller
  • Kompleks nettverksarkitektur
  • Utfordrende å feilsøke på tvers
• Høyere kostnad ettersom det blir flere lisenser for samme type tjenester
• Kompetanseutfordringer:
  • Teamene må lære seg flere plattformer
  • Vanskelig å oppnå ekspertise på tvers
  • Kompetanseutviklingen koster mer

Det lønner seg å ha flere leverandører når du har betydelig IT-kapasitet, spesifikke behov som kun en leverandør dekker godt, regulatoriske krav til redundans eller ønske om å unngå leverandøravhengighet.

Arkitekturmønstre for hybridmiljø

1. Nettverkstilkobling

For å etablere sikker forbindelse mellom lokalt datasenter og skyinfrastruktur, kan du sette opp en Site-to-Site VPN og/eller en dedikert forbindelse. En Site-to-Site VPN tilkobling gir deg en kryptert tunnel som går over internett og er enkel å sette opp. Ulempen med dette er at båndbredden kan variere, men dersom datatrafikken har middels til lavt volum er dette som regel tilstrekkelig.

En dedikert forbindelse er en privat og dedikert link. Den har høy båndbredde, lav latens og er mer sikker. Den har også høyere kostnad og tar lengre tid å sette opp. Den er mest egnet for høyt volum av datatrafikk og kritiske integrasjoner.

Det er også mulig å ha en dedikert forbindelse som primærkobling og VPN for redundans.

Prinsipper innenfor design av nettverkstilkoblingen er følgende:

• Ikke overlappe IP-adresserom mellom lokal datasenter og i skyinfrastrukturen
• Bruk private IP-adresser for intern kommunikasjon
• Implementer regler for ruting
• Overvåk båndbredden og latens

2. Datasynkronisering

Dersom både det lokale datasenteret og skyinfrastrukturen har lagring, er det viktig å holde dataen i disse konsistent. Du kan ta i bruk tjenester som databasereplikering, filsynkronisering eller hendelsesynkronisering. Du kan også bruke ETL/ELT dersom du har datavarehus eller data innen analyse.

For datasynkronisering er det viktig å angi en hovedkilde for dataen, unngå synkronisering i begge retninger der det er mulig og overvåke synkroniseringen.

3. Identitet og tilgangsstyring

Det bør være et felles identitetssystem på tvers av miljøene. Bruk Single Sign-on (SSO) til både applikasjoner og tjenester fra begge miljøene, i tillegg til gruppemedlemskap, retningslinjer og brukersynkronisering. Fordelen er sentralisert brukeradministrasjon, tilgangsstyring og at brukere trenger kun en identitet.

4. Applikasjonsintegrasjon

Applikasjoner må kunne kommunisere på tvers av miljøene. Du kan ta i bruk API Gateway som gir et sentralt punkt for sikkerhet og logging. Lokale systemer eksponerer API og applikasjoner i skymiljøet kommuniserer med dem via API Gateway.

Tjenester som Message Queue og Event Bus kan også brukes til dette formålet. Lokale systemer publiserer meldinger til en skybasert kø slik at applikasjonen i skymiljøet får lest dem. Denne kommunikasjonen er asynkron.

5. Plassering av hybrid arbeidslast

Arbeidslasten må ha en hensiktsmessig plassering.

Kriterier for plassering lokalt:

• Eldre systemer er vanskelige å migrere
• Ønskelig med lav latens til andre lokale systemer
• Spesielle krav til maskinvare
• Regulatoriske krav

Kriterier for plassering i sky:

• Nye applikasjoner
• Arbeidslaster med varierende belastning
• Behov for skalering
• Globale brukere

Uavhengig av hvor arbeidslasten plasseres, bør du ha en exit-strategi på plass. Følgende burde være definert i strategien:

• Dataekstraksjon:
  • Hvordan får vi ut data?
  • I hvilket format?
  • Hvor lang tid tar det?
  • Hva koster det å få ut data?
• Migrering av applikasjoner:
  • Hvilke komponenter og funksjoner må skrives om?
  • Hvor lang tid og hvor mye innsats kreves?
• Nettverkstilkobling:
  • Hvordan kobler vi ny leverandør til eksisterende miljø?
• Tidslinje:
  • Hvor raskt kan vi bytte hvis det skulle være nødvendig?

Arkitekturprinsipper for skytjenester

Skyutviklede tjenester er mer enn et verktøy for å flytte applikasjoner. De er designet for å utnytte skyplattformens fulle potensiale.

Cloud-native er teknologier som er optimaliserte for skyen. De gjør det mulig for virksomheter å bygge skalerbare applikasjoner i moderne miljøer som allmenne, private og hybride skyer. Teknologier som kontainere, mikrotjenester og autoskalering er eksempler på denne tilnærmingen.

I tradisjonell arkitektur er det ofte sammenhengende applikasjoner som kjøres. Disse skal være stabile og kjøres på servere som brukes i lang tid. En stor applikasjon som kjører alt i en prosess er utfordrende å skalere, har lav feiltoleranse og hele applikasjonen må utrulles ved en endring eller oppdatering.

Arkitektur basert på mikrotjenester kan kjøre hver tjeneste uavhengig, skalere separat og utrulle kun de tjenestene som er endret. Hver tjeneste kjører i sin egen prosess og kommuniserer gjennom enkle mekanismer. Dette gjør at du kan ha raskere leveranser, uavhengig utrulling av tjenester og mindre risiko per utrulling.

Mikrotjenester er mest egnet for flere team som jobber på samme system, behov for uavhengig skalering av produkter, kontinuerlig utvikling og komplekse applikasjoner. De er ikke egnet for enkle applikasjoner, små team eller for en virksomhet som ikke benytter seg av DevOps metodikk.

Serverless og skalering

Skyleverandørene tilbyr tjenester som ikke trenger servere for å kunne kjøre kode. Disse er kjent som "Serverless" eller FaaS (Function as a service), som AWS Lambda, Google Cloud Functions og IBM Cloud Functions. Med tradisjonelle servere betaler du for oppetid, mens med serverless betaler du kun når tjenesten faktisk brukes. I tjenesten konfigurerer du funksjoner som inneholder koder og disse funksjonene kjører kun når de er trigget av en betingelse eller hendelse.

Med en slik tilnærming, kan du fokusere på koden og trenger ikke å tenke på infrastrukturen. Det er også automatisk skalering i slike tjenester, men de har også sine ulemper. Første forespørsel etter inaktivitet kan være treg, den er derfor ikke egnet for applikasjoner som er kritiske for lav ventetid. I tillegg kan Serverless bli dyrt ved høy eller konstant belastning og er mindre forutsigbart enn dedikerte servere. Serverless er primært egnet for arbeidslast som er basert på hendelser, mikrotjenester med lavt volum, planlagte småjobber og integrasjoner.

En av de største fordelene med skytjenester er evnen til å skalere ressurser opp og ned automatisk basert på behov, men tjenestene og applikasjonene må designes for å utnytte dette. Målet er å kunne håndtere både høy og lav trafikkmengde uten at ytelsen blir degradert. Tjenestene skal også kunne opprettholde tilgjengeligheten ved å erstatte feilende instanser. Det finnes to typer skalering, vertikal og horisontal.

Vertikal skalering

Vertikal skalering går ut på å endre størrelsen på eksisterende ressurs, for eksempel økt minne eller antall prosessor. Fordelen med dette er at det ikke krever endringer i arkitekturen, og det fungerer for de fleste applikasjonene. Ulempen er at det er fysiske grenser for hvor mye du kan øke størrelsen og det kan ofte kreve en restart av ressursen.

Horisontal skalering

Horisontal skalering handler om å legge til eller fjerne instanser, for eksempel det å gå fra to servere til fem. Fordelen med en slik skalering er en nesten ubegrenset med skalering, høy tilgjengelighet, redundans og som regel ingen nedetid ved skalering. Ulempen er at arkitekturen blir mer kompleks og det er behov for lastbalansering.

Infrastruktur som kode

Når infrastrukturen blir konfigurert manuelt, er sjansen for feil og inkonsistens høy. Infrastruktur som kode behandler konfigurasjonen som om det er en applikasjon som bygges. Koden for infrastrukturen blir versjonert, testet og automatisert.

Tradisjonelt	Infrastruktur som kode
1. Finn ressurstype og velg å opprette denne	1. Skriv infrastrukturen i kode
2. Velg størrelse, nettverk og lagring	2. Send koden til Git for versjonering
3. Gjenta for hver ressurs som skal opprettes	3. Kjør automatisk utrulling
4. Dokumenter ressursinformasjon og steg	4. Få identisk infrastruktur hver gang

Fordelen med infrastruktur som kode er at du får en infrastruktur som er konsistent, versjonert, lett å replikere til andre miljøer og oversiktlig. Selve koden blir også en form for dokumentasjon.

Eksempler på verktøy for infrastruktur som kode:

• Terraform - kan brukes for flere skyplattformer
• CloudFormation - AWS
• Deployment Manager - Google Cloud

Integrasjon mellom sky og lokalt miljø

I et hybridmiljø er selve integrasjonen mellom sky og lokalt miljø avgjørende for stabil drift. Det handler ikke bare om nettverksforbindelser, men om hvordan data flyter, hvordan tjenester kommuniserer, og hvordan endringer håndteres på tvers av plattformer. For å ha en robust og skalerbar løsning må integrasjonen ta i bruk tjenester for kommunikasjon, synkronisering og behandling av meldinger.

API Gateway

API Gateway er en sentral inngangsport for alle API kall. Den håndterer ruting og autentisering. Arkitekturen kan se slik ut:

Applikasjon i skyen

↓

API Gateway i skyen

↓

VPN tilkobling

↓

Lokal tjeneste

API Gateway gir sentralisert sikkerhet ettersom autentisering og autorisasjon er samlet på et sted. Du kan også beskytte applikasjonen mot overbelastning.

Eksempler på API Gateway tjenester kan være AWS API Gateway, Google Cloud API Gateway, Oracle API Gateway og IBM API Connect.

Message Queue

Message Queue er en tjeneste som tar i bruk asynkron kommunikasjon ved hjelp av køer. En melding blir sendt til applikasjonen fra ene siden og havner i en kø. Så blir meldingen lest fra køen av mottakeren når det er klart. Overordnet ser arkitekturen slik ut:

Applikasjon i skyen

↓

Message Queue

↓

Lokal tjeneste

Fordelen med denne metoden er at applikasjonen som kjører i skyen trenger ikke å vente på svar, ettersom den lokale tjenesten prosesserer kommunikasjonen i sitt eget tempo. Dette gir raskere respons til brukeren. Hvis mottakeren av kommunikasjonen er nede lagres meldinger i kø og dermed blir det ingen tap av data.

Eksempler på Message queue tjenester kan være AWS SQS/SNS, Google Cloud Pub/Sub, Oracle Cloud Infrastructure Queue og IBM MQ.

Hendelsesdrevet system

Disse type tjenestene kommuniserer via hendelser. En produsent publiserer hendelsen når noe skjer, og dette blir synlig for applikasjonene og systemene som har abonnert på det.

Applikasjon i skyen publiserer en hendelse

↓

Hendelsesbuss

↓

Abonnent 1: skytjeneste Abonnent 2: lokalt system Abonnent 3: annen skytjeneste

Eksempler på hendelsesdrevne systemer: AWS EventBridge, Google Cloud Eventarc.

Databasereplikering

Databasereplikering handler om å replikere data mellom lokale- og skymiljøer. Replikeringen kan være synkront eller asynkront. Formålet med dette er å fange endringer og synkronisere disse underveis med minimal påvirkning på kilden, som kan være lokal eller i et skymiljø. Du kan ha enveis synkronisering hvor alle skrivehandlinger i primærdatabasen blir synkronisert til en sekundærdatabase, eventuelt en toveis synkronisering hvor endringer i begge databaser blir synkronisert på tvers. Utfordringen med toveis synkroniseringen er at det kan oppstå konflikter når det synkroniseres, så det kreves kompleks konflikthåndtering.

Eksempler på tjenester innen databasereplikering: AWS DMS (Database Migration Service), Oracle GoldenGate.

Nettverksarkitektur og tilkobling

Design av virtuelt nettverk

Virtuelle nettverk er fundamentet for nettverksarkitektur i sky. De gir deg muligheten til å isolere ressurser, strukturere ressurser og få kontroll på IP adresser. Et virtuelt nettverk er et logisk isolert nettverk hvor du kan koble sammen ressurser, kontrollere tilgang og definere eget IP-adresserom. Det er viktig å passe på at IP-adresserommet ikke overlapper, det vil si at det kan ikke være like IP-adresser lokalt eller i det virtuelle nettverket.

Subnet er en logisk gruppering av ressurser. Subnet deler opp det virtuelle nettverket i flere IP-adresserom, slik at du får sikkerhetssegmentering. Hvert subnet har et eget IP-adresserom som er basert på det virtuelle nettverket, og kan bidra til bedre ruting mellom hverandre og mellom andre virtuelle nettverk.

Ruting bestemmer hvor nettverkstrafikken skal gå. Du kan enten benytte deg av en standard ruting eller opprette en egen, også kalt UDR (User-defined route table). Ved å ta i bruk UDR kan du tvinge trafikk til å gå til et bestemt sted, som for eksempel en brannmur eller en annen sikkerhetstjeneste. Du kan bestemme ruter basert på IP-adresserom, noe som gjør at du kan bestemme hvilken type trafikk som skal hvor. Du kan for eksempel konfigurere at trafikk som skal til lokale nettverk går til VPN gateway og det som skal til internett skal gå gjennom en brannmur først.

Hub-and-spoke arkitektur

En Hub-and-spoke arkitektur innebærer at et virtuelt nettverk er dedikert for sentraliserte tjenester som brannmur, VPN gateway og DNS, og disse deles av andre virtuelle nettverk. Dette sparer du kostnader på ettersom du ikke trenger å implementere disse tjenestene for flere virtuelle nettverk. Det er ikke et fullt mesh-nettverk, det vil si at andre nettverk er ikke koblet direkte med hverandre, ettersom all trafikk skal gjennom hub-nettverket.

Tilkobling for hybrid sky

Nettverksforbindelse er essensielt for hybrid sky. Du kan ta i bruk VPN over internett eller dedikerte private forbindelser for å koble nettverk i sky med det lokale nettverket.

Site-to-Site VPN er en kryptert tunnel som går over offentlig internett. Den kan koble til lokale nettverk med nettverk i skymiljø. Den bruker eksisterende internettforbindelse og fungerer med eksisterende brannmur og ruter.

Lokal nettverk

↓

VPN Gateway

↓

Internett

↓

VPN Gateway i sky

↓

Virtuelt nettverk i sky

Site-to-Site VPN tjenester fra skyleverandørene:

• AWS: AWS Site-to-Site VPN
• Google Cloud: Cloud VPN
• Oracle Cloud: IPSec VPN Connect
• IBM Cloud: IBM Cloud VPN for VPC

Alternativt kan du bruke en dedikert privat forbindelse. Dette er en privat forbindelse som ikke går over internett.

Lokal nettverk

↓

Lokal ruter

↓

Krysskobling i datasenteret

↓

Skyleverandørens Edge ruter

↓

Virtuelt nettverk i sky

Fordelen med dedikert privat forbindelse er høy båndbredde og mindre angrepsflate, ettersom forbindelsen ikke deles med andre. Ulempen er at det er en høy kostnad for dette og at det tar mye lengre tid for implementasjon. Denne forbindelsen krever fysisk infrastruktur som må etableres og krever samarbeid med flere parter.

Dedikerte forbindelser fra skyleverandørene:

• AWS: AWS Direct Connect
• Google Cloud: Dedicated Interconnect/Partner Interconnect
• Oracle Cloud: Oracle FastConnect
• IBM Cloud: IBM Cloud Direct Link

Migreringsstrategier

Migrering til sky handler ikke kun om å flytte ressurser. Det handler om å evaluere tilnærming basert på applikasjonenes egenskaper og forretningsbehov. Du må velge riktig strategi for hver ressurs, basert på kompleksitet, risiko og gevinst.

Vi har her brukt Gartner som eksempel på hvordan man kan definere en strategi for skymigrering, hvor hver strategi representerer forskjellige tilnærminger med ulike nivåer av innsats, risiko og gevinst. Du må vurdere hver applikasjon og tjeneste individuelt og velge riktig strategi.

Strategi	Innsats	Risiko	Gevinst	Bruk
Avvikle	Minimal	Lav	Høy	Systemer som ikke lenger er i bruk
Beholde	Ingen	Ingen	Ingen	Systemer som ikke er klare for migrering
Flytte	Lav	Lav	Middels	Rask migrering, minimal endring
Relokalisere	Lav	Lav	Middels	Virtualiseringsløsninger som skal migreres
Erstatte	Middels	Middels	Høy	Erstatte eksisterende løsning med SaaS
Optimalisere	Middels	Middels	Høy	Utføre optimaliseringer under migreres
Ombygge	Høy	Høy	Høy	Full utnyttelse av skytjenester

Avvikle

Identifiser og slett applikasjoner og tjenester som ikke lenger brukes. Dette reduserer kompleksiteten og gjør at du kan fokusere på de viktigste systemene. Du kan stille følgende kontrollspørsmål for å identifisere ressurser som bør fjernes:

• Når ble systemet sist brukt?
• Er det noen som bruker det?
• Er det forretningskritisk?
• Finnes funksjonen eller tjenesten i andre systemer?
• Hva koster det å beholde det, eventuelt slette det?

Beholde

Beslutningen om å ikke migrere kan skyldes eldre systemer med høy kompleksitet eller risiko ved migrering. Kompleksiteten kan komme av applikasjonsavhengigheter eller maskinvare. Det kan også være at systemet skal erstattes i nær fremtid eller at virksomheten har et begrenset budsjett som gjør at andre systemer må prioriteres.

Denne strategien kan være både midlertidig og permanent. Midlertidig er egnet hvis systemet skal migreres senere, permanent hvis det ikke ser ut til å være aktuelt med en migrering. Det er viktig å ikke la denne strategien være en unnskyldning for å unngå endring. Dokumenter tydelig hvorfor systemet skal beholdes.

Flytte

Denne strategien innebærer å migrere ressurser til skyen uten å gjøre endringer. Denne migreringen er fra virtuell maskin til virtuell maskin, med samme operativsystem og konfigurasjon. Fordelen er at dette er den raskeste migreringsmetoden og innebærer lav risiko. Det er minimale endringer og testingen er relativt enkel. Ulempen er at den utnytter ikke skyens fulle potensiale og har de samme begrensningene som du har lokalt.

Dersom du har mange servere som må migreres raskt eller må flytte ressurser ut fra datasenter så raskt som mulig, er denne strategien velegnet.

Relokalisere

Samme strategi som flytte-metoden, men for virtualiseringsmiljøer. Den går ut på å flytte lokale virtualiseringsmiljøer og plattformer til tjenester innen virtualisering i sky. Et eksempel på dette er VMware som brukes av mange virksomheter. Skyleverandørene tilbyr blant annet følgende tjenester for VMware:

• VMware on AWS
• Google Cloud VMware Engine
• Oracle Cloud VMware Solution
• IBM Cloud for VMware Solutions

Fordelen er at du kan bruke samme verktøy og prosesser med den eksisterende kompetansen. Ulempen er at dette ofte er dyrere enn andre skytjenester. Denne strategien lønner seg dersom dere har gjort betydelige VMware investeringer og har dyp kompetanse på denne teknologien. Kan også egne seg som en midlertidig løsning, men dersom dere har en langsiktig strategi, fokus på kostnadsoptimalisering og mål om å modernisere tjenester så er denne strategien ikke anbefalt.

Erstatte

Denne strategien går ut på å erstatte eksisterende applikasjoner med en hyllevare (SaaS). Det kan være å gå til anskaffelse av en e-posttjeneste i stedet for å drifte en egen. Det finnes en rekke tjenester innen e-post, CRM, ERP, filserver og kommunikasjon som kan tas i bruk. Leverandøren har ansvaret for drift, sikkerhet og infrastruktur for tjenesten. Det er som regel en rask implementasjon av tjenesten og kostnaden er basert på antall brukere. Ulempen er at fleksibiliteten er mindre og du må tilpasse deg prosessene til tjenesten. Disse tjenestene har en abonnementsmodell og kan være dyrere på lang sikt. Dersom data lagres utenfor Norge, kan det oppstå utfordringer med krav og reguleringer.

Optimalisere

Denne strategien innebærer å migrere med enkelte optimaliseringer. Dette krever ikke en ny design av applikasjonen, kun mindre justeringer for å flytte til en tilsvarende tjeneste hos skyleverandøren. Det kan være å flytte til en plattformtjeneste som innebærer små endringer for å kunne være kompatibel. Du endrer enten ingenting eller minimalt på applikasjonskoden og arkitekturen.

Dette gir tjenesten mer tilgjengelighet, kostnadsbesparelser, og mulighet for automatisk sikkerhetskopiering. Denne tilnærmingen kan kreve mer innsats enn en ren flytting av applikasjonen. Du må teste integrasjoner, gjøre enkelte endringer i koden og håndtere en mer kompleks migrering. Strategien egner seg for forretningskritiske systemer og applikasjoner med omfattende bruk av databaser. Den er også relevant for systemer med behov for lagring av filer.

Ombygge

Dette innebærer å designe applikasjonen for skyen. Du tar i bruk tjenester og arkitektur i skyen som mikrotjenester, kontainere og serverless. Dette gir deg maksimal utnyttelse av mulighetene i sky.

Denne tilnærmingen krever omfattende endringer i applikasjonskoden. Du tar i bruk moderne rammeverk og går fra manuelle til automatiserte utrullinger. Resultatet er optimal kostnadeffektivitet, skalerbarhet og tilgjengelighet, i tillegg til økt innovasjonsevne. Ulempen er at dette medfører lengre utviklingstid og behov for spisskompetanse. Det kan også innebære betydelige utviklingskostnader. Dersom du har applikasjoner som er strategisk viktige, globale, eller har høy endringstakt, så er denne strategien godt egnet.