Der er meget godt at sige om cloudmigration. Efter en migration kan der høstes solide gevinster i form af bla. driftsoptimering, øget sikkerhed og skalerbarhed. Bare for at nævne nogle få. Men ofte bliver fordelene ved selve migrationsprocessen overset. Og det er en skam, for der er virkelig meget at hente.
Selvom målet ikke er den italienske hovedstad, kan en sammenligning godt være på sin plads. For hvis ikke alle, så er der mindst seks veje til clouden. AWS arbejder godt nok med syv – det skader jo ikke at strække sig lidt længere – men den generelle konsensus er, at der er seks strategier for migration. Enten samlet set eller fordelt efter formål og gevinst på forskellige dele af den eksisterende infrastruktur.
En af disse – og en helt oplagt mulighed i forbindelse med en migration – er at se på den samlede infrastruktur med friske og kritiske øje, og gennem en detaljeret analyse at kortlægge det totale korpus af integrationer, platforme og services, med henblik en evaluering af infrastrukturens arkitektur. For alle virksomheder, der ikke er cloud natives, vil der med stor sandsynlighed være optimering at hente ved at inkludere dette i den indledende analysefase for udarbejdelse af anbefalinger til det fremtidige design.
Monolittens lerfødder
Kendetegnede for infrastrukturer, der ikke er født i clouden, er deres monolitiske struktur med tætknyttede afhængigheder, silodannelse og manglende evne til udveksling af data på tværs af forretningsområder. Det gav mening og overskuelighed, da infrastrukturen var simpel og bestod af relativt få services. Men med stadigt større digitale behov og mulighed for målrettet understøttelse af alle dele af organisationens værdikæde og forretningsområder, er kompleksiteten eksploderet, og de tæt knyttede afhængigheder udgør et problem.
Dels betyder alt-som-en-service-arkitekturen, at en spidsbelast af én service medfører, at hele infrastrukturen skal skaleres med et voldsomt ressourcespild som resultat.
Tilsvarende kan det fastlåste, monolitiske setup betydet, at en fejl på én service sætter en kædereaktion i gang, der påvirker hele infrastrukturen.
Samlet set er konsekvenserne af en monolitisk infrastruktur en øget sårbarhed, spildte ressourcer og en tilbageholdenhed i forhold til at introducere nye services. Blandt andet fordi det er vanskeligt at implementere i en låst struktur, og fordi det er forbundet med risiko for hele værdikæden, hvis en ny service fejler. Det bremser innovationen, forlænger roll-outs og reducerer mulighederne for digital forretningsudvikling i alle dele af organisationen.
Op i gear med microservices
Første iteration til en ny tilgang til implementering af en ny mere agil digital understøttelse kom med SaaS. Her var der dog særlig fokus på mulighederne for nemmere adgang til skalering og opdatering. Det store ryk blev for alvor muligt med den globale adgang til cloud, hvor særligt AWS med sin enorme storagekapacitet og agnostiske setup med samarbejde med mange tusinde serviceudbydere, bogstavelig talt gav mulighed for at designe præcis den infrastruktur med præcis de services, en virksomhed har brug for. Med værktøjer til nemt at integrere alle services i et netværk med veldefinerede API’er.
Dermed var microservices introduceret.
Kendetegnende for en infrastruktur baseret på microservices er, at hver service med en tilknyttet applikation er en autonom enhed med en klar kobling til en specifik forretningsfunktion, der indfrier et specifikt behov. En microservice-applikation bliver udviklet, implementeret, kørt og skaleret uafhængigt af infrastrukturens øvrige services. De veldefinerede API’er giver sikker og enkel udveksling af data imellem microservicestrukturens applikationer, uden at denne kobling betyder uhensigtsmæssige afhængigheder eller kædereaktioner i tilfælde af fejl.
Fordele ved microservices:
Agilitet: Nye applikationer udspringer af specifikke, små og veldefinerede forretningsområder og applikationsbehov. De er alene tænkt til at understøtte en funktionalitet og kan således udvikles langt hurtigere og nemmere.
Skalerbarhed: Hver applikation skalerer uafhængigt af den øvrige infrastruktur, og spidsbelastninger et sted påvirker ikke resten. Det ekstra ressourceforbrug er således begrænset til den ene service.
Nem deployment: Enkel, kontinuerlig deployment af nye services, hvilket gør det nemt at teste nye idéer, der hurtigt – og forbundet med få omkostninger – kan pilles ned igen eller omfigureres i tilfælde af fejl. Sikrer kort time-to-market.
Frihed: Uden den tætte kobling og låste afhængigheder har teams frihed til at vælge præcis den service, der giver den bedste digitale understøttelse af det forretningsområde, de ønsker at optimere.
Bootstrapping: En koden udviklet til én service kan med små modifikationer genbruges som byggesten til en anden. På den måde kan man bootstrappe og slippe for at skrive koden fra bunden.
Resiliens: Med en microservicestruktur er infrastrukturen langt mere modstandsdygtig. Hvis en applikation fejler, kan denne blot lukkes ned og genstartes, uden at det påvirker resten af infrastrukturen.
Analyse af hele infrastrukturen og efterfølgende anbefalinger til valg af strategi for den kommen migration indgår i de første faser af AWS’ Migration Acceleration Program (MAP). Læs mere om det fulde program her.
Som en del af lanceringen af MAP i Danmark har AWS valgt, at hvis det leveres via KeyCore, kan det ske med fuld finansiering fra AWS.
Som Advanced Partner er KeyCores eksperter særligt trænede i at levere AWS Migration Acceleration Program.
For mere information om muligheder for at gennemføre MAP finansieret af AWS – kontakt os i dag