Hva er cloud native?
Cloud native betyr applikasjoner som er designet for skyens vilkår fra grunnen av: elastiske, containeriserte og automatisk produksjonssatte. Det motsatte er gamle systemer som bare er flyttet dit. Byggeklossene er containere, administrerte tjenester og automatiserte pipelines. Det senker driftskostnaden over tid, men krever mer designarbeid i starten.
Cloud native er et begrep man hører ofte, men som sjelden blir forklart tydelig. Det handler ikke bare om at et system tilfeldigvis kjører i skyen, men om hvordan det er bygget. Forskjellen er avgjørende for både kostnad og fleksibilitet. Nedenfor forklarer vi hva cloud native betyr, og hvorfor det er viktig for deg som kunde.
Definisjonen
Cloud native beskriver applikasjoner som er designet for skyens vilkår fra grunnen av. I stedet for å være bygget for én enkelt server og deretter flyttet til et annet sted, er de laget for å leve i et miljø som er elastisk, der kapasiteten kan vokse og krympe automatisk etter behov, og der delene kan produksjonssettes og byttes ut hver for seg.
Kjernen er at systemet utnytter det skyen faktisk tilbyr, i stedet for bare å bruke den som en leid variant av en gammeldags server. Et cloud native-system skalerer av seg selv når presset øker, gjenoppretter seg automatisk hvis en del svikter, og kan oppdateres ofte og trygt. Det er bygget for å endres, ikke for å stå stille.
Forskjellen på cloud native og lift-and-shift
Den enkleste måten å forstå cloud native på er å sette det opp mot det motsatte. Lift-and-shift betyr at man tar et eksisterende system akkurat som det er og flytter det rett opp i skyen, uten å endre hvordan det er bygget. Man løfter det opp og setter det ned på leid maskinvare.
Det går raskt, men systemet oppfører seg som før: Det skalerer ikke automatisk, utnytter ikke skyens ferdige tjenester og krever omtrent like mye drift som tidligere. Man har byttet adresse, men ikke måten å bo på. Cloud native er den motsatte tilnærmingen: å bygge, eller bygge om, applikasjonen slik at den er laget for skyen fra start og derfor kan dra full nytte av den.
Byggeklossene
Tre byggeklosser går igjen i så godt som hver eneste cloud native-løsning.
- Containere pakker en applikasjon sammen med alt den trenger for å kjøre, i et standardisert format. Resultatet er at den fungerer likt uansett hvor den kjøres, noe som gjør den enkel å flytte og å starte i mange kopier.
- Administrerte tjenester er ferdige skykomponenter (databaser, meldingskøer, lagring) som skyleverandøren drifter og vedlikeholder for deg. I stedet for å bygge og drifte dem selv bruker man dem som byggeklosser.
- CI/CD er automatiserte prosesser som tester og produksjonssetter ny kode uten manuelt arbeid. De gjør at oppdateringer kan skje ofte, raskt og med lav risiko.
Sammen gjør de tre systemet elastisk, robust og raskt å endre.
Et konkret scenario
Tenk deg en tjeneste med sterkt varierende last: rolig om natten og rush på bestemte tider av døgnet. Et cloud native-system møter det av seg selv. Når presset øker, startes flere containere automatisk og deler på jobben, og når det roer seg, trappes de ned igjen. Man betaler for høy kapasitet bare de timene den trengs.
Databasen er en administrert tjeneste, så ingen i teamet bruker tid på å ta sikkerhetskopier av den eller oppdatere den. Det er inkludert. Og når en forbedring skal ut, testes og produksjonssettes den automatisk gjennom en CI/CD-pipeline, samme dag. Et lift-and-shift-system ville i stedet ha krevd en fast, overdimensjonert server døgnet rundt og manuelt arbeid ved hver ny versjon. Samme tjeneste, men helt ulik økonomi og helt ulikt tempo.
Kostnaden: mer design nå, lavere drift senere
Her ligger avveiingen en kunde bør forstå. Det koster å komme dit: Cloud native krever mer designarbeid i starten fordi applikasjonen må bygges riktig for skyen fra begynnelsen i stedet for bare å flyttes dit. Den første investeringen er altså høyere.
Gevinsten kommer i forvaltningen. Driftskostnaden synker over tid fordi man betaler for faktisk bruk i stedet for overdimensjonert maskinvare, slipper å drifte egen infrastruktur og får et system som skalerer og vedlikeholdes automatisk. For et system som skal vokse eller har ujevn last, betaler designarbeidet seg tilbake. For et lite, stabilt system kan en enklere løsning være klokere. Som alltid avhenger det av hvordan løsningen skal brukes. Vi i Weapp hjelper til med å gjøre den avveiingen som en del av arbeidet vårt med skyarkitektur. Vil dere drøfte et konkret tilfelle, ta kontakt.
Ofte stilte spørsmål
Hva er cloud native, enkelt forklart?
Det er programvare som er bygget fra starten av for å leve i skyen og dra nytte av alt skyen tilbyr: å vokse og krympe automatisk etter behov, å produksjonssettes med et knappetrykk og å bestå av deler som kan byttes ut hver for seg. Det motsatte er gamle systemer som bare er flyttet til skyen uten å bli endret, og som derfor aldri utnytter det de nå kjører på.
Hva skiller cloud native fra lift-and-shift?
Lift-and-shift betyr at man tar et eksisterende system som det er og flytter det rett opp i skyen, uten å bygge det om. Det går raskt, men gir sjelden skyens fordeler. Systemet oppfører seg som før, bare på leid maskinvare. Cloud native innebærer i stedet at applikasjonen er utformet for skyen fra grunnen av slik at den faktisk kan skalere og driftes på skyens vilkår.
Hva er byggeklossene i cloud native?
Tre går igjen. Containere pakker en applikasjon med alt den trenger, og den kjører dermed likt overalt. Administrerte tjenester er ferdige skykomponenter (databaser, køer, lagring) som leverandøren drifter for deg. Og CI/CD er automatiserte prosesser som tester og produksjonssetter kode uten manuelt arbeid. Sammen gjør de systemet elastisk, driftssikkert og raskt å oppdatere.
Er cloud native alltid billigere?
Over tid ofte ja, men ikke fra første dag. Driftskostnaden synker fordi man betaler for det man bruker og slipper å drifte egen infrastruktur, og systemet skalerer automatisk i stedet for å kreve overdimensjonert maskinvare. Men det krever mer designarbeid i starten fordi applikasjonen må bygges riktig fra begynnelsen. Gevinsten kommer i forvaltningen, ikke på den første fakturaen.
Trenger alle systemer å være cloud native?
Nei. For et lite, stabilt system med jevn last kan det ekstra designarbeidet i starten være mer enn nytten tilsier. Cloud native lønner seg mest når lasten varierer, når systemet skal vokse, eller når rask og hyppig utvikling er viktig. Som med de fleste arkitekturvalg er svaret at det kommer an på hvordan systemet skal brukes og utvikles over tid.