Cloudflare Workers en AWS Lambda: meer dan koude starts

Cloudflare Workers past vaak bij korte API-verzoeken die dicht bij de gebruiker kunnen worden afgehandeld. AWS Lambda Event Functions ligt eerder voor de hand wanneer bestaande code een specifieke runtime, meer geheugen of nauwe toegang tot regionale AWS-diensten nodig heeft. De keuze hangt af van de volledige route van verzoek tot antwoord, niet alleen van de tijd die een functie nodig heeft om te starten.

Een Worker kan snel reageren op een eenvoudige authenticatiecontrole, maar alsnog wachten op een database in een andere regio. Een Lambda-functie kan dichter bij die database staan, terwijl de gebruiker een langere netwerkroute aflegt. Vergelijk daarom dezelfde taak met dezelfde databron: de afstand tot gebruiker en data, actieve rekentijd, wachttijd en kosten van gekoppelde diensten kunnen elk de uitkomst veranderen.

Wat zegt een koude start werkelijk?

Een snelle start is vooral waardevol wanneer de rest van het verzoek kort duurt. In onderzoek van Lin en collega’s rapporteerde Cloudflare voor een minimale Worker een verwerkingsoverhead onder zijn meetprecisie van 0,01 milliseconde; de geteste AWS Lambda-functie had gemiddeld ongeveer 1,17 milliseconde overhead bij het afhandelen van zo’n minimale aanroep. Bij de onderzochte Lambda-configuratie nam ook de kans op een koude start toe naarmate de functie langer ongebruikt bleef.

Die cijfers beschrijven verschillende onderdelen van de uitvoering. De verwerkingsoverhead van een functie die alleen een leeg antwoord terugstuurt, is geen meting van de volledige koude start of van de responstijd van een echte API. Zodra de code een database bevraagt, een externe dienst aanroept of een groter antwoord opbouwt, kan die stap veel langer duren dan de gemeten platformoverhead. Voor een zinvolle vergelijking horen de tijd tot de functie draait, de uitvoering van de code en de wachttijd op andere diensten afzonderlijk in beeld.

CPU en geheugen begrenzen de taak

Grote beeldverwerking als voorbeeld van een taak waarvoor de geheugen- en CPU-grenzen van Cloudflare Workers bepalend zijn.

Bij een HTTP-verzoek op Workers Paid geldt volgens de Workers-limieten standaard 30 seconden CPU-tijd, instelbaar tot maximaal vijf minuten; per isolate is 128 MB geheugen beschikbaar. Wachten op netwerkverkeer telt niet mee als CPU-tijd. Die geheugenruimte geldt voor de isolate en kan dus door gelijktijdige verzoeken worden gedeeld.

Een functie die lang op een externe API wacht, verbruikt daardoor niet automatisch veel Worker-CPU. Een taak die een groot bestand volledig in het geheugen laadt, kan juist vastlopen voordat haar rekentijd het probleem wordt. Streaming kan de geheugendruk van zo’n taak verlagen, maar maakt een berekening niet lichter. Voor wachtrijverwerking gelden bovendien andere uitvoeringsgrenzen dan voor een HTTP-verzoek: het type aanroep hoort dus bij de platformkeuze.

Lambda Event Functions laat meer geheugen aan een functie toewijzen en koppelt daar ook rekencapaciteit aan. Meer geheugen kan een rekenintensieve taak versnellen, maar verandert tegelijk de prijs per seconde. Daardoor is de goedkoopste geheugeninstelling niet vanzelf de goedkoopste uitvoering van de taak.

De runtime bepaalt hoeveel bestaande code meekan

De runtimes voor Lambda Event Functions omvatten onder meer Node.js, Python, Java, .NET en Ruby; eigen runtimes en containerimages bieden aanvullende mogelijkheden. Een bestaande toepassing met systeembibliotheken of native afhankelijkheden kan daardoor op Lambda eenvoudiger onder te brengen zijn. De gekozen taalversie en architectuur blijven wel onderdeel van de technische keuze.

Workers gebruikt V8-isolates en een omgeving rond web-API’s; WebAssembly en Python via Pyodide bieden aanvullende routes voor code buiten JavaScript. Dat maakt de naam van een programmeertaal op zichzelf geen bewijs dat een bestaand pakket werkt. Vooral native modules, bestandssysteemgebruik en de manier waarop een pakket verbindingen opent, verdienen aandacht. Voor een kleine nieuwe API kan de compacte Worker-omgeving passen; bij een bestaande toepassing kan de benodigde aanpassing zwaarder wegen dan een verschil in starttijd.

Waar staan de gebruiker en de data?

Workers draait standaard op het wereldwijde netwerk van Cloudflare, dicht bij de plek waar een verzoek binnenkomt. Een Lambda Event Function draait in de gekozen AWS-regio. Voor bezoekers in Nederland en Vlaanderen kan de eerste opzet gunstig zijn als de functie zonder regionale data antwoord geeft. Staat de database in een Europese AWS-regio, dan moet een Worker voor iedere benodigde raadpleging alsnog die afstand overbruggen.

Ook Workers kan dichter bij een achterliggende dienst worden geplaatst. Daarmee kan de wachttijd tussen functie en database dalen, terwijl de route tussen gebruiker en functie langer wordt. Het aantal heen-en-weergaande databaseverzoeken bepaalt mede of die verschuiving helpt. Een authenticatiecontrole met één lokale beslissing vraagt dus om een andere plaatsing dan een API die meerdere keren per verzoek regionale gegevens ophaalt.

Houd bij een vergelijking de databron en de gebruikerslocaties gelijk. Anders meet je tegelijk het verschil tussen platforms én het verschil tussen netwerkafstanden. Voor gegevens die in een specifieke Europese regio moeten blijven, moet bovendien duidelijk zijn waar verwerking en opslag plaatsvinden; een nabij toegangspunt zegt op zichzelf niets over de locatie van de achterliggende data.

Vergelijk de volledige rekening

Bij Workers Standard noemt de prijspagina van Cloudflare een minimumbedrag van $5 per maand, met 10 miljoen verzoeken en 30 miljoen CPU-milliseconden inbegrepen. Extra verzoeken en CPU-tijd worden afzonderlijk berekend; voor de duur van het wachten op netwerkverkeer rekent dit model geen afzonderlijke tijdskosten. Cloudflare vermeldt voor Workers ook geen aanvullende kosten voor uitgaand dataverkeer, terwijl bijvoorbeeld opslag en wachtrijen hun eigen verbruik kunnen hebben.

De Lambda-prijzen van AWS rekenen Event Functions per verzoek en uitvoeringsduur bij het toegewezen geheugen; het vrije maandelijkse gebruik omvat een miljoen verzoeken en 400.000 GB-seconden. De prijs hangt ook af van regio en architectuur. Provisioned Concurrency, dataverkeer buiten de regio en andere AWS-diensten kunnen kosten toevoegen. Lambda Web Functions hebben een ander model, met onder meer actieve CPU-tijd en verbruikt geheugen; hun tarieven horen niet bij een berekening voor Event Functions.

Vergelijk dus niet alleen twee functieregels op een factuur. Een publiek HTTP-eindpunt kan een toegangsdienst nodig hebben, en logs, opslag of een wachtrij kunnen bij beide ontwerpen meetellen. Vrije gebruiksruimte kan bovendien al door andere functies in hetzelfde account worden benut. Dat maakt een prijsvoorbeeld pas bruikbaar wanneer de omringende diensten en het verwachte gebruik vastliggen.

Wat verandert er per soort taak?

Een pakketbezorging als voorwaardelijk voorbeeld van een webhook waarvan de vervolgstappen de platformkeuze bepalen.

Publieke API. Neem als voorwaardelijk voorbeeld een miljoen verzoeken per maand, elk met 10 milliseconden actief rekenwerk en 400 milliseconden wachttijd op dezelfde externe dienst. Dat levert voor Workers 10 miljoen CPU-milliseconden op, binnen het genoemde inbegrepen gebruik van Standard. Een Lambda Event Function die per verzoek 410 milliseconden draait met 128 MB toegewezen geheugen, verbruikt rekenkundig 51.250 GB-seconden. Ook dat valt binnen de genoemde vrije gebruiksruimte, mits die nog beschikbaar is. Alleen al daardoor kan de functieprijs anders uitvallen dan een vergelijking van CPU-tijd doet vermoeden; de toegangsdienst en netwerkroute zijn nog niet meegerekend.

Webhook. Stel dat een bezorgdienst een statuswijziging doorgeeft. Voorwaardelijk geldt bij een miljoen meldingen met 5 milliseconden rekenwerk en 200 milliseconden wachten: Workers verbruikt 5 miljoen CPU-milliseconden, terwijl een Lambda Event Function bij 128 MB en 205 milliseconden uitvoeringsduur uitkomt op 25.625 GB-seconden. Als de ontvangstfunctie daarna een wachtrij vult en regionale systemen de wijziging verwerken, moeten ook die vervolgstappen worden betaald. Hun ligging en betrouwbaarheid kunnen dan belangrijker zijn dan de starttijd van de ontvangstfunctie.

Achtergrondtaak. Neem als voorwaardelijk voorbeeld beeldverwerking die op haar piek meer dan 128 MB geheugen nodig heeft. Die taak past niet ongewijzigd binnen de geheugenlimiet van een Worker-isolate; een Lambda Event Function kan met meer toegewezen geheugen wel een kandidaat zijn. Als streaming of het opdelen van werk de piek verlaagt, ontstaat opnieuw een keuze tussen beide platforms. Reken dan de gemeten uitvoeringsduur, actieve CPU-tijd, opslagbewegingen en eventuele wachtrij samen door: bij deze taak bepalen resourcegrenzen eerst wat uitvoerbaar is, en pas daarna wat voordelig is.