Kubernetes eller serverless?

Har ni lämnat de traditionella servrarna bakom er dyker snart nästa fråga upp: ska skalningen ske med Kubernetes eller serverless? De två representerar olika filosofier för hur en modern applikation ska drivas – en om kontroll, en om att slippa bry sig. Här är avvägningen, och varför svaret ofta ligger mitt emellan.

Serverless: rätt default för mindre team

Serverless betyder att molnleverantören kör din kod åt dig. Du laddar upp funktionerna eller applikationen, och plattformen sköter resten: startar upp när något händer, skalar automatiskt vid belastning, och skalar ner till noll när det är tyst. Du betalar bara för faktisk användning.

För ett mindre team är det svårt att slå. Det finns ingen server att patcha, ingen kapacitet att dimensionera, ingen jour för själva plattformen. Vid ojämn eller låg last är det dessutom mycket billigt – kostar inget när inget händer. Det låter teamet lägga tiden på produkten i stället för på infrastrukturen.

Priset är två saker. Dels en tätare koppling till leverantörens sätt att göra saker, vilket gör en framtida flytt svårare. Dels vissa begränsningar – till exempel på hur länge en körning får pågå. För de flesta mindre produkter väger enkelheten ändå tyngre, och serverless är ett bra förval.

Kubernetes: portabilitet och kontroll, till ett pris

Kubernetes är motsatsen i filosofi. Det är ett system för att köra och samordna containrar där du styr plattformen, in i minsta detalj. Med det följer två verkliga fördelar.

• Portabilitet. En Kubernetes-uppsättning kan köras nästan var som helst – hos vilken molnleverantör som helst, eller på egna servrar. Det minskar inlåsningen och ger förhandlingsutrymme.
• Kontroll. Du bestämmer exakt hur tjänster körs, skalas och kopplas ihop. Krav som serverless inte tillåter, som mycket långa körningar eller speciella nätverksbehov, går att uppfylla.

Men kontrollen kostar. Kubernetes är en plattform i sig som måste driftas, uppgraderas, säkras och övervakas – och den kräver kompetens som är specialiserad och inte gratis att rekrytera. För ett litet team med en handfull tjänster blir det ofta mer maskineri än nyttan motiverar. Kubernetes lönar sig när komplexiteten redan är hög, inte som ett sätt att framtidssäkra en enkel produkt.

Ett scenario: när valet vänder

Föreställ er en startup med en applikation och ojämn trafik. Serverless är självklart: låg kostnad, ingen drift, teamet fokuserar på produkten. Så växer bolaget. Tjänsterna blir tiotals, lasten hög och jämn dygnet runt, och ett par komponenter kräver körningar längre än serverless tillåter. Nu börjar serverless-notan kännas, och begränsningarna skava. Vid någon punkt vänder kalkylen: kontrollen och den jämna kapaciteten som Kubernetes ger blir värd sin driftkostnad. Poängen är att valet inte är för livet – rätt svar kan ändras med storleken.

Mellanformerna som ofta är det egentliga svaret

Här är det viktigaste och mest förbisedda: valet är sällan de två extremerna. Mittemellan finns managerade containrar – tjänster som Cloud Run och Fargate.

Idén är att du paketerar din applikation i en container precis som i Kubernetes-världen, men slipper drifta själva Kubernetes-maskineriet. Leverantören kör och skalar åt dig, ofta ner till noll som serverless. Du får containervärldens flexibilitet med serverless-liknande enkelhet.

För en stor del av alla team är den mellersta raden det rätta svaret. Den ger flexibilitet utan Kubernetes fulla driftbörda, och skalar smidigt utan serverless snävaste begränsningar.

Så väljer du

Börja i serverless eller managerade containrar. De löser de flesta behov för mindre och medelstora produkter, med låg drift och betalning efter användning. Gå till Kubernetes när komplexiteten verkligen kräver det – många tjänster, behov av portabilitet, eller krav serverless inte klarar – och när ni har kompetensen att förvalta det.

Vill ni ha hjälp att välja rätt driftmodell för just er produkt tittar vi på Weapp gärna på det som en del av vår cloud-arkitektur. Hör av dig så resonerar vi kring vad som är rimligt innan ni bygger fast er i ett upplägg.