Serverloos rekenen: cloud zonder eigen servers te beheren
Stel je voor dat je een elektrische boormachine nodig hebt voor een klusje van tien minuten. Je koopt er geen aanschaft en onderhoudt geen eigen generator voor; je stopt de stekker in het stopcontact en betaalt alleen voor de stroom die je daadwerkelijk gebruikt. Serverloos rekenen werkt volgens hetzelfde principe, maar dan voor software: een bedrijf schrijft een stukje code, en pas op het moment dat iemand die code nodig heeft — bijvoorbeeld door op een knop te klikken in een app — wordt er ergens in een datacenter automatisch rekenkracht ingeschakeld om die taak uit te voeren.
De term "serverloos" is in zekere zin misleidend, want er draaien wel degelijk fysieke servers. Het verschil is dat de ontwikkelaar die servers niet zelf hoeft te bestellen, te installeren of te onderhouden. Een cloudleverancier — een bedrijf dat rekenkracht via internet aanbiedt, zoals Amazon of Google — regelt dat volledig op de achtergrond. De ontwikkelaar levert alleen de code aan en betaalt per gebruik, net zoals je bij elektriciteit betaalt per kilowattuur in plaats van voor een hele eigen energiecentrale.
Wat is het precies?
De kern van serverloos rekenen heet vaak Function as a Service, afgekort FaaS. Dat betekent dat een ontwikkelaar geen complete applicatie op een server zet die continu draait, maar losse functies uploadt: kleine stukjes code die één specifieke taak uitvoeren, zoals het verkleinen van een geüploade foto of het versturen van een bevestigingsmail.
Die functies worden pas uitgevoerd als er een concrete aanleiding is, een zogeheten event. Denk aan een klant die op "bestellen" klikt, een bestand dat wordt geüpload, of een tijdschema dat elke nacht om drie uur afgaat. Zolang er geen aanleiding is, gebeurt er niets en draait er ook geen rekenkracht — en wordt er dus niets in rekening gebracht.
Zodra een aanroep binnenkomt, start het cloudplatform automatisch een omgeving om de functie in uit te voeren, voert de code uit, en sluit die omgeving daarna weer af of houdt hem kort warm voor een volgende aanroep. Bij grote drukte start het platform vanzelf meerdere exemplaren tegelijk op; dit heet automatisch schalen. De klant hoeft dit niet zelf te configureren, in tegenstelling tot bij een traditionele server of zelfs een virtuele machine (een softwarematige nabootsing van een computer) of container (een lichtgewicht, afgeschermde omgeving om software in te draaien), waarbij iemand vooraf moet inschatten hoeveel capaciteit nodig is.
De afrekening gebeurt doorgaans per aanroep en per gebruikte rekentijd, gemeten in milliseconden. Dat is fundamenteel anders dan een traditionele server, die je huurt of koopt en die kosten maakt of hij nu gebruikt wordt of niet. Een bekend nadeel is de zogeheten cold start: als een functie een tijd niet is aangeroepen, moet het platform eerst een nieuwe uitvoeringsomgeving opstarten voordat de code kan draaien, wat een merkbare vertraging van tientallen tot honderden milliseconden kan geven.
Wat wil men ermee bereiken?
Het belangrijkste doel is dat ontwikkelaars zich kunnen concentreren op de functionaliteit van hun software, in plaats van op het beheren van servers, besturingssystemen en beveiligingsupdates. Dat werk, vaak aangeduid als "ops" (operations), wordt overgenomen door de cloudleverancier.
Een tweede doel is kostenefficiëntie. Bij traditionele servers betaal je vaak voor capaciteit die grotendeels ongebruikt blijft, bijvoorbeeld 's nachts of in rustige periodes. Bij serverloos rekenen betaal je in principe alleen voor het moment dat er daadwerkelijk iets wordt uitgevoerd.
Daarnaast belooft de aanpak betere schaalbaarheid bij piekbelasting, zoals een webshop tijdens Black Friday. Het platform schaalt vanzelf mee zonder dat iemand vooraf servers hoeft bij te bestellen. Tot slot hoopt men op snellere ontwikkelcycli: kleinere, onafhankelijke functies zijn vaak makkelijker apart te bouwen, testen en updaten dan één grote, monolithische applicatie.
Voorbeelden uit de praktijk
AWS Lambda, gelanceerd door Amazon in november 2014, geldt algemeen als het eerste grote commerciële FaaS-platform en zette de term serverloos rekenen op de kaart. Het bedrijf zelf noemt als voorbeeld dat het frisdrankmerk Coca-Cola Lambda gebruikte om de app achter slimme verkoopautomaten te bouwen; dit voorbeeld komt uit AWS-marketingmateriaal en is niet onafhankelijk geverifieerd.
Google Cloud Functions verscheen als bètaversie in 2016-2017 en werd in 2018 algemeen beschikbaar gemaakt. Microsoft Azure Functions volgde een vergelijkbaar tijdpad met een lancering in 2016. Beide platforms bieden functionaliteit die sterk lijkt op AWS Lambda, met eigen integraties in het bijbehorende cloudecosysteem.
Cloudflare Workers, geïntroduceerd in 2017, koos een andere technische aanpak: in plaats van elke functie in een aparte container te draaien, gebruikt Cloudflare zogeheten V8-isolates — lichtgewicht, geïsoleerde stukjes geheugen binnen dezelfde JavaScript-engine die ook in de Chrome-browser zit. Dat maakt koude starts aanzienlijk sneller en past bij het idee van edge computing: de code draait op servers dicht bij de gebruiker, verspreid over honderden locaties wereldwijd, in plaats van in één centraal datacenter.
Voor wie niet afhankelijk wil zijn van één cloudleverancier bestaat Knative, een open-source project dat mede door Google is geïnitieerd en in 2018 werd uitgebracht. Knative maakt het mogelijk om serverloze functies te draaien bovenop Kubernetes, een populair open-source systeem voor het beheren van containers, zodat organisaties serverless-achtige voordelen kunnen krijgen op hun eigen infrastructuur.
Hoe ver is de techniek?
Serverloos rekenen is geen experimentele technologie meer. Sinds ongeveer 2018-2020 wordt het breed commercieel toegepast, van kleine start-ups tot grote ondernemingen, en alle grote cloudleveranciers bieden inmiddels volwaardige FaaS-diensten aan.
Toch zijn er reële beperkingen die eerlijkheidshalve genoemd moeten worden. Het cold-start-probleem is verminderd maar niet verdwenen, vooral bij talen en omgevingen die van nature langzamer opstarten. Er is daarnaast een risico op vendor lock-in: omdat elke cloudleverancier zijn eigen API's en integraties gebruikt, is het overstappen van bijvoorbeeld AWS naar Google Cloud vaak een flinke technische operatie, geen kwestie van code kopiëren.
Ook gelden er praktische grenzen: functies mogen meestal niet langer dan een paar minuten draaien en krijgen een beperkte hoeveelheid geheugen toegewezen, waardoor serverloos rekenen ongeschikt is voor langdurige berekeningen of taken die veel geheugen vasthouden tussen aanroepen. Het debuggen en monitoren van een applicatie die uit tientallen losse functies bestaat, is bovendien lastiger dan bij één samenhangende applicatie, omdat een enkele gebruikersactie door meerdere onafhankelijke stukjes code kan lopen.
Belangrijk is dat serverloos rekenen zelden een volledige vervanging is van traditionele servers. In de praktijk combineren veel organisaties beide vormen: serverloze functies voor pieken en losstaande taken, traditionele of container-gebaseerde servers voor de kern van hun applicatie. De markt groeit nog altijd, maar van een volledige verdringing van klassieke servers is geen sprake.
Wie werken eraan?
De grootste spelers zijn de gevestigde Amerikaanse cloudleveranciers: Amazon Web Services met AWS Lambda, Google Cloud met Cloud Functions en het verwante Cloud Run, en Microsoft Azure met Azure Functions. Deze drie domineren de markt voor bedrijfskritische toepassingen.
Cloudflare heeft met Workers een eigen niche opgebouwd rond snelheid en edge computing. IBM biedt IBM Cloud Functions aan, gebaseerd op het open-source project Apache OpenWhisk. In China is Alibaba Cloud met Function Compute een belangrijke aanbieder, naast vergelijkbare diensten van Tencent.
Op het gebied van open standaarden en gedeelde infrastructuur speelt de Cloud Native Computing Foundation (CNCF) een centrale rol. Deze non-profitorganisatie, onderdeel van de grotere Linux Foundation, ondersteunt open-sourceprojecten zoals Knative en de CloudEvents-standaard, die beschrijft hoe verschillende systemen op een uniforme manier events met elkaar kunnen uitwisselen. Geografisch ligt het zwaartepunt van de ontwikkeling bij Amerikaanse techbedrijven, met China als tweede belangrijke regio via Alibaba en Tencent.