Serverless eller tradisjonelle servere?
Serverless betyr at du betaler per kall og slipper å drifte servere, mens tradisjonell drift innebærer at du betaler for kapasitet døgnet rundt. Serverless vinner ved ujevn eller lav last, tradisjonell drift ved høy og jevn belastning. Ta hensyn til cold starts og leverandørinnlåsing før du velger driftsmodell.
Serverless mot tradisjonell drift er i bunn og grunn et spørsmål om hvordan du betaler for og tar ansvar for datakraft. Bak de tekniske begrepene skjuler det seg et enkelt veivalg: å leie kapasitet hver gang den trengs, eller å holde kapasitet i gang og betale for den. Her er sammenligningen målt i kostnad og ansvar.
De to modellene
Tradisjonell drift innebærer at du har servere, egne eller leide i skyen, som går døgnet rundt. Du betaler for kapasiteten uansett om den brukes, og du (eller leverandøren din) har ansvaret for å installere, skalere og vedlikeholde dem. Du har full kontroll og full forutsigbarhet, men også fullt ansvar.
Serverless snur det på hodet. Skyleverandøren tar seg av serverne, koden din kjøres bare når den kalles, og du betaler per kjøring. Serverne finnes fortsatt («serverless» er delvis en misvisende merkelapp), men de er ikke ditt problem. Du slipper drift og skalering, mot at du gir fra deg en del kontroll.
Forskjellen i ansvar er halve historien. Den andre halvdelen er økonomien, og der blir det konkret.
Økonomien: betale per kall mot betale for kapasitet
Kjernen er enkel. Serverless er betal per kall: Står tjenesten stille, koster den nesten null. Ved en topp skalerer den opp automatisk, og du betaler for akkurat den trafikken. Tradisjonell drift er betal for kapasitet: Serveren koster det samme døgnet rundt, uansett om den håndterer tusen kall eller ingen i det hele tatt.
Hvilken som er billigst, avgjøres av formen på lasten. To regneeksempler gjør det tydelig:
- Ujevn last. En intern rapporttjeneste som kjøres noen ganger om dagen. Med serverless betaler du bare for disse kjøringene, i praksis småpenger. En server som går døgnet rundt for den samme jobben, betaler du for i 24 timer for å bruke den i minutter.
- Jevn, høy last. Et populært API som tar imot millioner av kall hvert døgn, jevnt fordelt. Her kan summen av alle avgiftene per kall bli høyere enn det en håndfull servere i kontinuerlig drift ville ha kostet. Ved forutsigbar, tung last vinner ofte kapasitet du holder i gang.
| Lastprofil | Oftest billigst |
|---|---|
| Lav eller ujevn (støtvis, sjelden) | Serverless |
| Høy og jevn (konstant trafikk) | Tradisjonell drift |
| Uforutsigbar med kraftige topper | Serverless (skalerer automatisk) |
Baksidene ved serverless: cold starts og innlåsing
Ved ujevn last høres serverless nesten for bra ut, så det er verdt å være ærlig om prisen.
Cold starts. Når en funksjon har stått ubrukt, må den startes opp ved neste kall, og den første kjøringen får en forsinkelse. For en bakgrunnsjobb spiller det ingen rolle. Men for en brukernær tjeneste der responstiden merkes umiddelbart, kan den ekstra forsinkelsen ved første kall være et reelt irritasjonsmoment.
Leverandørinnlåsing. Serverless-tjenester er ofte tett vevd inn i én bestemt skyleverandørs måte å fungere på. Bygger du mye av logikken din på den måten, blir du avhengig av akkurat den plattformen, og å flytte senere blir et større prosjekt. Det er håndterbart, men det er en binding du bør gå inn i med åpne øyne.
Hvilke arbeidslaster hører hjemme hvor
Grovt inndelt: Serverless passer for det hendelsesstyrte og det ujevne. Bakgrunnsjobber, planlagte oppgaver, API-er med sporadisk eller sterkt varierende trafikk og nye tjenester der du ennå ikke kjenner volumet: Alt dette trives i en modell som koster etter bruk og skalerer av seg selv.
Tradisjonell drift passer for det tunge og jevne. Tjenester som kjører konstant, som er følsomme for den minste forsinkelse, eller der du vil ha full kontroll og en helt forutsigbar månedskostnad, hører hjemme på kapasitet du holder i gang. Det er også fullt mulig å kombinere: la en stabil kjerne kjøre tradisjonelt og legge støtvise jobber på serverless.
Det finnes altså ikke noe universelt riktig svar, bare det som passer til hvordan systemet deres faktisk belastes. Vil dere ha hjelp til å analysere lastprofilen og regne på hva den betyr for kostnadene, ser vi i Weapp gjerne på driftsvalget sammen med dere før dere låser dere til en modell.
Ofte stilte spørsmål
Hva betyr egentlig serverless?
Serverless betyr ikke at det ikke finnes servere, men at skyleverandøren tar seg av dem for deg. Koden din kjøres bare når den kalles, og du betaler per kjøring, ikke for oppetid. Serverne finnes, men de er ikke ditt ansvar: Du slipper å installere, skalere og vedlikeholde dem.
Når blir serverless billigere enn tradisjonell drift?
Når lasten er ujevn eller lav. Betaler du per kall, koster en tjeneste som mest brukes støtvis, nesten ingenting når den står stille, og den skalerer automatisk ved topper. En tradisjonell server faktureres døgnet rundt uansett om noen bruker den, noe som blir dyrt for arbeidslaster som sjelden brukes.
Når vinner tradisjonell drift i stedet?
Ved høy og jevn last. Når en tjeneste brukes konstant og mye, kan den faste kostnaden for en server som går døgnet rundt, bli lavere enn å betale per kall for millioner av kall. Ved forutsigbar, tung belastning er kapasitet du eier, ofte mer økonomisk enn kapasitet du leier per gang.
Hva er cold starts, og hvorfor betyr de noe?
En cold start er forsinkelsen når en serverless-funksjon starter fra hvile etter å ha stått ubrukt. Det første kallet kan ta merkbart lengre tid før koden svarer. For bakgrunnsjobber spiller det ingen rolle, men for en tjeneste der hvert millisekund merkes for brukeren, kan det være et reelt problem.
Hva innebærer leverandørinnlåsing med serverless?
Serverless-tjenester er ofte tett knyttet til én bestemt skyleverandørs måte å fungere på. Bygger du mye logikk på den måten, blir det vanskeligere og dyrere å flytte til en annen leverandør senere. Det diskvalifiserer ikke løsningen, men det er en risiko du bør vurdere før du bygger stort på én enkelt plattform.