Container Apps vs AKS vs App Service: Een Besliskader

In dit artikel

• De Drie Opties
• Het Besliskader
• Wanneer Welke Gebruiken
• App Service: Eenvoudige Webapplicaties
• Container Apps: Microservices, Event-Driven en API’s
• AKS: Complexe Orchestratie en Volledige Controle
• Container Apps Features Die Je Moet Kennen
• Het Anti-Pattern: De Over-Engineering Taks
• Het Migratiepad: Progressieve Complexiteit
• VNet-Integratie en Beveiliging
• Slotgedachten

Microsoft heeft net Azure Container Apps general availability aangekondigd op Build 2022. Het is een serverless container platform gebouwd op Kubernetes dat het volledige clusterbeheer wegabstraheert. Jij levert een container image aan, Container Apps doet de rest.

Dit verandert het gesprek over container hosting op Azure. Tot nu toe was de keuze binair: App Service als je eenvoud wilt, AKS als je orchestratie nodig hebt. Container Apps vult de leemte die er altijd al was: een platform voor teams die meer nodig hebben dan App Service, maar geen Kubernetes cluster willen (of kunnen) beheren.

Wij draaien al jaren workloads op alle drie de services. Zo denken wij over de keuze.

De Drie Opties

Voordat we in het framework duiken, een korte samenvatting van wat elke service precies is.

Azure App Service is een PaaS web hosting platform. Het draait containers, maar in de kern is het een beheerde web application host. Je krijgt ingebouwde deployment slots, authenticatie, custom domains en TLS, allemaal te configureren via de portal of je favoriete IaC-tool. Het is de oudste van de drie en de meest mature.

Azure Container Apps is een serverless container platform. Onder de motorkap draait het op Kubernetes (specifiek een AKS cluster beheerd door Microsoft), maar je ziet of raakt het cluster nooit aan. Het is specifiek gebouwd voor microservices, API’s, background processors en event-driven workloads. De belangrijkste differentiators zijn KEDA-based autoscaling, Dapr-integratie en scale-to-zero.

Azure Kubernetes Service (AKS) is managed Kubernetes. Microsoft beheert het control plane; jij beheert de rest: node pools, networking, RBAC, ingress controllers, service meshes, monitoring agents en upgrade cycles. Je krijgt volledige toegang tot de Kubernetes API en kunt alles draaien wat het ecosysteem ondersteunt.

Azure docs: Container Apps overview · App Service overview · AKS overview

Het Besliskader

Dit is de tabel die we met klanten doorlopen wanneer ze container hosting op Azure evalueren.

Dimensie	App Service	Container Apps	AKS
Abstractieniveau	Hoog - beheerde PaaS	Gemiddeld - serverless containers	Laag - managed Kubernetes
Kubernetes-kennis	Niet nodig	Niet nodig	Vereist
Scale-to-zero	Nee (always-on instances)	Ja (KEDA-based)	Manueel (KEDA + node autoscaler)
Kostenmodel	Always-on App Service Plan	Betalen per vCPU/memory seconden	Node pool VMs + control plane
Networking	VNet-integratie (outbound)	Container Apps Environment (VNet)	Volledige VNet-controle (CNI/kubenet)
Ingress	Ingebouwd (HTTPS, custom domains)	Ingebouwd (Envoy-based)	BYO (NGINX, Traefik, AGIC)
CI/CD-integratie	Deployment Center, GitHub Actions	Revisions, GitHub Actions, Azure Pipelines	Helm, Kustomize, GitOps (Flux/ArgoCD)
Multi-container	Beperkt (sidecar preview)	Ja (sidecar containers)	Volledige pod spec
Custom operators/CRDs	Nee	Nee	Ja
Service mesh	Nee	Dapr (ingebouwd)	Istio, Linkerd, of eender welke mesh
Opstarttijd	Snel (warm instances)	Cold start mogelijk	Snel (pods op warme nodes)

Het patroon is duidelijk: naarmate je van links naar rechts gaat, win je controle en verlies je eenvoud. De vraag is waar jouw workload op dat spectrum zit.

Azure docs: Container Apps vs other Azure container options · AKS vs Container Apps

Wanneer Welke Gebruiken

App Service: Eenvoudige Webapplicaties

App Service is de juiste keuze wanneer je een webapplicatie of API draait die in een standaardpatroon past: een .NET API, een Node.js frontend, een Python Flask app. Je wilt TLS, custom domains, deployment slots en nul infrastructuur-gedoe.

Gebruik App Service wanneer:

• Je workload een enkele webapplicatie of API is
• Je geen scale-to-zero nodig hebt (het verkeer is consistent genoeg om always-on te rechtvaardigen)
• Je team niet vertrouwd is met containers en dat ook niet wil zijn
• Je ingebouwde authenticatie-integratie nodig hebt (Easy Auth)
• Deployment slots en traffic splitting belangrijk zijn voor je releaseproces

Container Apps: Microservices, Event-Driven en API’s

Container Apps is de sweet spot voor de meeste moderne cloud-native workloads. Als je microservices bouwt, events verwerkt van queues of topics, background jobs draait of API’s host die dynamisch moeten schalen: dit is waar je moet beginnen.

Gebruik Container Apps wanneer:

• Je meerdere services hebt die met elkaar moeten communiceren (microservices)
• Je scale-to-zero wilt voor kostenoptimalisatie bij bursty workloads
• Je events verwerkt van Azure Service Bus, Kafka, Storage Queues of andere event sources
• Je Dapr wilt voor service invocation, state management of pub/sub zonder een volledige service mesh te adopteren
• Je revision management nodig hebt voor blue-green of canary deployments
• Je team Docker images kan bouwen, maar geen Kubernetes wil beheren

AKS: Complexe Orchestratie en Volledige Controle

AKS is voor teams die Kubernetes echt nodig hebben. Dat betekent custom operators, CRDs, specifieke CNI plugins, service mesh configuraties of compliance-eisen die cluster-level controle vereisen.

Gebruik AKS wanneer:

• Je custom Kubernetes operators of CRDs nodig hebt
• Je een specifieke service mesh nodig hebt (Istio, Linkerd) met volledige configuratiecontrole
• Je workloads GPU scheduling, advanced node affinity of custom scheduler plugins vereisen
• Je stateful workloads draait die persistent volume management nodig hebben dat verder gaat dan wat Container Apps biedt
• Regelgevende of compliance-eisen cluster-level audit controls vereisen
• Je een dedicated platform team hebt dat Kubernetes kan beheren

Azure docs: When to use Container Apps · AKS baseline architecture

Container Apps Features Die Je Moet Kennen

Container Apps bundelt meerdere mogelijkheden die weken zouden kosten om op te zetten op raw AKS.

KEDA-based autoscaling. Container Apps gebruikt KEDA onder de motorkap voor event-driven scaling. Je configureert scale rules declaratief: schalen op HTTP concurrent requests, queue length, CPU, memory of eender welke van KEDA’s 50+ scalers. Scale-to-zero is de standaard, wat betekent dat je niets betaalt wanneer er geen verkeer is.

Dapr-integratie. Dapr wordt als sidecar ingeschakeld met een enkele configuratievlag. Dit geeft je service-to-service invocation, state management, pub/sub messaging en bindings, allemaal zonder Dapr aan je container image toe te voegen of Dapr-infrastructuur te beheren.

Revision management. Elke deployment creert een nieuwe revision. Je kunt verkeer splitsen tussen revisions voor canary deployments, meerdere revisions tegelijkertijd draaien en direct rollbacken. Dit is hetzelfde concept als Cloud Run revisions of App Service deployment slots, maar dan voor containers.

Ingebouwde ingress. Container Apps gebruikt Envoy als ingress controller. Je krijgt HTTPS, custom domains en traffic splitting zonder een ingress controller te deployen of te beheren. External ingress stelt de app bloot aan het internet. Internal ingress maakt de app alleen beschikbaar binnen de Container Apps Environment.

Azure docs: Scaling in Container Apps · Dapr integration · Revisions in Container Apps

Het Anti-Pattern: De Over-Engineering Taks

De meest voorkomende fout die we zien is teams die AKS kiezen terwijl Container Apps een betere keuze zou zijn geweest. Wij noemen dit de over-engineering taks.

Zo ziet het er in de praktijk uit. Een team moet vijf microservices draaien die berichten verwerken van Service Bus en een REST API aanbieden. Ze kiezen AKS omdat “we misschien later Kubernetes features nodig hebben.” Zes maanden later besteden twee engineers 30% van hun tijd aan het beheren van cluster upgrades, node pool scaling, ingress controller configuraties en certificate rotation. De applicatiecode is niet veranderd, maar de infrastructuur-overhead heeft het team opgeslokt.

AKS is een krachtig platform. Het is ook een operationeel commitment. Het control plane is beheerd, maar alles daarboven niet. Node pool OS patching, Kubernetes version upgrades, network policy management, RBAC-configuratie, monitoring agent deployment, ingress controller lifecycle: dat alles valt onder de verantwoordelijkheid van jouw team.

Container Apps elimineert deze hele categorie werk. Voor het scenario van vijf microservices en een queue, deploy je Container Apps op een namiddag en schaalt het ‘s nachts naar nul. AKS deploy je in een week en kost je 24/7 node pool VMs.

De vraag die je moet stellen is niet “zouden we Kubernetes features kunnen gebruiken?” Het is: “hebben we vandaag Kubernetes features nodig, en hebben we een team dat Kubernetes verantwoord kan beheren?”

Het Migratiepad: Progressieve Complexiteit

Een van de beste dingen aan het Azure container ecosysteem is dat het migratiepad duidelijk gedefinieerd en incrementeel is.

App Service naar Container Apps. Als je App Service workload al gecontaineriseerd is, is de stap naar Container Apps rechttoe rechtaan. De belangrijkste wijzigingen zijn de ingress-configuratie en het scaling model. Environment variables, secrets en managed identity werken vergelijkbaar. Je wint scale-to-zero en KEDA-based scaling. Je verliest deployment slots (vervangen door revisions) en Easy Auth (vervangen door manuele auth of Dapr middleware).

Container Apps naar AKS. Omdat Container Apps op Kubernetes draait, vertaalt het mentale model zich direct. Je container images, environment variables en scaling concepten dragen allemaal over. Je zult je eigen ingress controller moeten configureren, monitoring opzetten en de cluster lifecycle beheren, maar de applicatielaag blijft dezelfde. Als je Dapr gebruikte op Container Apps, kun je Dapr op AKS deployen en je applicatiecode ongewijzigd houden.

Dit incrementele pad betekent dat je kunt starten met de eenvoudigste optie die aan je eisen voldoet en alleen opschaalt wanneer je tegen een echte beperking aanloopt. Dat is het tegenovergestelde van starten met AKS en de operationele kosten vanaf dag een dragen.

Azure docs: Migrate from App Service to Container Apps · Container Apps environments

VNet-Integratie en Beveiliging

Container Apps worden gedeployd in een Container Apps Environment, dat de beveiligings- en netwerkgrens vormt voor je apps. Je hebt twee opties:

External environment: de omgeving heeft een publiek endpoint. Individuele apps kunnen geconfigureerd worden met external of internal ingress. Dit is de eenvoudigste optie en werkt voor public-facing API’s en services.

Internal environment: de omgeving wordt gedeployd in een VNet zonder publiek endpoint. Alle ingress is privaat. Dit is het patroon voor enterprise workloads die binnen de bedrijfsnetwerkgrens moeten blijven.

Voor internal environments wordt de Container Apps Environment geinjecteerd in een dedicated subnet in je VNet. Uitgaand verkeer gaat via het VNet en is onderhevig aan je NSGs en route tables. Inkomend verkeer vereist een reverse proxy (Application Gateway, Azure Front Door of een custom oplossing) voor het interne endpoint.

Dit model is vergelijkbaar met App Service Environment (ASE), maar zonder de aanzienlijke kostenoverhead. Een ASE begint op ruwweg 1000 USD/maand alleen al voor de stamp. Een Container Apps internal environment kost niets bovenop de resources die je apps verbruiken.

DNS-configuratie is belangrijk bij internal environments. De Container Apps Environment krijgt een statisch IP en een standaard domain. Je moet Private DNS zones configureren om het domain van de omgeving te resolven naar het interne IP binnen je VNet.

Azure docs: Container Apps networking · Container Apps with internal VNet · Private DNS zones

Slotgedachten

Azure Container Apps vult een leemte die bestond sinds de lancering van AKS. Niet elke gecontaineriseerde workload heeft Kubernetes nodig, en niet elk team zou een cluster moeten beheren.

Begin met de eenvoudigste optie die aan je eisen voldoet. App Service voor standaard web apps. Container Apps voor microservices, event-driven workloads en API’s die baat hebben bij scale-to-zero. AKS wanneer je de Kubernetes API echt nodig hebt en het team hebt om het te ondersteunen.

Kies het platform waarmee je product kunt shippen, niet het platform dat zelf een project wordt.