Serverless er godt. Bare ikke til alt

Serverless lyder næsten som om infrastrukturen forsvinder. Det gør den selvfølgelig ikke. Det, der forsvinder, er en del af det arbejde, teamet ellers selv skulle stå for.

Cloud-platformen håndterer provisioning, skalering og en større del af driften, mens man typisk betaler efter faktisk brug. Det kan være virkelig smart. Men kun hvis workloaden passer til modellen.

Hvor vi typisk bruger serverless

Event-drevne processer er et oplagt eksempel. En fil lander i et storage-område, en ordre oprettes, en webhook modtages eller et natligt job skal behandle data. Her kan en lille serverless-funktion være både enklere og billigere end at holde en service kørende hele tiden.

Det samme kan gælde API'er med meget ujævn trafik eller afgrænsede integrationer, hvor belastningen kommer i korte bølger.

Hvor vi er mere forsigtige

Hvis et system har konstant høj belastning, meget lange processer eller stramme latency-krav, kan traditionelle services eller containere være enklere. Og jo mere en løsning bindes til en bestemt cloud-platforms specialservices, desto dyrere kan det blive at flytte den senere.

Cold starts er sjældent hele diskussionen

Cold starts bliver ofte brugt som argument både for og imod serverless. I praksis afhænger betydningen af runtime, konfiguration, platform og krav til svartid. Vi vil hellere måle på den konkrete løsning end gøre det til en trosretning.

Serverless og microservices er ikke modsætninger

En microservice kan sagtens være serverless. Et større system kan også kombinere containere, managed databaser og enkelte funktioner. Det behøver ikke være arkitektonisk rent for at være godt.

Vores tommelfingerregel

Vi bruger serverless, når det fjerner reel driftskompleksitet eller passer naturligt til belastningen. Vi bruger det ikke bare for at få en moderne tegning i arkitekturdiagrammet. Løsningen skal stadig være til at forstå, drive og ændre om tre år.