Azure Container Apps (ACA) continue d’évoluer et devient l’une des plateformes les plus flexibles pour déployer des applications conteneurisées sans gérer d’orchestrateur.
Mais depuis l’arrivée des Workload Profiles, beaucoup d’architectes et développeurs se demandent :
Dois-je utiliser un environnement « Consumption-Only » ou un environnement « Workload Profiles » ?
Ce billet clarifie définitivement les différences — et surtout quand choisir l’un ou l’autre.
Deux modèles d’exécution pour ACA
Azure Container Apps propose désormais deux types d’environnements, chacun conçu pour un usage bien précis :
- Consumption-Only Environment — le modèle historique
- Workload Profiles Environment — pour les charges avancées ou critiques
Ces deux environnements utilisent la même plateforme ACA, mais offrent des capacités très différentes.
1. Consumption-Only Environment
Simplicité et facturation à la demande
Le modèle “consumption-only” repose entièrement sur la facturation à la consommation :
CPU / mémoire par seconde, automatiquement gérés par Azure.
✔ Ce que tu obtiens
- Scale-to-zero natif (0$ quand l’app est arrêtée)
- Zéro gestion de compute (pas de VM, pas de nœuds)
- Déploiement ultra simple
- Idéal pour API légères ou usages occasionnels
✔ Quand l’utiliser ?
- Environnements Dev/Test
- Apps ayant un trafic irrégulier ou faible
- Services internes ou automatisations ponctuelles
- Proof-of-concept, MVP, petits workloads
❌ Limitations importantes
- Pas de contrôle sur le compute
- Pas de GPU
- Performances moins prévisibles
- Scalabilité limitée pour des workloads intensifs
- Impossible d’isoler des profils différents (CPU vs RAM optimisée)
2. Workload Profiles Environment
La puissance et la maîtrise pour les workloads sérieux
Avec les Workload Profiles, ACA devient bien plus proche d’un cluster AKS géré, sans la complexité.
Tu provisionnes des profils de compute (par exemple : D-series, E-series, GPU) et ACA va scaler les conteneurs au sein de ces profils.
✔ Ce que tu obtiens
- Contrôle total sur le compute
- Performances prévisibles et garanties
- Support des GPU
- Isolation des workloads par profils
- Idéal pour microservices et architectures complexes
✔ Quand l’utiliser ?
- Workloads intensifs ou constants
- Traitement de données, batch, ML
- API à haute performance
- Scénarios d’entreprise (hub-spoke, sécurité, conformité)
- Domaines nécessitant un contrôle strict du réseau ou de la performance
❌ Inconvénients
- Pas de scale-to-zero complet (compute toujours provisionné)
- Coût minimal plus élevé
- Plus complexe à configurer
- Moins adapté aux charges légères
3. Tableau de comparaison
| Critère | Consumption-Only | Workload Profiles |
|---|---|---|
| Coût minimal | ⭐ Très bas (scale-to-zero) | ❌ Plus élevé |
| Complexité | ⭐ Faible | ⚠️ Moyenne |
| Contrôle du compute | ❌ Aucun | ✔ Total |
| GPU | ❌ Non | ✔ Oui |
| Performance garantie | ❌ Non | ✔ Oui |
| Microservices complexes | ⚠️ Possible | ✔ Recommandé |
| Dev/Test | ✔ Idéal | ❌ Overkill |
| Workloads critiques | ❌ Non | ✔ Oui |
4. Alors, lequel choisir ?
🟦 Choisis « Consumption-Only » si :
Tu veux un coût minimal, aucune gestion d’infrastructure, et des workloads légers ou irréguliers.
🟩 Choisis « Workload Profiles » si :
Tu as des besoins de performance, GPU, prévisibilité, isolation ou workloads critiques.
Conclusion
Azure Container Apps s’adapte désormais à tous les types de projets :
- des microservices critiques avec GPU
- aux API légères et coût-optimisées
- en passant par les architectures d’entreprise exigeantes
Le choix entre Consumption-Only et Workload Profiles ne dépend pas seulement du coût, mais de la nature même de ton application : stabilité, performance, sécurité, gouvernance et topologie réseau.