Wat is serverless? Serverless computing simpel uitgelegd

Serverless is een manier om code te draaien waarbij je zelf geen servers opzet of beheert. Je geeft je code aan een cloudprovider, en die draait die code alleen wanneer iets hem activeert — een webverzoek, een geüpload bestand, een betalingsmelding — en stopt daarna. Je betaalt meestal voor de tijd dat je code daadwerkelijk draait, niet voor een machine die stilstaat.

Waarom serverless ertoe doet bij het bouwen met AI

Als je met AI een app bouwt en naar hostingopties of code kijkt, kom je "serverless-functies", "edge-functies" of "cloudfuncties" tegen. Veel hostingplatforms bieden ze aan, en sommige AI-builders zetten backends zo op. Het model begrijpen helpt je bij drie praktische vragen:

• Kosten. Gaat je app geld kosten terwijl niemand hem gebruikt?
• Snelheid. Waarom is het eerste verzoek na een rustige periode trager?
• Limieten. Waarom liep een lange taak — een groot rapport genereren, een video verwerken — tegen een time-out aan?

Het helpt ook om te weten wat serverless niet is: het is niet de afwezigheid van een backend. Je hebt nog steeds code aan de serverkant; iemand anders draait alleen de machines. Voor de basis, zie wat een server is.

Een analogie uit het dagelijks leven

Een traditionele server is als een eigen auto hebben. Hij staat er altijd, klaar om meteen te rijden, maar je betaalt ervoor — verzekering, parkeren, onderhoud — of je hem nu gebruikt of niet.

Serverless is als een taxi bellen. Je betaalt alleen voor de ritten die je maakt, en als honderd mensen tegelijk een rit nodig hebben, komen er honderd taxi's. Maar de auto kan even op zich laten wachten (een koude start), elke rit heeft een maximale lengte, en de chauffeur herinnert zich je niet van je vorige rit (functies zijn stateless).

Hoe serverless-functies werken

In de meest voorkomende vorm, functions as a service genoemd:

1. Je schrijft een functie — een klein stukje code dat één soort gebeurtenis afhandelt, zoals "verwerk een POST naar /api/bookings."
2. Je zet hem live. De provider slaat hem op en koppelt hem aan een trigger: een URL, een schema, een nieuw bestand in opslag, een bericht in een wachtrij.
3. Er komt een gebeurtenis binnen. De provider start een kopie van je functie (of hergebruikt een warme), draait hem en geeft het resultaat terug.
4. Hij schaalt zelf. Als er duizend verzoeken tegelijk binnenkomen, draait de provider veel kopieën parallel, tot aan de limieten van je account.
5. Hij gaat slapen. Wanneer het verkeer stopt, worden kopieën afgesloten. Als er niets draait, betaal je niets voor rekenkracht.

Een kleine serverless-functie in JavaScript kan er zo uitzien:

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hello, ${name}` });
}

Er is geen code nodig om een server te starten, een poort te openen of een proces draaiend te houden. Het platform regelt dat allemaal.

"Serverless" wordt ook losser gebruikt voor andere beheerde diensten die automatisch schalen en per gebruik factureren — serverless databases bijvoorbeeld, die pauzeren wanneer ze stilstaan.

Belangrijke termen

Een uitgewerkt voorbeeld: een kleine boekingssite

De boekingssite van een yogastudio krijgt elke zondagavond een piek aan bezoekers, wanneer het nieuwe rooster online gaat, en de rest van de week heel weinig.

• Op een altijd aanstaande server betaalt de studio 24/7 voor een machine, gedimensioneerd op de piek van zondagavond, en die staat de rest van de tijd meestal stil.
• Met serverless-functies zijn GET /api/classes en POST /api/bookings functies. De zondagse drukte start automatisch veel kopieën; op een rustige dinsdagochtend draait bijna niets en is de rekening bijna nul.

De afwegingen komen ook naar voren. De eerste persoon die de site op dinsdagochtend opent, moet misschien heel even wachten op een koude start. De database moet veel kortstondige verbindingen aankunnen van veel functiekopieën, wat een connection pooler vereist. En als de studio later een taak wil als "het jaarlijkse aanwezigheids-pdf van iedereen genereren", kan die de tijdslimiet van de functie overschrijden en elders moeten draaien.

Wanneer serverless past — en wanneer niet

Veelvoorkomende misverstanden

• "Serverless betekent geen backend." Het betekent geen servers om te beheren. Je schrijft en beveiligt nog steeds backendcode.
• "Serverless is altijd goedkoper." Goedkoop bij laag volume, maar prijzen per verzoek kunnen oplopen bij hoog, constant volume.
• "Serverless schaalt oneindig." Platforms hebben limieten voor gelijktijdigheid, en je database kan lang voordat de functies dat doen het knelpunt worden.
• "Bestanden die in een functie worden opgeslagen, staan er de volgende keer nog." Lokale opslag is tijdelijk. Gebruik een database of bestandsopslag.
• "Schalen naar nul is hetzelfde als serverless." Verwant, maar niet identiek. Sommige platforms draaien je app als een gewone server die slaapt wanneer hij stilstaat en wakker wordt bij het volgende verzoek — vergelijkbare besparingen en een vergelijkbare vertraging bij het eerste verzoek, maar zonder functiestijl tijdslimieten per verzoek.

Wat je aan je AI-builder kunt vragen

• "Draait deze backend als serverless-functies, of als een altijd aanstaande of slapende server? Wat betekent dat voor de kosten?"
• "Zullen sommige taken langer duren dan de tijdslimiet van het platform? Zo ja, hoe moeten we die aanpakken?"
• "Sla alles wat moet blijven bestaan op in de database of bestandsopslag, niet in het geheugen of lokale bestanden."
• "Hoe moeten de databaseverbindingen worden beheerd als er veel kopieën tegelijk draaien?"
• "Hoe groot is de vertraging bij het eerste verzoek nadat de app stil heeft gestaan?"

Hoe Mythex apps host

Mythex beschrijft zijn hosting niet als serverless-functies. Wanneer je publiceert, draait je app als een gewone webapp of container die Mythex voor je beheert — er is geen hosting in te stellen. Het werkt op schalen naar nul: gepubliceerde apps en hun databases slapen wanneer ze stilstaan en worden wakker bij het volgende bezoek, een slapende app kost niets aan rekenkracht, en extra machines starten alleen wanneer het verkeer zwaar is (Pro staat maximaal 3 per service toe). De gekoppelde Postgres-database gaat ook slapen na 5 minuten inactiviteit en wordt gefactureerd voor de tijd dat hij wakker was. Zo krijg je veel van het voordeel "betalen voor wat je gebruikt", met dezelfde soort vertraging bij het eerste verzoek na een rustige periode. Zie hostinglimieten in de docs, en onze gidsen over webhosting en hostingkosten verlagen.

Veelgestelde vragen