Kubernetes eller serverless?

Har I lagt de traditionelle servere bag jer, dukker det næste spørgsmål hurtigt op: Skal skaleringen ske med Kubernetes eller serverless? De to repræsenterer hver sin filosofi for hvordan en moderne applikation skal drives: Den ene handler om kontrol, den anden om at slippe for at bekymre sig. Her er afvejningen, og hvorfor svaret ofte ligger midt imellem.

Serverless: det rigtige udgangspunkt for mindre teams

Serverless betyder at cloududbyderen kører din kode for dig. Du uploader funktionerne eller applikationen, og platformen klarer resten: starter op når der sker noget, skalerer automatisk under belastning og skalerer ned til nul når der er stille. Du betaler kun for det faktiske forbrug.

For et mindre team er det svært at slå. Der er ingen server at patche, ingen kapacitet at dimensionere og ingen vagtordning for selve platformen. Ved ujævn eller lav belastning er det desuden meget billigt, for det koster intet når der ikke sker noget. Det giver teamet mulighed for at bruge tiden på produktet i stedet for på infrastrukturen.

Prisen er todelt. Dels en tættere kobling til udbyderens måde at gøre tingene på, hvilket gør en fremtidig flytning sværere. Dels visse begrænsninger, f.eks. på hvor længe en kørsel må vare. For de fleste mindre produkter vejer enkelheden alligevel tungest, og serverless er et godt udgangspunkt.

Kubernetes: portabilitet og kontrol, til en pris

Filosofisk er Kubernetes det modsatte. Det er et system til at køre og koordinere containere hvor du styrer platformen, ned i mindste detalje. Det giver to reelle fordele.

• Portabilitet. Et Kubernetes-setup kan køre næsten hvor som helst, hos en hvilken som helst cloududbyder eller på egne servere. Det mindsker fastlåsningen og giver forhandlingsrum.
• Kontrol. Du bestemmer præcis hvordan services køres, skaleres og kobles sammen. Krav som serverless ikke tillader, f.eks. meget lange kørsler eller særlige netværksbehov, kan opfyldes.

Men kontrollen koster. Kubernetes er i sig selv en platform der skal driftes, opgraderes, sikres og overvåges, og den kræver kompetencer der er specialiserede og ikke gratis at rekruttere. For et lille team med en håndfuld services bliver det ofte mere maskineri end gevinsten kan retfærdiggøre. Kubernetes betaler sig når kompleksiteten allerede er høj, ikke som en måde at fremtidssikre et simpelt produkt på.

Et scenarie: når valget vender

Forestil jer en startup med en applikation og ujævn trafik. Serverless er det oplagte valg: lav udgift, ingen drift, og teamet fokuserer på produktet. Så vokser virksomheden. Der kommer snesevis af services, belastningen bliver høj og jævn døgnet rundt, og et par komponenter kræver kørsler der er længere end serverless tillader. Nu begynder serverless-regningen at kunne mærkes, og begrænsningerne begynder at gnave. På et tidspunkt vender regnestykket: Den kontrol og den jævne kapacitet som Kubernetes giver, bliver driftsomkostningen værd. Pointen er at valget ikke er for livet. Det rigtige svar kan ændre sig med størrelsen.

Mellemformerne der ofte er det egentlige svar

Her er det vigtigste og mest oversete: Valget står sjældent mellem de to yderpunkter. Midt imellem findes managed containere, tjenester som Cloud Run og Fargate.

Idéen er at du pakker din applikation i en container præcis som i Kubernetes-verdenen, men slipper for at drifte selve Kubernetes-maskineriet. Udbyderen kører og skalerer for dig, ofte ned til nul ligesom serverless. Du får containerverdenens fleksibilitet med en enkelhed der minder om serverless.

For en stor del af alle teams er den midterste række det rigtige svar. Den giver fleksibilitet uden Kubernetes’ fulde driftsbyrde og skalerer smidigt uden serverless’ snævreste begrænsninger.

Sådan vælger du

Start med serverless eller managed containere. De dækker de fleste behov for mindre og mellemstore produkter, med lidt drift og betaling efter forbrug. Gå over til Kubernetes når kompleksiteten virkelig kræver det (mange services, behov for portabilitet eller krav som serverless ikke kan klare) og når I har kompetencerne til at drifte og vedligeholde det.

Vil I have hjælp til at vælge den rigtige driftsmodel til netop jeres produkt, ser vi hos Weapp gerne på det som en del af vores cloudarkitektur. Kontakt os, så drøfter vi hvad der er fornuftigt før I binder jer til en bestemt opsætning.