Det er ikke lengre valgfritt å ha en "sky-strategi". De siste 15 årene har cloud tjenester blitt normen for investeringer i IT infrastruktur.
Målsettingen til så godt som alle "sky-strategier" er økt fleksibilitet og lavere kostnader, dessverre er ofte resultatet noe helt annet.
Hva er cloud vendor lock-in?
Det å kjøpe server, router, switch, firewall, storage, internett tilgang og backup fra samme leverandør, det er en cloud vendor lock-in.
De store cloud leverandørene som AWS, Azure, og Google Cloud jobber hardt for å holde kunder innenfor deres økosystem av skytjenester. Når disse leverandørene forkynner om cloud fleksibilitet så snakker de alltid om fleksibilitet innenfor deres avgrensede økosystem av tjenester.
Resultatet er at mange bedrifter ender opp med en monolitt av en cloud infrastruktur hvor det ofte er langt mindre fleksibilitet for valg av tjenester enn hva de tidligere hadde med sine on-premise IT tjenester.
Cloud applikasjoner basert på åpne standarder
Akkurat som det alltid har vært, er det å bygge cloud-applikasjoner basert på åpne standarder og er det første skrittet i å sikre fleksibilitet.
Om du bygger forretningskritiske applikasjoner som er avhengig av en tjeneste eller teknologi som kun en cloud leverandør tilbyr, så har du skapt en lock-in.
Selvsagt er det mulig at leverandør spesifikke standarder blir åpne standarder, men dette tilhører sjeldenhetene. Et eksempel på dette er S3 standarden til AWS for objektlagring som har blitt en standard for all objektlagring på tvers av leverandører.
Sandbox generiske cloud tjenester
En av grunnene til å benytte seg av cloud infrastruktur er mulighetene til å bygge verdi på toppen av andre sin infrastruktur. Det vil normalt ikke være formålstjenlig å gjenskape funksjonaliteten som finnes i tjenester som Amazon A2I eller Azure Cognitive Services innenfor en cloud-applikasjon.
Den beste måten å utnytte slike tjenester, men samtidig bevare fleksibiliteten er å bygge generiske cloud tjenester innenfor din applikasjon. Dette gjør det mulig å isolere bruken av 3. parts cloud tjenester, SDK og eventuelt datastruktur. Resultatet er at det blir enklere å bytte ut 3. parts tjenester i fremtiden dersom noe bedre eller mer kostnadseffektivt blir tilgjengelig.
Bygg generiske data modeller
Når man jobber med data modellering i cloud applikasjoner så er det viktig å fristille seg fra datamodellen til leverandører av en spesifikk cloud tjeneste.
Datamodellen bør være bygget opp rundt forretningslogikken i applikasjonen og ikke de tekniske navnene i tjeneste du har integrasjoner mot.
Et praktisk eksempel her er hvis du bygger en applikasjon for å lese bilskilt med integrasjon mot Google Vision API. Google vil returnere skiltnummeret med nøkkelen textAnnotations[].description men du vet at dette er et skiltnummer og i den generiske data modellen bør dette navngis som bilskilt nummer eller "license plate number" ettersom de fleste datamodeller er på engelsk.
Tenk multi-cloud arkitektur fra starten
Multi-cloud betyr i praksis at man bygger en cloud applikasjon som kan gjøres hos flere cloud leverandører samtidig.
Bygging av multi-cloud applikasjoner kan introdusere betydelige kompleksitet dersom introdusert etter at arkitekturen for en applikasjon er satt, men dersom man bygger en cloud applikasjon som tar høyde for multi-cloud i den grunnleggende arkitekturen, så vil det ofte øke kvaliteten på arbeidet til utviklerne.
Normalt vil utviklingen av multi-cloud applikasjoner sette mye høyere krav til både sikkerhet og feilhåndtering enn hva mono cloud applikasjoner har behov for.
Når cloud-applikasjonene testes så er det også viktig at multi-cloud scenarioer med split-brain problematikk blir grundig testet før produksjonssetting.
Planlegg cloud exit først
Før man tar i bruk en cloud tjeneste bør man lage en exit plan. Ofte ser vi bedrifter som ikke lengre har kontroll over egne data etter å ha investert flere år på å lagre data inn i lukkede cloud tjenester.
I cloud verden er det utrolig enkelt å ta i bruk nye tjenester uten å tenke på konsekvensene rundt dette. Azure alene har mer enn 600 tjenester som kan aktiveres ved noen få tasteklikk.
Det er en trend at raskt voksende teknologiselskaper benytter cloud infrastruktur til å vokse, men når man har funnet en kundemasse og et basisbehov av tjenester velger man da å flytte disse til on-premise, for å redusere kostnader. Dropbox var en av de første til å flytte mye av infrastrukturen fra AWS, men vi har i senere tid sett både Ahref og Basecamp gjøre tilsvarende cloud-exit.
Vil du snakke mer om bygging av cloud-applikasjoner? Ta kontakt med Egil: [email protected]
Skrevet at Egil Fujikawa Nes
