Container Apps vs AKS vs App Service : un cadre de decision

Dans cet article

• Les trois options
• Le cadre de decision
• Quand utiliser chaque option
• App Service : applications web simples
• Container Apps : microservices, event-driven et API
• AKS : orchestration avancee et controle total
• Fonctionnalites de Container Apps a connaitre
• L’anti-pattern : la taxe de la sur-ingenierie
• Le chemin de migration : complexite progressive
• Integration VNet et securite
• Conclusion

Microsoft vient d’annoncer la disponibilite generale d’Azure Container Apps lors de Build 2022. Il s’agit d’une plateforme serverless de conteneurs construite sur Kubernetes qui abstrait entierement la gestion du cluster. Vous fournissez une image de conteneur, Container Apps s’occupe du reste.

Cela change la conversation sur l’hebergement de conteneurs dans Azure. Jusqu’a present, la decision etait binaire : App Service si vous voulez de la simplicite, AKS si vous avez besoin d’orchestration. Container Apps comble le vide qui a toujours existe, une plateforme pour les equipes qui ont besoin de plus qu’App Service mais qui n’ont pas besoin (ou envie) d’operer un cluster Kubernetes.

Nous faisons tourner des workloads sur ces trois services depuis des annees. Voici comment nous abordons la decision.

Les trois options

Avant de plonger dans le cadre de decision, un bref resume de ce que chaque service propose concretement.

Azure App Service est une plateforme PaaS d’hebergement web. Elle execute des conteneurs, mais son identite principale est celle d’un hote d’applications web manage. Vous beneficiez de deployment slots integres, d’authentification, de domaines personnalises et de TLS, le tout configurable via le portail ou votre outil d’IaC prefere. C’est le plus ancien des trois et le plus mature.

Azure Container Apps est une plateforme serverless de conteneurs. Elle fonctionne sur Kubernetes sous le capot (plus precisement, un cluster AKS gere par Microsoft), mais vous ne voyez jamais le cluster et n’interagissez jamais avec lui. Elle est concue pour les microservices, les API, les processeurs en arriere-plan et les workloads event-driven. Les differenciateurs cles sont l’autoscaling base sur KEDA, l’integration Dapr et le scale-to-zero.

Azure Kubernetes Service (AKS) est du Kubernetes manage. Microsoft gere le control plane ; vous gerez tout le reste : les node pools, le networking, le RBAC, les ingress controllers, les service meshes, les agents de monitoring et les cycles de mise a jour. Vous avez un acces complet a l’API Kubernetes et pouvez executer tout ce que l’ecosysteme supporte.

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

Le cadre de decision

Voici le tableau que nous parcourons avec nos clients lorsqu’ils evaluent l’hebergement de conteneurs sur Azure.

Dimension	App Service	Container Apps	AKS
Niveau d’abstraction	Eleve, PaaS manage	Moyen, conteneurs serverless	Bas, Kubernetes manage
Connaissances Kubernetes	Pas necessaires	Pas necessaires	Requises
Scale-to-zero	Non (instances always-on)	Oui (base sur KEDA)	Manuel (KEDA + node autoscaler)
Modele de cout	App Service Plan always-on	Paiement par secondes vCPU/memoire	VM de node pool + control plane
Networking	Integration VNet (sortant)	Container Apps Environment (VNet)	Controle VNet complet (CNI/kubenet)
Ingress	Integre (HTTPS, domaines personnalises)	Integre (base sur Envoy)	BYO (NGINX, Traefik, AGIC)
Integration CI/CD	Deployment Center, GitHub Actions	Revisions, GitHub Actions, Azure Pipelines	Helm, Kustomize, GitOps (Flux/ArgoCD)
Multi-container	Limite (sidecar en preview)	Oui (sidecar containers)	Full pod spec
Custom operators/CRDs	Non	Non	Oui
Service mesh	Non	Dapr (integre)	Istio, Linkerd, ou tout autre mesh
Temps de demarrage	Rapide (instances warm)	Cold start possible	Rapide (pods sur des nodes warm)

Le schema est simple : en allant de gauche a droite, vous gagnez en controle et perdez en simplicite. La question est de savoir ou se situe votre workload sur ce spectre.

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

Quand utiliser chaque option

App Service : applications web simples

App Service est le bon choix lorsque vous executez une application web ou une API qui suit un schema standard : une API .NET, un frontend Node.js, une application Python Flask. Vous voulez du TLS, des domaines personnalises, des deployment slots et zero reflexion sur l’infrastructure.

Utilisez App Service quand :

• Votre workload est une application web ou une API unique
• Vous n’avez pas besoin de scale-to-zero (le trafic est suffisamment constant pour justifier le always-on)
• Votre equipe ne connait pas les conteneurs et ne souhaite pas s’y mettre
• Vous avez besoin de l’integration d’authentification integree (Easy Auth)
• Les deployment slots et le traffic splitting sont importants pour votre processus de release

Container Apps : microservices, event-driven et API

Container Apps est le point d’equilibre pour la plupart des workloads cloud-native modernes. Si vous construisez des microservices, traitez des evenements depuis des queues ou des topics, executez des jobs en arriere-plan, ou hebergez des API qui doivent scaler dynamiquement, c’est ici qu’il faut commencer.

Utilisez Container Apps quand :

• Vous avez plusieurs services qui doivent communiquer (microservices)
• Vous voulez le scale-to-zero pour optimiser les couts sur des workloads a trafic variable
• Vous traitez des evenements provenant d’Azure Service Bus, Kafka, Storage Queues ou d’autres sources d’evenements
• Vous voulez Dapr pour le service invocation, le state management ou le pub/sub sans adopter un service mesh complet
• Vous avez besoin de la gestion des revisions pour des deployments blue-green ou canary
• Votre equipe sait construire des images Docker mais ne veut pas gerer Kubernetes

AKS : orchestration avancee et controle total

AKS est fait pour les equipes qui ont reellement besoin de Kubernetes. Cela signifie : custom operators, CRDs, plugins CNI specifiques, configurations de service mesh, ou des exigences de conformite qui imposent un controle au niveau du cluster.

Utilisez AKS quand :

• Vous avez besoin de custom Kubernetes operators ou de CRDs
• Vous necessitez un service mesh specifique (Istio, Linkerd) avec un controle total sur la configuration
• Vos workloads requierent du GPU scheduling, du node affinity avance, ou des plugins de scheduler personnalises
• Vous executez des workloads stateful qui necessitent une gestion des persistent volumes au-dela de ce que Container Apps propose
• Des exigences reglementaires ou de conformite imposent des controles d’audit au niveau du cluster
• Vous avez une equipe plateforme dediee capable d’operer Kubernetes

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

Fonctionnalites de Container Apps a connaitre

Container Apps regroupe plusieurs capacites qui prendraient des semaines a mettre en place sur un AKS brut.

Autoscaling base sur KEDA. Container Apps utilise KEDA sous le capot pour le scaling event-driven. Vous configurez les regles de scaling de maniere declarative : scalez sur les requetes HTTP concurrentes, la longueur de la queue, le CPU, la memoire, ou n’importe lequel des 50+ scalers de KEDA. Le scale-to-zero est le comportement par defaut, ce qui signifie que vous ne payez rien quand il n’y a pas de trafic.

Integration Dapr. Dapr s’active en tant que sidecar avec un seul flag de configuration. Cela vous donne le service-to-service invocation, le state management, le pub/sub messaging et les bindings, le tout sans ajouter Dapr a votre image de conteneur ni gerer l’infrastructure Dapr.

Gestion des revisions. Chaque deploiement cree une nouvelle revision. Vous pouvez repartir le trafic entre les revisions pour des deployments canary, executer plusieurs revisions simultanement et effectuer un rollback instantanement. C’est le meme concept que les revisions de Cloud Run ou les deployment slots d’App Service, mais pour les conteneurs.

Ingress integre. Container Apps utilise Envoy comme ingress controller. Vous obtenez HTTPS, les domaines personnalises et le traffic splitting sans deployer ni gerer d’ingress controller. L’ingress externe expose l’application sur Internet. L’ingress interne la rend accessible uniquement au sein du Container Apps Environment.

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

L’anti-pattern : la taxe de la sur-ingenierie

L’erreur la plus courante que nous observons, c’est des equipes qui choisissent AKS alors que Container Apps aurait ete un meilleur choix. Nous appelons cela la taxe de la sur-ingenierie.

Voici a quoi cela ressemble en pratique. Une equipe doit faire tourner cinq microservices qui traitent des messages depuis Service Bus et exposent une API REST. Ils choisissent AKS parce que “on pourrait avoir besoin des fonctionnalites Kubernetes plus tard.” Six mois apres, deux ingenieurs passent 30 % de leur temps a gerer les mises a jour du cluster, le scaling des node pools, les configurations de l’ingress controller et la rotation des certificats. Le code applicatif n’a pas change : c’est l’overhead d’infrastructure qui a consume l’equipe.

AKS est une plateforme puissante. C’est aussi un engagement operationnel. Le control plane est gere, mais tout ce qui se trouve au-dessus ne l’est pas. Le patching OS des node pools, les mises a jour de version Kubernetes, la gestion des network policies, la configuration RBAC, le deploiement des agents de monitoring, le cycle de vie de l’ingress controller : tout cela repose sur votre equipe.

Container Apps elimine cette categorie entiere de travail. Pour le scenario “cinq microservices et une queue”, Container Apps se deploie en une apres-midi et scale a zero la nuit. AKS se deploie en une semaine et vous coute des VM de node pool 24h/24.

La question a poser n’est pas “pourrions-nous utiliser des fonctionnalites Kubernetes ?” C’est plutot : “avons-nous besoin de fonctionnalites Kubernetes aujourd’hui, et avons-nous une equipe capable d’operer Kubernetes de maniere responsable ?”

Le chemin de migration : complexite progressive

L’un des grands avantages de l’ecosysteme de conteneurs Azure, c’est que le chemin de migration est bien defini et incremental.

App Service vers Container Apps. Si votre workload App Service est deja containerise, le passage a Container Apps est simple. Les principaux changements concernent la configuration de l’ingress et le modele de scaling. Les variables d’environnement, les secrets et la managed identity fonctionnent de maniere similaire. Vous gagnez le scale-to-zero et le scaling base sur KEDA. Vous perdez les deployment slots (remplaces par les revisions) et Easy Auth (remplace par une authentification manuelle ou un middleware Dapr).

Container Apps vers AKS. Parce que Container Apps fonctionne sur Kubernetes, le modele mental se transfere directement. Vos images de conteneurs, variables d’environnement et concepts de scaling se transposent tels quels. Vous devrez configurer votre propre ingress controller, mettre en place le monitoring et gerer le cycle de vie du cluster, mais la couche applicative reste identique. Si vous utilisiez Dapr sur Container Apps, vous pouvez deployer Dapr sur AKS et garder votre code applicatif inchange.

Ce chemin incremental signifie que vous pouvez commencer avec l’option la plus simple qui repond a vos besoins et monter en complexite uniquement lorsque vous atteignez une limitation reelle. C’est l’inverse de commencer avec AKS et supporter le cout operationnel des le premier jour.

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

Integration VNet et securite

Les Container Apps sont deployees dans un Container Apps Environment, qui constitue la frontiere de securite et de networking pour vos applications. Vous avez deux options :

Environnement externe : l’environnement dispose d’un endpoint public. Les applications individuelles peuvent etre configurees avec un ingress externe ou interne. C’est l’option la plus simple, adaptee aux API et services exposes publiquement.

Environnement interne : l’environnement est deploye dans un VNet sans endpoint public. Tout l’ingress est prive. C’est le schema pour les workloads d’entreprise qui doivent rester dans le perimetre du reseau corporate.

Pour les environnements internes, le Container Apps Environment est injecte dans un subnet dedie de votre VNet. Le trafic sortant passe par le VNet et est soumis a vos NSGs et tables de routage. Le trafic entrant necessite un reverse proxy (Application Gateway, Azure Front Door, ou une solution personnalisee) devant l’endpoint interne.

Ce modele est similaire a l’App Service Environment (ASE), mais sans le surcout significatif. Un ASE demarre a environ 1000 USD/mois rien que pour le stamp. Un environnement interne Container Apps ne coute rien au-dela des ressources consommees par vos applications.

La configuration DNS est importante dans les environnements internes. Le Container Apps Environment recoit une IP statique et un domaine par defaut. Vous devez configurer des Private DNS zones pour resoudre le domaine de l’environnement vers l’IP interne au sein de votre VNet.

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

Conclusion

Azure Container Apps comble un vide qui existait depuis le lancement d’AKS. Tous les workloads containerises n’ont pas besoin de Kubernetes, et toutes les equipes ne devraient pas operer un cluster.

Commencez avec l’option la plus simple qui repond a vos besoins. App Service pour les applications web standard. Container Apps pour les microservices, les workloads event-driven et les API qui beneficient du scale-to-zero. AKS quand vous avez reellement besoin de l’API Kubernetes et que vous avez l’equipe pour le supporter.

Choisissez la plateforme qui vous permet de livrer du produit, pas celle qui devient un projet a part entiere.