Serverless

Je app gaat viraal op TikTok.
Van 10 naar 100.000 gebruikers in één uur.

Wat gebeurt er met je ene VM?  En wie betaalt de 20 VM's die je voor de zekerheid klaarzet… als de hype voorbij is?

Leerdoelen

Na deze les kan je:

• uitleggen wat serverless is en hoe het verschilt van IaaS, containers en PaaS
• een event-driven architectuur beschrijven en queue, pub/sub, event bus en stream onderscheiden
• de belangrijkste serverless bouwstenen bij AWS, GCP en Azure benoemen
• beperkingen zoals cold starts, limieten en vendor lock-in inschatten
• een kostenraming maken en beargumenteren wanneer serverless (niet) past
• een eenvoudige serverless architectuur ontwerpen

Wie beheert wat?

Hoe verder naar rechts, hoe minder je beheert. Code, data en configuratie blijven altijd jouw verantwoordelijkheid.

Definitie

Serverless computing refers to the concept of building and running applications that do not require server management. […] Applications are executed, scaled, and billed in response to the exact demand needed at the moment.

• "Serverless" is een misnomer: er zijn wel servers, alleen beheer jij ze niet.
• Geen capacity planning, patching, fault tolerance of schalen van VM's of containers.
• Stateless: een instance kan elk moment verdwijnen, dus state bewaar je extern (database, storage).
• Scale to zero: geen gebruik = geen draaiende resources.
• Pay per use: je betaalt voor wat je effectief verbruikt.

Serverless is meer dan functions

Een serverless architectuur = FaaS als lijm tussen BaaS-bouwstenen, verbonden door events

Event-driven architecture

De bouwstenen

• Event: een feit dat gebeurd is ("order 123 geplaatst"). Onveranderlijk, in de verleden tijd.
• Event producer: publiceert events zonder te weten wie ze ontvangt.
• Event broker: ontvangt, buffert en routeert events (queue, topic, bus of stream).
• Event consumer: abonneert zich op events en reageert erop, vaak een serverless function.
• Services communiceren indirect en asynchroon: loose coupling.

Voordelen en nadelen

Queue, pub/sub, event bus of stream?

In de praktijk combineer je ze, bv. EventBridge → SQS → Lambda.

Voorbeeld: multi-tenant SaaS

Berichten komen (minstens) één keer aan

def handle(event):
    # al verwerkt? dan niets doen
    if processed.exists(event["id"]):
        return
    create_invoice(event["data"])
    processed.add(event["id"])
								

Overzicht: wie noemt het hoe?

Functions

Zo ziet een function eruit

import functions_framework

@functions_framework.http
def hello(request):
    name = request.args.get("name", "student")
    return {"message": f"Hallo {name}!"}
								

def lambda_handler(event, context):
    name = event.get("queryStringParameters",
                     {}).get("name", "student")
    return {"statusCode": 200,
            "body": f"Hallo {name}!"}
								

gcloud run deploy hello --source . --function hello \
    --base-image python313 --region europe-west1 --allow-unauthenticated
						

Triggers

• HTTP: een request van een browser, app of API gateway
• Storage: bestand opgeladen of verwijderd
• Messaging: bericht op een queue of topic (SQS, Pub/Sub…)
• Schedule: cron (EventBridge Scheduler, Cloud Scheduler)
• Database changes: DynamoDB Streams, Firestore triggers, Cosmos DB change feed

CloudEvents: open CNCF-standaard voor het beschrijven van events (GCP Eventarc, Azure Event Grid)

Een event in CloudEvents-formaat

{
  "specversion": "1.0",
  "type": "google.cloud.storage.object.v1.finalized",
  "source": "//storage.googleapis.com/projects/_/buckets/videos-raw",
  "id": "8413216547019243",
  "time": "2026-09-28T09:30:00Z",
  "datacontenttype": "application/json",
  "data": { "bucket": "videos-raw", "name": "kat-op-skateboard.mp4" }
}
						

gcloud eventarc triggers create video-uploaded \
    --location=europe-west1 \
    --destination-run-service=transcoder \
    --event-filters="type=google.cloud.storage.object.v1.finalized" \
    --event-filters="bucket=videos-raw" \
    --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com
						

Deployen: van klikken naar code

resource "google_cloud_run_v2_service" "api" {
  name     = "video-api"
  location = "europe-west1"

  template {
    containers {
      image = "europe-west1-docker.pkg.dev/my-proj/apps/video-api:1.0"
    }
    scaling {
      min_instance_count = 0   # scale to zero
      max_instance_count = 10  # kostenplafond!
    }
  }
}
								

Limieten

Past je taak niet binnen deze grenzen? Kies dan een job (Cloud Run jobs, AWS Batch, Container Apps jobs) of een container.

Cold starts

• Eerste request na een stilte = extra latency (van ~100 ms tot enkele seconden).
• Beperken: kleine packages, lichte runtime, init buiten de handler voor hergebruik.
• Vermijden: min instances (Cloud Run), provisioned concurrency / SnapStart (Lambda), always ready (Azure). Maar dan betaal je ook als het stil is!

API gateway: de voordeur

• AWS API Gateway
• GCP API Gateway, Apigee
• Azure API Management

• Eén publiek endpoint voor tientallen functions of services
• Authenticatie (JWT, OAuth, API keys) vóór je code draait
• Rate limiting en quota: bescherming tegen misbruik én tegen een onverwachte factuur
• Routing, versioning, caching en request validatie

Workflows: choreography vs. orchestration

Vuistregel: choreography tussen domeinen, orchestration voor een proces binnen één domein (bv. bestelling → betaling → verzending).

Serverless databases

• Betalen per request / opslag in plaats van per server-uur
• Let op: een "wakker wordende" database geeft ook een cold start
• Duizenden function-instances × een DB-connectie = connection storm. Gebruik een proxy of HTTP-API.

Data warehousing

• AWS Redshift Serverless, Athena
• GCP BigQuery
• Azure Microsoft Fabric

Betalen per gescande data of per verbruikte compute

Demo: BigQuery

Object storage

• AWS S3
• GCP Cloud Storage
• Azure Blob Storage

Oneindig schaalbaar, betalen per GB, per request en voor egress. Vaak de bron van events.

Demo: GCP bucket

Serverless containers

• AWS Fargate (ECS/EKS), Lambda met container images
• GCP Cloud Run (services en jobs)
• Azure Container Apps (services en jobs)

• Elke taal, elke library, elk binair bestand: als het in een container past, draait het
• Geen lock-in op het programmeermodel: dezelfde image draait ook op Kubernetes
• Let op: Fargate = geen servers beheren, maar geen scale to zero. Serverless is een spectrum.

Demo: Cloud Run

• Scale from 0 (!) tot honderden instances; stel zelf een max in
• Tot 1000 gelijktijdige requests per instance
• Snelle start (meestal < enkele seconden); min instances tegen cold starts
• Elke deploy = nieuwe revision: traffic splitting voor canary en blue/green
• Tot 8 vCPU / 32 GiB per instance, en optioneel GPU's voor AI-inferencing
• Ingebouwde HTTPS-URL, TLS-certificaten en custom domains
• Isolatie via sandbox: gVisor (1e generatie) of microVM (2e generatie)

Demo!

Security in serverless

• Least privilege: elke function krijgt een eigen service account / role, met enkel de rechten die ze nodig heeft
• Secrets nooit in code of environment variables in Git, wel in Secrets Manager, Secret Manager of Key Vault
• Event injection: ook een event uit een bucket of queue is onbetrouwbare input, dus valideer alles
• Dependencies: je hebt geen OS meer om te patchen, maar wel libraries (supply chain)
• Denial of wallet: een aanvaller hoeft je niet plat te leggen, hij kan je gewoon laten betalen. Gebruik rate limits, max instances en budget alerts.

Observability

Voorbeeld: microservices op AWS

Voorbeeld: web app op Azure

Voorbeeld: parkeerdata Gent op GCP

Hoe betaal je voor een function?

kost = #requests × prijs per request
+ uitvoeringstijd × geheugen (GB-seconden) × prijs per GB-s

• Voorbeeld Lambda (x86, us-east-1): $0,20 per miljoen requests en $0,0000166667 per GB-s
• Maandelijkse free tier: 1 miljoen requests en 400.000 GB-s
• Meer geheugen = ook meer CPU, dus soms sneller én goedkoper

Rekenvoorbeeld

API-function: 512 MB geheugen, 200 ms per request

• Weinig of grillig verkeer: serverless wint ruim.
• Constant hoog verkeer: een VM, container of Cloud Run met concurrency is goedkoper.
• Vergeet de TCO niet: wie patcht, monitort en schaalt die VM's? Engineeringuren kosten ook geld.

Verborgen kosten

• API Gateway: per miljoen requests, soms duurder dan de function zelf
• Data transfer / egress: data die de cloud verlaat (video's!)
• Logging: elke log-regel van miljoenen invocations wordt opgeslagen en gefactureerd
• NAT gateways en private networking
• Recursieve loops: een function die schrijft in de bucket die haar triggert…

Zet altijd budget alerts en max instances!

Wanneer wel, wanneer niet?

Case: Prime Video (2023)

• Een tool die de kwaliteit van videostreams monitort, gebouwd met Step Functions en Lambda
• Probleem: per seconde video tientallen state transitions en veel data via S3 tussen de stappen. Dat was duur en schaalde slecht.
• Oplossing: alles samengevoegd in één proces in containers (ECS)
• Resultaat: 90% goedkoper

Les: niet "serverless is slecht", maar kies per workload het juiste model

Vendor lock-in

• Het risico zit niet in de function, maar in de bouwstenen eromheen: triggers, IAM, DynamoDB, Step Functions…
• Beperken:
  • Containers (Cloud Run, Container Apps) in plaats van provider-specifieke function-formaten
  • Open standaarden: CloudEvents, OpenTelemetry, Kafka-API
  • Open-source platformen: Knative, OpenFaaS, KEDA op eigen Kubernetes
  • Hexagonale architectuur: businesslogica los van de handler
• Maar: lock-in is een afweging, geen doodzonde. Snelheid van ontwikkelen heeft ook waarde.

Quiz: serverless of niet?

Case study: videoplatform

Opdracht: ontwerp een basic YouTube-alternatief, volledig serverless.

Denkvragen

• Een video van 2 GB: moet die door je function? (payload limits!)
• Wat start de preprocessing, en wie weet wanneer die klaar is?
• Transcoderen duurt 20 minuten. Past dat in een function?
• Views tellen = extreem veel kleine writes. Welke database?
• Hoe krijg je data in het datalake zonder de app te vertragen?
• Wat kost het als één video viraal gaat? (egress!)

Referentie-oplossing

Referentie-oplossing per provider

Wat kan er misgaan?

• Dubbel event → video twee keer getranscodeerd: maak de job idempotent
• Transcoding faalt → retries + dead-letter queue + status "mislukt" voor de gebruiker
• Output in de input-bucket → oneindige lus en een astronomische factuur
• Virale video → CDN vangt de load op; zonder CDN betaal je de volle egress
• Hot partition: één video met miljoenen views in één database-record → tellers bufferen of sharden
• Misbruik → upload-limieten, quota per gebruiker, rate limiting, budget alerts

Trends

• Serverless AI: modellen aanroepen via een API (Amazon Bedrock, Vertex AI, Microsoft Foundry), en GPU's op Cloud Run / Container Apps voor eigen modellen
• Edge functions: code draait in honderden locaties dicht bij de gebruiker (Cloudflare Workers, CloudFront Functions, Lambda@Edge)
• WebAssembly: lichte sandboxes met cold starts in microseconden
• Scale-to-zero databases: Aurora Serverless v2, Aurora DSQL, Neon
• Durable execution: workflows als gewone code (Durable Functions, Temporal)
• Steeds meer diensten worden serverless: logging-analyse, security (IDS), ML-pipelines, Kafka…

Samenvatting

Serverless is geen doel, maar een keuze per workload

Verder lezen

• CNCF Serverless Whitepaper
• AWS Well-Architected: Serverless Applications Lens
• Serverless Land: patterns en voorbeelden
• Google Cloud Run documentatie
• Azure Functions documentatie
• CloudEvents · Knative · OpenTelemetry

Volgende stap: aan de slag in het labo!