Når cloud ikke bare er en migration
"Vi er blevet opkøbt af en anden virksomhed, og derfor skal vi ind i deres cloud-setup."
Sådan lyder starten på flere af de her slags projekter.
I det her tilfælde var det en virksomhed i en reguleret sektor med kritisk infrastruktur. Alt lå on-prem i egne datacentre, og der var stort set ingen erfaring med cloud. Samtidig var de blevet en del af en stor koncern, hvor compliance, sikkerhed og governance allerede var defineret.
Cloud var ikke et valg. Det var et krav. Men ret hurtigt stod det klart, at det her ikke bare handlede om at flytte nogle applikationer.
Anders, Cloud Architect hos cVation, har været en del af projektet fra start og arbejdet tæt med både platform og migrering.
Mere end en teknisk øvelse
Den tekniske opgave var kompleks i sig selv.
Applikationer skulle flyttes i bølger, afhængigt af hvor kritiske de var. Noget måtte slet ikke flyttes. Samtidig skulle alt passe ind i en eksisterende struktur med klare krav til identitet, netværk og hosting, i det her tilfælde Azure.
Ifølge Anders var det sværeste ikke teknologien. Det var at få det til at fungere i spændet mellem en organisation uden cloud-erfaring og en koncern med klare forventninger til, hvordan tingene skulle gøres.
Der var constraints fra begge sider, og de trak ofte i forskellige retninger.
Vi startede med platformen
I stedet for at begynde med migrationen, startede vi med at bygge platformen.
Det er ofte vores klare anbefaling i den her type projekter. Hvis man bare flytter applikationer uden et fælles fundament, ender man hurtigt med løsninger, der er svære at arbejde i bagefter.
En platform isoleret fra forretningen er dog heller ikke svaret. Derfor definerede vi tidligt lighthouse workloads, som platformen skulle understøtte fra dag ét. Det sikrer, at de valg vi træffer omkring arkitektur, standarder og tooling er forankret i forretningens konkrete behov og ikke blot teoretiske konstruktioner.
Fokus var at skabe et setup, der gør det muligt at bygge og drifte applikationer på en konsistent måde. Det betød blandt andet templates og service patterns til deployment, standarder for pipelines i GitHub, klare guardrails for sikkerhed og adgang og monitorering tænkt ind fra start.
Et af målene var at reducere den kognitive load for udviklerne. At gøre det tydeligt, hvordan man gør tingene rigtigt, uden at man skal forstå hele platformen i dybden fra dag ét.
Det største skifte er ansvar
Noget af det, der ændrer sig mest i den her type projekter, er ikke kun teknologien, men også måden, organisationen arbejder på.
Udgangspunktet var en klassisk opsætning med mange handovers og afhængigheder. Udviklere bestilte infrastruktur gennem tickets, ventede på adgang og var afhængige af flere led, før noget kunne komme i drift.
Det skaber friktion. Og det øger kompleksiteten.
I stedet arbejder vi mod en model, hvor udviklerne selv kan deploye og drifte deres løsninger end-to-end.
"You build it, you run it, you own it".
Anders fortæller, at et sådant skifte kræver tæt samarbejde med dem, det påvirker. De centrale teams, der afgiver ansvar, applikationsteamsne, der overtager det, og interessenter som IT security og compliance. Organisationen var allerede i gang med den bevægelse, men cloud-migreringen kickstartede den for alvor, ikke mindst fordi det også er den operating model, moderselskabet arbejder efter.
Modellen kendes ofte som en Shared Responsibility Model. En klar beskrivelse af, hvem der er ansvarlig for hvad, fordelt mellem Microsoft, platformteamet og applikationsteamsne, og hvor ansvaret overlapper.
Det kræver, at platformen tager noget af kompleksiteten væk. At der er klare patterns, templates og guardrails, så man ikke skal opfinde det hele selv hver gang.
Guardrails spiller en særlig rolle her. De sikrer automatisk, at de teams, der får mere ansvar, kun kan deploye infrastruktur, der lever op til organisationens IT-politikker. Hvis guardrailsne tillader det, er man i princippet compliant. Det er også en måde at fjerne kompleksitet på.
For kunden betyder det færre afhængigheder, mindre ventetid og en organisation, der kan arbejde mere selvstændigt.
Og det er ofte her, man ser den reelle effekt af transformationen.
Når det begynder at virke
Når fundamentet er på plads, ændrer det, hvordan man arbejder.
Nye miljøer bliver nemmere at oprette. Det bliver nemmere at deploye og teste ændringer.
Det gør det lettere at migrere og at levere værdi hurtigere fremover.
Og en større del af driften kan håndteres gennem managed services.
I praksis er en migrering ofte et miks. Noget rehostes, det vil sige flyttes direkte fra virtuelle maskiner on-prem til virtuelle maskiner i Azure, for at kunne moderniseres senere, mens andre applikationer replatformes til managed services som en del af migreringen.
Det betyder også, at noget af ansvaret flytter sig. Microsoft tager sig af hardware, patching, netværk og security hardening, mens fokus i højere grad ligger på at levere applikationerne.
Det gør faktisk løsningen mere simpel. Og det er samtidig en del af det, der gør det muligt at give applikationsteamsne mere ansvar, fordi meget af det, man normalt selv skulle håndtere, er abstraheret væk.
Rollen i den slags projekter
I den her type projekter er rollen sjældent én ting.
Vi arbejder på tværs af arkitektur, implementering og adoption.
Men en stor del af arbejdet ligger i at forstå, hvor organisationen er, og hvad der faktisk giver mening i deres kontekst.
Det handler om at få de rigtige stakeholders med på de rigtige tidspunkter.
At forstå både forretningen og de tekniske begrænsninger. Og at sikre, at der er buy-in undervejs.
Det fungerer kun, hvis man arbejder tæt sammen. Ikke med en stor overlevering til sidst, men side om side med kunden gennem hele forløbet. Så de forstår, hvad der er bygget, og hvorfor.
Hvornår er det en succes?
I et projekt som det her, i en reguleret sektor og med krav fra begge sider, er compliance en stor del af målet. Men i sig selv er det ikke nok.
For Anders er det først en succes, når platformen faktisk er til at arbejde i, når udviklerne selv kan drifte deres workloads, og når organisationen kan bygge videre uden at være afhængig af os.
For så er man ikke bare flyttet til cloud. Man har ændret måden, man udvikler og drifter software på, og man bruger cloud'en, som den er tiltænkt. Det er der, man får mest ud af den.