Serverless eller traditionelle servere?
Serverless betyder at du betaler pr. kald og slipper for at passe servere. Traditionel drift indebærer at du betaler for kapacitet døgnet rundt. Serverless vinder ved ujævn eller lav belastning, traditionel drift ved høj og jævn belastning. Tag cold starts og leverandørlåsning med i overvejelserne før du vælger driftsmodel.
Serverless mod traditionel drift er grundlæggende et spørgsmål om hvordan du betaler for og tager ansvar for regnekraft. Bag de tekniske ord gemmer sig et enkelt valg: leje kapacitet hver gang der er brug for den, eller holde kapacitet kørende og betale for den. Her er sammenligningen målt i omkostninger og ansvar.
De to modeller
Traditionel drift betyder at du har servere, egne eller lejede i skyen, som kører døgnet rundt. Du betaler for kapaciteten uanset om den bliver brugt, og du (eller din leverandør) har ansvaret for at installere, skalere og vedligeholde dem. Du har fuld kontrol og fuld forudsigelighed, men også det fulde ansvar.
Serverless vender det om. Cloududbyderen passer serverne, din kode kører kun når den bliver kaldt, og du betaler pr. kørsel. Serverne findes stadig (“serverless” er til dels en misvisende betegnelse), men de er ikke dit problem. Du slipper for drift og skalering, men til gengæld opgiver du en del af kontrollen.
Forskellen i ansvar er halvdelen af historien. Den anden halvdel er økonomien, og der bliver det konkret.
Økonomien: betaling pr. kald mod betaling for kapacitet
Kernen er enkel. Serverless er betal pr. kald: Står tjenesten stille, koster den tæt på nul, og ved en spidsbelastning skalerer den automatisk op, og du betaler for netop den trafik. Traditionel drift er betal for kapacitet: Serveren koster det samme døgnet rundt uanset om den kører tusind kald eller slet ingen.
Hvilken model der er billigst, afgøres af belastningens form. To regneeksempler gør det tydeligt:
- Ujævn belastning. En intern rapporttjeneste der kører nogle gange om dagen. Med serverless betaler du kun for de kørsler, i praksis småpenge. En server der kører døgnet rundt til samme job, betaler du for i 24 timer for at bruge den i minutter.
- Jævn, høj belastning. Et populært API der modtager millioner af kald hvert døgn, jævnt fordelt. Her kan summen af alle gebyrer pr. kald overstige hvad en håndfuld servere der kører konstant, ville have kostet. Ved forudsigelig tung belastning trækker kapacitet du holder kørende, ofte det længste strå.
| Belastningsprofil | Oftest billigst |
|---|---|
| Lav eller ujævn (stødvis, sjældent) | Serverless |
| Høj og jævn (konstant trafik) | Traditionel drift |
| Uforudsigelig med kraftige spidser | Serverless (skalerer automatisk) |
Bagsiderne ved serverless: cold starts og lock-in
Serverless lyder næsten for godt i det ujævne tilfælde, så det er værd at være ærlig om prisen.
Cold starts. Når en funktion har stået ubrugt, skal den startes op ved det næste kald, og den første kørsel får en forsinkelse. For et baggrundsjob betyder det ingenting. Men for en brugervendt tjeneste hvor svartiden mærkes med det samme, kan den ekstra forsinkelse ved det første kald være et reelt irritationsmoment.
Leverandørlåsning. Serverless-tjenester er ofte tæt vævet ind i en bestemt cloududbyders måde at fungere på. Bygger du meget af din logik på den måde, bliver du afhængig af netop den platform, og at flytte senere bliver et større projekt. Det kan håndteres, men det er en binding du skal gå ind i med åbne øjne.
Hvilke workloads hører hjemme hvor
Groft sagt passer serverless til det hændelsesstyrede og det ujævne. Baggrundsjob, planlagte opgaver, API’er med sporadisk eller kraftigt svingende trafik og nye tjenester hvor du endnu ikke kender volumen: Alt det trives i en model der koster efter forbrug og skalerer af sig selv.
Traditionel drift passer til det tunge og jævne. Tjenester der kører konstant, som er følsomme over for den mindste forsinkelse, eller hvor du vil have fuld kontrol og en helt forudsigelig månedlig omkostning, hører hjemme på kapacitet du holder kørende. Det er også fuldt ud muligt at blande: lade en stabil kerne køre traditionelt og lægge stødvise job på serverless.
Der findes altså ikke et universelt rigtigt svar, kun det der passer til hvordan jeres system faktisk belastes. Vil I have hjælp til at aflæse belastningsprofilen og regne på hvad den betyder for regningen, kigger vi i Weapp gerne på valget af drift sammen med jer før I låser jer fast på en model.
Ofte stillede spørgsmål
Hvad betyder serverless egentlig?
Serverless betyder ikke at der ikke er nogen servere, men at cloududbyderen passer dem for dig. Din kode kører kun når den bliver kaldt, og du betaler pr. kørsel i stedet for at betale for oppetid. Serverne findes, men de er ikke dit ansvar: Du slipper for at installere, skalere og vedligeholde dem.
Hvornår bliver serverless billigere end traditionel drift?
Når belastningen er ujævn eller lav. Betaler du pr. kald, koster en tjeneste der mest bruges stødvis, næsten ingenting når den står stille, og den skalerer automatisk ved spidsbelastninger. En traditionel server faktureres døgnet rundt uanset om nogen bruger den, og det bliver dyrt for workloads der sjældent kører.
Hvornår vinder traditionel drift i stedet?
Ved høj og jævn belastning. Når en tjeneste bruges konstant og meget, kan den faste omkostning ved en server der kører døgnet rundt, blive lavere end at betale pr. kald for millioner af kald. Ved forudsigelig, tung belastning er kapacitet du ejer, ofte mere økonomisk end kapacitet du lejer pr. gang.
Hvad er cold starts, og hvorfor betyder de noget?
En cold start er forsinkelsen når en serverless-funktion starter fra hvile efter at have stået ubrugt. Det første kald kan tage mærkbart længere tid før koden svarer. For baggrundsjob betyder det ingenting, men for en tjeneste hvor hvert millisekund mærkes af brugeren, kan det være et reelt problem.
Hvad indebærer leverandørlåsning med serverless?
Serverless-tjenester er ofte tæt knyttet til en bestemt cloududbyders måde at fungere på. Bygger du meget logik på den måde, bliver det sværere og dyrere at flytte til en anden udbyder senere. Det diskvalificerer ikke løsningen, men det er en risiko at tage med i overvejelserne før du bygger stort på én enkelt platform.