Fra datacenter til cloud: 4 skridt, der sikrer, at dit cloud projekt bliver en succes

Cloud. Skyen. Andre menneskers computere.

Uanset hvordan man taler om cloud er en ting sikkert: Der kommer mere af det.

Nogle virksomheder har en cloudstrategi for at spare penge. Nogle, fordi det understøtter en bredere digitaliseringsdagsorden. Og nogle, fordi det simpelthen giver bedst mening af tekniske årsager.

Om du overvejer at flytte data eller applikationer i skyen af den ene eller den anden årsag, er det vigtigt at processen tilrettelægges ordentligt. Netic giver dig her 4 vigtige skridt til at sikre, at dit cloud-projekt bliver en succes.

1. Kortlægning

De fleste cloud-projekter starter med en idé eller et ønske.

En idé som man ønsker at kortlægge, og hvor cloud på et tidspunkt bliver inddraget som et naturligt led i design og implementering. Eller et ønske fra en kunde - eller internt - om at gøre ting billigere, lettere eller mere smart.

Derfor starter processen med at kortlægge behov og krav, og til det formål skal der udarbejdes en cloud-model, der som minimum bør indeholde følgende elementer:

• Governance
• Application Assessment
• Arkitektur
• Implementering

Governance er politikker og regler for omgangen med applikationen og applikationens data. Hvordan arbejdes der med dette? Hvordan dokumenteres der? Hvordan håndteres brud?

Application Assessment er en vurdering af applikationen og dens afhængigheder i forhold til implementering og drift i cloud. Hvis applikationen på dette tidspunkt ikke er udviklet, skal man træffe de arkitekturvalg, der er nødvendige, for at sikre en rigtig cloud native applikation. Hvis applikationen allerede er i drift - eller på vej i drift - skal der måske planlægges en række ændringer eller opdateringer, før applikationen flyttes i skyen.

Arkitektur er essentielt. Ikke kun arkitekturen i selve applikationen, men i særdeleshed de valg, der skal træffes for at sikre et optimalt udbytte af den cloud-platform, der vælges; valg, der i sidste ende er med til at sikre en god oplevelse for brugerne og en sund økonomi.

Det kan måske virke som om Design & Implementering er for tidligt at have med i cloud-modellen allerede på dette tidspunkt, men det er vigtigt, allerede på et tidligt tidspunkt at have for øje, at der kommer en fase, der hedder implementering og drift - og at de valg der træffes fra starten, vil have en indvirkning på det, der kommer.

En grundigt gennemtænkt cloud-arkitektur gør hele forskellen mellem cloud-enabled og cloud-native. Se desuden afsnittet "Lift & Shift" længere nede.

2. Strategi

Når infrastrukturen bliver en softwareplatform, giver det en grad af agilitet, som på sigt vil transformere den måde, IT-afdelinger arbejder på.

Men det indebærer også udfordringer, for selvom det er muligt at udføre både udvikling og drift på denne softwareplatform med processer, der er designet til at virke på fysisk infrastruktur, er det sjældent det, der giver de bedste resultater.

Derfor bør din virksomhed udarbejde en cloud-enablement strategi, under hensyntagen til de temaer og strategier, som virksomheden i øvrigt har vedtaget på IT-området. Med en sådan strategi på plads, bliver det lettere at identificere de operationelle skridt og prioritere disse.

Nu kan jeg næsten høre dig spørge: "Hvad skal en cloud-strategi så egentligt indeholde?". Spørgsmålet er absolut rimeligt. I en artikel fra Gartner, februar 2018, lyder buddet at strategien skal adressere fem hovedspørgsmål:

1. Hvor og hvordan skal vores organisation benytte sig af cloud-computing services?
2. Hvordan vil vi - på tværs af hybride miljøer - tilgå, sikre, styre og integrere data samt håndtere governance?
3. Hvordan indfaser vi cloud computing i vores applikationsstrategi og -arkitektur?
4. Hvilke ændringer fordrer cloud computing af vores eksisterende infrastruktur og de dertil hørende teknologier?
5. Hvor bliver vores forretning en cloud computing service provider for andre?

3. Design & Implementering

Strategi og planlægning kommer altid først, men på et eller andet tidspunkt når du dertil, at applikationen skal implementeres eller migreres. Det er med andre ord tid til eksekvering.

Hvis du har gjort dit arbejde godt nok i step 1 og 2, har du faktisk allerede de elementer, du behøver, for at kunne lave et design og udføre migrering eller implementering. Hvis ikke, kommer her de elementer, som vi hos Netic mener, at du bør overveje:

Applikationsoptimering eller refactoring (omskrivning)

Er din applikation klar til at komme i skyen, eller skal den optimeres først? Måske skal koden omskrives inden migreringen rent faktisk kan foretages? Disse spørgsmål bør du overveje.

Hvis I stadig er ved at udvikle applikationen, er dette naturligvis ikke et issue, men et cloud-fokuseret design er altid et godt udgangspunkt og bør tages alvorligt. 

Infrastruktur og sikkerhed

Hvordan hænger applikationen sammen med jeres øvrige infrastruktur? Vil den blive et element i et hybridt miljø, hvor workloads flyttes fra eget eller hostet datacenter til skyen og tilbage?

Hvordan med sikkerheden? Er GDPR og governance tænkt ind? Måske skal firewall-regler og access lister ændres?

Det var blot nogle få spørgsmål som jeres infrastrukturfolk måske vil bringe på banen, inden applikationen kan migreres. Der er helt sikkert flere. Tal med dine netværksfolk og dine sikkerhedsfolk - eller med en kvalificeret cloud-rådgiver, for at sikre, at alle sten bliver vendt.

Migration eller Lift & Shift

Vi har ikke talt så meget om dette, men der findes jo faktisk en måde at få en applikation ud i skyen hurtigt. Det såkaldte "Lift & Shift".

Lift & Shift indebærer, at applikation flyttes mere eller mindre 1:1 ud på en virtuel server i Public Cloud. Der er naturligvis stadig ting at tage hensyn til. Firewall regler og access-lister, eksempelvis. Andre servere skal måske peges i retning af, hvor applikationen nu ligger.

Men det er en temmeligt brugt måde at få en applikation hurtigt i skyen. Vi ser blot ofte, at der herefter ikke sker mere: Nu er vi i skyen og alle er glade. Det er der for så vidt ikke noget galt i, men ved Lift & Shift udnytter man under 10 % af de fordele, som Public Cloud virkeligt giver: Micro-services, Platform as a Service og "rigtig" cloud computing. Dvs. de processer der vil være med til at øge effektiviteten og nedbringe driftsomkostningerne.

Med det sagt, kan Lift & Shift faktisk i mange tilfælde være en fin mellemlanding, mens applikationen cloud-enables.

Træning og kompetencer

Som et sidste punkt, der bør overvejes i forbindelse med implementering, er kompetencerne.

Samtidigt binder dette punkt fint sammen med det fjerde punkt i hele din projektplan - nemlig den fortsatte drift. For hvilke kompetencer skal din virksomhed have, for at jeres cloudrejse kan lykkes? Findes der medarbejdere, der har kompetencerne? Eller måske blot nogle af de nødvendige kompetencer, der så kan bygges videre på?

Måske vil I finde ud af, at det bliver nødvendigt at inddrage en leverandør; enten til at træne medarbejderne eller til rent faktisk at varetage driften. Kort og godt: Ressourcer og kompetencer.

4. Management & Drift

Hos Netic har vi gennem årene set og været i berøring med rigtigt mange softwareprojekter. Fælles for rigtigt mange af dem har været, at driftsfasen ikke har været tænkt ind allerede i udviklingsfasen.

Faktum er bare, at der kommer en driftsfase - og det gør der også for software i public cloud. Applikationen skal overvåges, der skal tænkes incidenthåndtering, patches og changes og mange andre ting. Klassisk drift.

Der er især tre emner, som det er vigtigt at overveje, i forhold til den fortsatte drift af din applikation i public cloud. Disse tre er Kapacitetsplanlægning, Observability og Cost-optimering.

Kapacitetsplanlægning

Traditionelt set, har kapacitetsplanlægning været en specialiseret IT-disciplin, hvor man baseret på events som eksempelvis hardware-ændringer eller ændringer af en applikation har foretaget justeringer af kapacitetsplanen.

I skyen forholder det sig imidlertid sådan, at infrastrukturen bliver en mere flydende størrelse, der dynamisk leverer forretningsservices on demand, og returnerer ressourcer tilbage til den dynamiske pulje, når disse ikke længere behøves. Derfor skal kapacitetsplanlægning i langt højere grad baseres på forretnings-KPI'er end på IT-specifikke events.

Observability

I en driftsverden har det altid været god latin, at have indsigt i sine systemer. I public cloud er det kritisk at have fuld transparens over applikationen og alle dens afhængigheder.

Dette skyldes at cloud-computing faktisk har introduceret en højere grad af kompleksitet, i og med at applikationer i skyen ofte er distribuerede og kan have afhængigheder flere steder og måske hos andre cloud vendors.

Derfor er der behov for en langt større grad af indsigt i, hvordan applikationen opfører sig.

Cost-optimering

En af de store fordele ved public cloud er, at det fungerer efter en Pay-as-You-Go model. Eller sagt på en anden måde: Efterhånden som dit forbrug skalerer, gør omkostningerne det også.

Det er naturligvis en fordel, fordi du ikke behøver at betale for store "klumper" af infrastruktur, som du ikke har behov for endnu - du er ikke underlagt en rigid prisstruktur.

Men det gør også at det er sværere at planlægge omkostningerne til infrastruktur, hvis man ikke på forhånd ved, hvordan ressourceforbruget kommer til at udvikle sig.

Hvis du overvejer at flytte hele eller dele af din virksomheds applikationer i public cloud, så tag fat i os for en snak om mulighederne.

Læs mere her: https://www.netic.dk/ydelser/netic-cloud-operations/