På tide å skru av serverne nå?
Tradisjonelle, fysiske servere fases ut, og skyen står klar til å ta over. Men er skybaserte løsninger alltid en trygg vei til bedre effektivitet og lavere kostnader? Bedrifter møter nye utfordringer når applikasjoner flyttes til skyen, med uvante prismodeller, funksjonalitet som endrer seg, og historikk som kan gå tapt. Hvordan kan din bedrift sikre en vellykket overgang i et landskap der teknologi og strategi må gå hånd i hånd? (AI-generert ingress med artikkelen som input)
Beslutningen er tatt.
OK - så er beslutningen tatt. De siste fysiske serverne som trofast har levert applikasjoner og tjenester til de ansatte skal fases ut. Alt skal opp i "skyen".
Eller er det kanskje den lokale driftsleverandøren som ikke henger med i tiden, og dermed må gi tapt for tjenester levert fra de de store skalerbare Public Clouds.
Din første innskytelse er kanskje at dette har vel alle gjort allerede? Og har ikke alle programvareleverandører flyttet applikasjonene til skyen for lenge siden?
Det er f.eks over 10 år siden Office 365 ble lansert som en abonnementstjeneste basert på Microsofts offentlige sky for personlig effektivitet - OneDrive. Og siden har skymigrering og skytjenester vært på alles lepper og alles agenda.
Joda, konvertering til abonnementsbaserte applikasjoner og lagringstjenester har kommet svært langt, og mer enn 80% av større bedrifter sier de har en "Cloud first" strategi for IT anskaffelser. Det betyr at man vurderer en løsning i en Public Cloud som mest sannsynlig for den neste investeringen i en IT-basert tjeneste. Så lang er alt OK.
Men jobben med å konvertere er definitivt ikke helt ferdig ennå. og uansett motivasjon og begrunnelse for å gå "as a service" så er det en rekke faktorer man må ha kontroll på.
Utfordringer
Utfordringene kommer ofte i det øyeblikket organisasjonen starter evalueringen av de nye tjenestene som skal erstatte de klassiske applikasjonene som var installert på organisasjonens egne servere, eller var installert hos den lokale driftsleverandøren.
Landskapet som de IT-ansvarlige i den aktuelle organisasjonen skal bevege seg i er ganske annerledes i skyen. De mest framtredende forskjellene skapes - etter min erfaring - av disse tre overordnede forholdene:
-Funksjonalitet og brukergrensesnitt i den nye programvaren som tilbys i skyversjonen oppleves vesentlig forskjellig fra den eksisterende versjonen.
-Prismodellene er nye og uvante.
-Det er utfordrende å få med seg historikken fra de klassisk installerte applikasjonene.
Ikke så rart at det generer utfordringer og usikkerhet i en bedrift eller organisasjon når man finner ut at man faktisk står ovenfor en oppgradering til et IT-system man verken kjenner funksjonaliteten til , eksakt pris på, eller kan ta med data fra det gamle systemet til!
OK. Jeg satte det på spissen nå. Kan ikke forenkle det sånn, og ikke tenke så negativt. Selvsagt skal oppgraderingen til nye applikasjoner bidra til å øke effektiviteten, få ned kostnadene og øke konkurransekraften. Ellers ville overgangen til skyplattformer være meningsløs.
En grundig evaluering er altså nødvendig.
Innfrir skyen?
Ikke alle bedrifter eller organisasjoner vil oppleve at "skyen" umiddelbart innfrir sine lovnader om kostnadseffektiv innovasjon og effektiv IT-drift - basert på uovertruffen skalerbarhet og fleksibilitet - sånn uten videre.
Og grunnen til det er ikke så vanskelig å forstå, i alle fall ikke hvis jeg får forenkle det litt. For eksempel se på to forhold:
1) Leverandørenes forventninger til avkastning på investeringer
2) Grunnleggende forskjellig teknologi, terminologi og metodikk.
For det første har applikasjonsleverandørene gjort store investeringer i å utvikle programmene og tjenestene, samtidig som datasenterleverandørene har investert massivt i å bygge de fysiske plattformene som skal til i Public Cloud.
Begge skal ha igjen for investeringene sine, og lovnaden om kostnadsbesparelser ved å migrere til "sky" settes på prøve når de nye applikasjonene og tjenestene skal prises. Mange har opplevd det utfordrende å beregne gevinsten ved overgang til skytjenester pga overgangen fra eie- til leiebasert prising. Og fordi det i noen tilfeller er komplisert å forutse behovene for programvarelisenser, datakraft og lagringsplass.
For det andre er metodikken og livssyklusen for tjenestene som utvikles i Public Clouds svært forskjellig fra klassisk programvareutvikling. Programvare utviklet for "uendelig" skalerbarhet og DevOps har helt andre egenskaper en programvaren som var utviklet for en definert lokal plattform og beregnet for batch-vise oppgraderinger i en predefinert syklus.
Som følge av at de nye applikasjonene, med nye tjenester, utvikles i helt andre miljøer med andre metoder, blir det i mange tilfeller umulig å ta med seg historikk. Mange har opplevd at "den gamle" versjonen" må beholdes som oppslagsverk når den nye versjonen tas i bruk i skyen. Det betyr ofte at den gamle serveren blir stående igjen, og man får "dobbel" kostnad.
Dette er veldig overordnet forklart hvorfor de tre ovenfor nevnte forholdene har gjort skymigreringen litt mer utfordrende enn forventet for mange organisasjoner.
Jeg har bevisst ikke gått inn på om migreringen skal skje basert på IaaS, PaaS eller SaaS. Hva disse tre forkortelsene innebærer er så godt beskrevet på nettet at jeg anbefaler et raskt selvstudium.
Så hvordan angriper man overgangen slik at det blir en suksess? Det finnes nemlig ikke noe alternativ, i alle fall ikke for de aller fleste. Her er det "Go with the flow". Uansett mine kritiske blikk - alle må følge med i transformasjonen til skyen for å unngå å bli akterutseilt.
Med mindre du driver en samfunnskritisk tjeneste og har krav på deg om et eget datasenter som kan drive tjenesten uten tilgang til internett i en definert tidsperiode. Men det er en helt annen situasjon som ikke får plass i denne artikkelen.
Metodikk for suksess
Det skorter ikke på beskrevet metodikk for skymigreringer. Valg av riktig tilnærming er viktig.
Først av alt må organisasjonen definere målet med migreringen. Det er viktig å holde fokus på hver enkelt organisasjons individuelle mål og forventninger. Migreringen skal ikke skje for migreringens egen skyld. Den skal tilføre bedriften din lønnsomhet og konkurransekraft.
En detaljert analyse og kartlegging av forretningsprosesser og IT-systemer må gjøres først. Hvor er bedriftens "pengemaskin" og hvor er kostnadene. Hvordan støttes hele prosessen av IT i dag, og hvor kan det gjøres bedre?
I hvilken grad endrer markedet og kundenes forventninger seg, og hvor raskt endrer de seg. Skymigreringen bør være en evolusjon, og ikke en revolusjon. Begrepet Hybrid Cloud oppsto veldig raskt i kjølvannet av lanseringen av Public Clouds. Nettopp fordi skymigreringen er en gradvis utvikling fra on prem til Public Cloud.
De aller fleste velger først en kombinasjon av on prem/Privat Cloud og Public Cloud før alle tjenester kan leveres "as a service" fra de store skyene. Prosessen kan ta flere år.
I denne "top down" tilnærmingen ønsker de fleste å benytte flinke forretningsrådgivere for å gjennomføre kartlegging og analyse av hvordan transformasjonen best bidra til vekst.
For å få fokus bort fra teknologien og over på strategi og organisasjon kan jeg anbefale denne boken:
Vekst og digitalisering - dilemmaer fra virkeligheten
Benedicta Aall Bugge, Janne Aas-Jakobsen og Maaike M. Visser Taklo, 2022
Cappelen Damm Akademisk
Når det overordnede målet og strategien er på plass kan veikartet tegnes og teknologene kan starte reisen.
Gjennomføring
Når det gjelder selve gjennomføringen av oppgraderinger og migreringer av applikasjoner og plattformer, som en følge av den overordnede strategiske analysen, er metodikken i større grad standardisert.
Den mest omtalte innfallsvinkelen for å starte planleggingen av en applikasjonmigrering er beskrevet som de 7 R'ene:
Refactor, Replatform, Repurchase, Rehost, Relocate, Retain, and Retire.
For hvert enkelt element i den eksisterende infrastrukturen som blir berørt av migreringen gjøres en vurdering av hvilken av de sju R'ene som henholdsvis kommer til anvendelse.
Resultatet kan spenne fra rett og slett terminering (retire) av en applikasjon eller tjeneste til beslutning om utvikling av helt nye tjenester (refactor). I noen tilfeller vil de lokale applikasjonene videreføres (retain). Prøv å unngå den siste. For det betyr som regel at en server ikke blir slått av, og fortsatt vil være til bry.
Mellom disse ytterpunktene ligger mulighetene replatform, repurchase, rehost, relocate, som antas å være de vanligste rutene for Road Map til skyen.
Jeg overlater til de tre største Public Cloud-leverandørene å beskrive analysen av den praktiske gjennomføringen av migreringen. De har alle tre et forhold til R'ene, i tillegg til godt beskrevne veiledninger til hvordan skymigreringen skal foregå.
Her er bare noen tips til inspirasjon:
Microsoft omtaler naturlig nok ikke retain og retire i sin metodikk siden de to ikke involverer noen form for migrering, derav bare 5 R'er hos Microsoft. Cloud Adoption Framework
Google presiserer at de 7R'ene (som kanskje er 8R'er) ikke er en strategi, og stiller betimelig spørsmål ved om R'ene er overfokusert. Real World Cloud Migration Strategies
Amazon baker inn de 7 opprinnelige R'ene i sin giude for migrering. Large Migration Strategies.
God lesing!
Bakgrunn
Min erfaring med migreringer fra on-prem til skybaserte tjenester skriver seg fra en periode som kundeansvarlig for et titalls kunder hos en IT-driftsleverandør som tok den vanskelige, men riktige, avgjørelsen om å anbefale kundene om å migrere fra driftsleverandørens lokale "Private Cloud" til globale "Public Clouds."
Konklusjon
"Fokus på egen båt!" pleide kapteinen å rope under regattaen hvis vi i mannskapet ble for opptatt av hva som skjedde med de andre båtene.
Egne behov og egen Road Map defineres først! Da blir gjennomføringen glatt seilas.
Les også:
Er skytjenestene grønne?
Bærekraft og digitalisering.