Serverloze apps op Azure: praktische handleiding voor beginners

Een serverloze app op Azure is een toepassing waarbij code of workflows worden uitgevoerd door beheerde Azure-services, zonder dat het ontwikkelteam zelf servers hoeft te provisioneren, patchen of schalen.

Voor Belgische ontwikkelteams is serverless vooral interessant wanneer een applicatie reageert op gebeurtenissen: een HTTP-aanvraag, een bestand dat in Blob Storage verschijnt, een bericht op een queue, een geplande taak of een integratie tussen bedrijfssystemen. De architectuur blijft echter niet vanzelf eenvoudig. Wie een eerste proof-of-concept bouwt, moet al vroeg nadenken over hostingplan, lokale configuratie, deployment, kostenbewaking, logging en gegevensbescherming.

Azure biedt daarvoor meerdere bouwstenen. Azure Functions voert code uit op basis van triggers en bindingen. Azure Logic Apps is geschikt voor visuele workflowautomatisering en integraties met SaaS- en bedrijfsapplicaties. In veel projecten vullen ze elkaar aan: Functions voor compacte code en maatwerklogica, Logic Apps voor procesorkestratie en connectoren.

Wanneer serverless een goede eerste keuze is

Serverless past goed bij workloads die wisselend, gebeurtenisgedreven of relatief klein van omvang zijn. Voorbeelden zijn het verwerken van uploads, het versturen van notificaties, het synchroniseren van gegevens tussen systemen, het uitvoeren van geplande controles of het aanbieden van een eenvoudige API voor een mobiele of webapplicatie. Het team hoeft vooraf geen servercapaciteit te reserveren en kan sneller valideren of de oplossing functioneel werkt.

Dat betekent niet dat elke applicatie automatisch beter serverless wordt. Langlopende taken, processen met een constante hoge belasting en workloads die een zeer voorspelbare latency vereisen, vragen meer ontwerpkeuzes. Soms blijft een container, een App Service of een dedicated compute-model eenvoudiger te beheren. De kracht van Azure Functions zit vooral in heldere grenzen: één functie doet één taak, reageert op één soort trigger en schrijft alleen de noodzakelijke output weg.

Een eenvoudige architectuur voor een eerste serverless app kan bestaan uit een HTTP-trigger voor inkomende aanvragen, een Storage Queue voor asynchrone verwerking, Blob Storage voor bestanden, Application Insights voor observability en Key Vault voor geheimen. Wie later een publieke API aanbiedt, kan Azure API Management toevoegen voor throttling, authenticatiebeleid, versiebeheer en een consistente gatewaylaag.

De ontwikkelomgeving lokaal opzetten

Een eerste Azure Function kan rechtstreeks in de Azure Portal worden gemaakt, maar voor serieus ontwikkelwerk is lokale ontwikkeling betrouwbaarder. Het team kan code reviewen, testen automatiseren, configuratie scheiden per omgeving en deployments herhalen. Een praktische setup bestaat uit Visual Studio Code of een andere editor, Azure Functions Core Tools, een ondersteunde runtime zoals .NET, Node.js of Python, en Azurite voor lokale Storage-emulatie.

Azure Functions v4 is de gangbare runtimebasis voor nieuwe projecten. De gekozen programmeertaal bepaalt de projectstructuur en tooling, maar het werkpatroon blijft vergelijkbaar: lokaal initialiseren, een trigger toevoegen, lokaal starten, de functie testen, daarna pas resources in Azure aanmaken. Dit voorkomt een veelgemaakte beginnersfout: experimenteren in de portal, daarna niet meer precies weten welke configuratie nodig was om de app reproduceerbaar te maken.

De belangrijkste configuratievalkuil zit vaak in AzureWebJobsStorage. Functions heeft een geldig Storage-account nodig voor runtime-state, triggers en interne coördinatie. Lokaal kan Azurite worden gebruikt, terwijl productie een echt Storage-account vereist. Het bestand local.settings.json hoort niet in bronbeheer wanneer het secrets of connection strings bevat; voor cloudomgevingen horen gevoelige waarden in Key Vault of in app settings die via Managed Identity worden benaderd.

Onderstaand voorbeeld gebruikt Azure Functions Core Tools om een HTTP-trigger te maken. Het doel is niet om een volledige applicatie te bouwen, maar om de minimale ontwikkelcyclus zichtbaar te maken: project aanmaken, functie toevoegen, lokaal uitvoeren en de endpoint testen.

Example — lokale HTTP-trigger met Azure Functions Core Tools

func init be-serverless-demo --worker-runtime dotnet
cd be-serverless-demo
func new --name HelloHttp --template "HTTP trigger" --authlevel "function"
func start

Na het starten toont de terminal de lokale URL van de functie. Een test met een browser of HTTP-client bevestigt dat de runtime werkt voordat er Azure-resources worden aangemaakt. Wanneer de functie lokaal niet start, ligt de oorzaak vaak bij een ontbrekende runtime, een niet-actieve Azurite-instantie of een foutieve waarde voor AzureWebJobsStorage.

Een Blob-trigger is een logische tweede stap omdat die laat zien hoe serverless reageert op data-events. De functie wordt dan uitgevoerd wanneer een bestand in een container verschijnt. In productie is het belangrijk dat de verwerking idempotent is: hetzelfde bestand of event kan opnieuw worden aangeboden, en de functie moet daar veilig mee omgaan zonder dubbele boekingen, dubbele e-mails of corrupte output.

Example — Blob-trigger toevoegen voor bestandsverwerking

func new --name ProcessUpload --template "Azure Blob Storage trigger"

# Voor lokale tests met Azurite:
# AzureWebJobsStorage=UseDevelopmentStorage=true

De gegenereerde functie bevat een binding naar Blob Storage. Het team moet daarna de containernaam, het padpatroon en de verwerking invullen. Bij echte bedrijfsdata is het verstandig om alleen technische metadata te loggen en geen persoonsgegevens of volledige bestandsinhoud naar logs te schrijven.

Deployment naar Azure: portal, CLI en CI/CD

Voor een eerste demonstratie is de Azure Portal bruikbaar: een resource group, Storage-account, Function App en Application Insights-resource kunnen snel worden aangemaakt. Toch verdient een herhaalbare aanpak de voorkeur zodra meer dan één ontwikkelaar betrokken is. Azure CLI, Bicep, Terraform, GitHub Actions of Azure DevOps verminderen configuratiedrift tussen test, acceptatie en productie.

Een minimale Azure CLI-deployment maakt duidelijk welke cloudresources echt nodig zijn. De regio verdient aandacht voor Belgische teams. West Europe en North Europe zijn gangbare EU-regio’s voor veel Azure-workloads, maar de keuze moet worden afgestemd op latency, dataresidentie, beschikbaarheid van services en interne compliance-afspraken. Daarbij hoort ook een naamgevings- en taggingconventie, zodat kosten en eigenaarschap later traceerbaar blijven.

Example — Function App aanmaken met Azure CLI

az group create \
  --name rg-be-serverless-demo \
  --location westeurope

az storage account create \
  --name stbeserverlessdemo01 \
  --resource-group rg-be-serverless-demo \
  --location westeurope \
  --sku Standard_LRS

az functionapp create \
  --name func-be-serverless-demo \
  --resource-group rg-be-serverless-demo \
  --storage-account stbeserverlessdemo01 \
  --consumption-plan-location westeurope \
  --runtime dotnet \
  --functions-version 4

Dit maakt een resource group, Storage-account en Function App aan in West Europe op een consumption-gebaseerde configuratie. In een productieomgeving horen aanvullende keuzes thuis, zoals Application Insights, netwerkrestricties, Managed Identity, Key Vault-referenties en deployment slots waar het gekozen hostingplan dat ondersteunt.

CI/CD voorkomt dat deployments afhankelijk worden van handmatige stappen. Een GitHub Actions-workflow kan bij elke wijziging bouwen, testen en naar Azure publiceren. Secrets zoals publish profiles of federated identity-configuratie horen in GitHub Encrypted Secrets of, waar mogelijk, in een identity-gebaseerd model zonder langlevende secrets. Voor teams die al Microsoft tooling gebruiken, is Azure DevOps een gelijkwaardig alternatief.

Example — compacte GitHub Actions-workflow voor build en deploy

name: Deploy Azure Function

on:
  push:
    branches: [ main ]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '8.0.x'
      - run: dotnet build --configuration Release
      - uses: Azure/functions-action@v1
        with:
          app-name: func-be-serverless-demo
          package: .
          publish-profile: ${{ secrets.AZURE_FUNCTIONAPP_PUBLISH_PROFILE }}

De workflow laat de basis zien, maar productieomgevingen vragen meestal extra stappen: unit tests, dependency scanning, environment approvals en gescheiden app settings per omgeving. Een veelgemaakte fout is om connection strings in repositorybestanden of workflow YAML te plaatsen. Die configuratie hoort buiten de code, met zo weinig mogelijk rechten en met duidelijke rotatie-afspraken.

Het juiste hostingplan kiezen

Het hostingplan bepaalt hoe de functie schaalt, welke netwerkmogelijkheden beschikbaar zijn, hoe cold starts zich gedragen en hoe kosten ontstaan. Beginners kiezen vaak automatisch voor Consumption omdat het eenvoudig en kostenbewust lijkt, maar dat is niet altijd de juiste keuze. De workloadvorm is belangrijker dan de naam van het plan.

Een pragmatische regel is om met Consumption te starten wanneer de workload kort, eventgedreven en tolerant voor variabele opstarttijd is. Premium wordt logischer wanneer gebruikerservaring, private networking of voorspelbare latency belangrijker worden. Dedicated past beter wanneer er al vaste capaciteit draait of wanneer de functie in een breder App Service-model moet landen.

Cold starts zijn vooral zichtbaar bij sporadisch gebruikte HTTP-functies. Mogelijke mitigaties zijn een Premium-plan met pre-warmed instances, een timer-trigger die periodiek initialisatiepaden activeert, of het verplaatsen van gebruikerskritische paden naar een model met warmere capaciteit. Lange processen horen zelden in één HTTP-trigger. Queue-gebaseerde verwerking of Durable Functions is vaak robuuster wanneer een workflow meerdere stappen, retries of statusbeheer nodig heeft.

Kosten inschatten en bewaken in EUR

Serverless verlaagt de drempel om te starten, maar maakt kosten niet automatisch voorspelbaar. De belangrijkste kostenfactoren zijn het aantal executions, de uitvoeringsduur, het geheugengebruik, opslagtransacties, netwerkverkeer en observability-data in Application Insights of Log Analytics. De Azure Pricing Calculator kan deze factoren in EUR modelleren voor West Europe of North Europe, zonder dat het team vaste bedragen hoeft te raden.

Een nuttige oefening is om drie scenario’s te modelleren: een laag proof-of-concept-volume, een normale productiedag en een piekdag. Daarbij hoort ook een inschatting van gemiddelde uitvoeringstijd en geheugenprofiel. Een functie die weinig wordt aangeroepen maar lang draait, kan duurder uitvallen dan een functie met veel korte executions. Logs kunnen eveneens een merkbare kostenpost worden wanneer elke payload volledig wordt vastgelegd.

Cost Management is daarom geen administratieve stap achteraf. Budgetalerts, tags zoals environment, owner en costcenter, en aparte resource groups per omgeving maken duidelijk waar kosten ontstaan. Voor proof-of-concepts is een expliciet budget met alerts vaak belangrijker dan technische optimalisatie; het voorkomt dat testresources weken blijven draaien zonder eigenaar.

Monitoring, logging en GDPR-aandachtspunten

Observability is bij serverless anders dan bij servergebaseerde applicaties. Het team kan niet inloggen op een server om processen te bekijken; telemetry, metrics en traces zijn de primaire bron van waarheid. Azure Monitor en Application Insights geven inzicht in afhankelijkheden, fouten, responstijden en gebruikspatronen. Log Analytics maakt query’s over logs en metrics mogelijk wanneer incidentanalyse meer detail vereist.

Voor Belgische en Europese teams hoort GDPR vanaf het begin in het loggingontwerp. De keuze voor EU-regio’s ondersteunt dataresidentie, maar lost niet alles op. Logs kunnen persoonsgegevens bevatten als ontwikkelaars volledige request bodies, e-mailadressen, rijksregisternummers, klantreferenties of documentinhoud registreren. De veiligere aanpak is dat functies correlation IDs, technische statuscodes en minimale metadata loggen, terwijl gevoelige inhoud buiten telemetry blijft.

Application Insights en Log Analytics vragen ook om retentiebeleid. Een korte retentie kan voldoende zijn voor debugging en incidentonderzoek, terwijl audit- of compliancebehoeften afzonderlijk moeten worden beoordeeld. Teams moeten daarnaast sampling bewust configureren: te veel sampling kan incidentanalyse verzwakken, te weinig sampling kan kosten en datavolumes verhogen.

Secrets vormen een tweede GDPR- en security-risico. Connection strings in code, screenshots of local.settings.json kunnen snel buiten de juiste context terechtkomen. Managed Identity in combinatie met Key Vault is meestal veiliger dan langlevende secrets in configuratiebestanden. Wanneer een function toegang nodig heeft tot Azure SQL Database of Storage, moet die identiteit alleen de noodzakelijke rechten krijgen.

Veelgemaakte fouten bij eerste serverless projecten

De meeste problemen in beginnende serverless projecten ontstaan niet door Azure Functions zelf, maar door aannames rond configuratie en uitvoeringstijd. Een functie die lokaal werkt, faalt in Azure als de app settings ontbreken. Een HTTP-trigger die in demo’s snel genoeg is, loopt vast zodra hij een lang proces synchroon uitvoert. Een queue-handler die niet idempotent is, veroorzaakt dubbele verwerking wanneer retries optreden.

Een sterk eerste ontwerp houdt rekening met die operationele realiteit. Lange taken worden achter een queue geplaatst. Externe afhankelijkheden krijgen timeouts en retrybeleid. App settings worden per omgeving beheerd. Deployment gebeurt via pipeline in plaats van losse portalwijzigingen. Deze discipline is ook de reden waarom een trainingstraject rond Azure bij Readynez de nadruk legt op zowel platformbegrip als uitvoerbare praktijk: beginners hebben meer nodig dan kennis van knoppen in de portal.

Er is ook een organisatorische valkuil. Serverless verlaagt de infrastructuurdrempel, waardoor teams soms te laat governance betrekken. Naming, tagging, RBAC, logretentie, budgetalerts en data-classificatie lijken klein bij een proof-of-concept, maar ze bepalen of de oplossing later zonder herbouw naar productie kan.

Waar serverless op Azure logisch verder groeit

Een eerste serverless app hoeft niet groot te zijn. Een HTTP-trigger, Blob-trigger, Storage-account, Application Insights en een eenvoudige deployment pipeline zijn voldoende om het model te begrijpen. Daarna wordt de volgende stap bepaald door het probleem: API-beheer, workflowautomatisering, database-integratie, event routing of strengere netwerkisolatie.

Teams die serverless breder willen inzetten, doen er goed aan de leerroute te koppelen aan echte workloads. Een proof-of-concept rond factuurverwerking, datavalidatie of notificaties maakt trade-offs zichtbaar die in abstracte voorbeelden verborgen blijven. Wie dieper wil bouwen aan Azure-kennis kan verder lezen in meer Azure serverless-artikelen of formele Microsoft-training verkennen via Readynez Microsoft-training.

De key takeaway is dat serverless succesvol wordt wanneer code, configuratie, kosten en compliance samen worden ontworpen. Azure Functions maakt de start eenvoudig, maar de kwaliteit van de oplossing komt uit herhaalbare deployment, minimale logging van gevoelige data, passend hostingplan en duidelijke operationele grenzen.