Kubernetes eller serverless?

Har dere lagt de tradisjonelle serverne bak dere, dukker neste spørsmål snart opp: Skal skaleringen skje med Kubernetes eller serverless? De to representerer ulike filosofier for hvordan en moderne applikasjon skal driftes: Den ene handler om kontroll, den andre om å slippe å bry seg. Her er avveiingen og grunnen til at svaret ofte ligger midt imellom.

Serverless: riktig standardvalg for mindre team

Serverless betyr at skyleverandøren kjører koden din for deg. Du laster opp funksjonene eller applikasjonen, og plattformen tar seg av resten: starter opp når noe skjer, skalerer automatisk ved belastning og skalerer ned til null når det er stille. Du betaler bare for faktisk bruk.

For et mindre team er det vanskelig å slå. Det finnes ingen server å patche, ingen kapasitet å dimensjonere og ingen vaktordning for selve plattformen. Ved ujevn eller lav last er det dessuten svært billig: Det koster ingenting når ingenting skjer. Teamet kan bruke tiden på produktet i stedet for på infrastrukturen.

Prisen er to ting. For det første en tettere kobling til leverandørens måte å gjøre ting på, noe som gjør en fremtidig migrering vanskeligere. For det andre visse begrensninger, for eksempel på hvor lenge en kjøring kan vare. For de fleste mindre produkter veier enkelheten likevel tyngre, og serverless er et godt standardvalg.

Kubernetes: portabilitet og kontroll, til en pris

Filosofisk er Kubernetes det motsatte. Det er et system for å kjøre og samordne containere der du styrer plattformen, ned til minste detalj. Med det følger to reelle fordeler.

• Portabilitet. Et Kubernetes-oppsett kan kjøres nesten hvor som helst, hos hvilken som helst skyleverandør eller på egne servere. Det reduserer innlåsingen og gir forhandlingsrom.
• Kontroll. Du bestemmer nøyaktig hvordan tjenester kjøres, skaleres og kobles sammen. Krav som serverless ikke tillater, for eksempel svært lange kjøringer eller spesielle nettverksbehov, kan oppfylles.

Men kontrollen koster. Kubernetes er en plattform i seg selv som må driftes, oppgraderes, sikres og overvåkes, og den krever kompetanse som er spesialisert og ikke gratis å rekruttere. For et lite team med en håndfull tjenester blir det ofte mer maskineri enn nytten tilsier. Kubernetes lønner seg når kompleksiteten allerede er høy, ikke som en måte å fremtidssikre et enkelt produkt på.

Et scenario: når valget snur

Se for dere et oppstartsselskap med én applikasjon og ujevn trafikk. Serverless er det selvsagte valget: lave kostnader, ingen drift, teamet fokuserer på produktet. Så vokser selskapet. Antallet tjenester stiger til flere titall, lasten blir høy og jevn døgnet rundt, og et par komponenter krever kjøringer som varer lenger enn serverless tillater. Nå begynner serverless-regningen å merkes og begrensningene å skave. På et tidspunkt snur regnestykket: Kontrollen og den jevne kapasiteten som Kubernetes gir, blir verdt driftskostnaden. Poenget er at valget ikke er for livet. Riktig svar kan endre seg med størrelsen.

Mellomformene som ofte er det egentlige svaret

Her er det viktigste, og det mange overser: Valget står sjelden mellom de to ytterpunktene. Midt imellom finnes administrerte containere (managed containers), tjenester som Cloud Run og Fargate.

Ideen er at du pakker applikasjonen i en container akkurat som i Kubernetes-verdenen, men slipper å drifte selve Kubernetes-maskineriet. Leverandøren kjører og skalerer for deg, ofte ned til null som serverless. Du får containerverdenens fleksibilitet med serverless-lignende enkelhet.

For en stor andel av alle team er den midterste raden det riktige svaret. Den gir fleksibilitet uten hele driftsbyrden til Kubernetes og skalerer smidig uten de strammeste begrensningene til serverless.

Slik velger du

Begynn med serverless eller administrerte containere. De dekker de fleste behov for små og mellomstore produkter, med lite drift og betaling etter bruk. Gå over til Kubernetes når kompleksiteten virkelig krever det (mange tjenester, behov for portabilitet eller krav serverless ikke klarer), og når dere har kompetansen til å forvalte det.

Ønsker dere hjelp til å velge riktig driftsmodell for akkurat produktet deres, ser vi i Weapp gjerne på det som en del av arbeidet vårt med skyarkitektur. Ta kontakt, så drøfter vi hva som er fornuftig før dere låser dere til et oppsett.