Quand on travaille régulièrement avec Azure Container Apps (ACA), on finit par connaître le chemin : environnement Container Apps, application, révisions, ingress, scaling, logs, métriques…
Tout est disponible dans le portail Azure classique, mais l’expérience reste très orientée ressources Azure et configuration de l’infrastructure.
Microsoft propose maintenant une nouvelle expérience dédiée à Azure Container Apps :
Je l’ai parcourue récemment et ma première impression est assez simple : on se rapproche beaucoup plus d’une expérience de plateforme applicative que d’une expérience traditionnelle de gestion de ressources Azure.
Et personnellement, j’aime beaucoup cette direction.
Une interface beaucoup plus centrée sur les applications
Dès l’arrivée dans le nouveau portail, la différence d’approche est visible.
Dans le portail Azure traditionnel, lorsqu’on souhaite créer une Container App, on se retrouve rapidement confronté à plusieurs décisions : environnement Container Apps, région, registre de conteneurs, ingress, réseau, workload profiles, scaling, etc.
Ce sont des concepts importants, particulièrement lorsqu’on construit une plateforme d’entreprise.
Mais est-ce vraiment ce qu’un développeur devrait voir en premier lorsqu’il veut simplement déployer son conteneur ?
Le nouveau portail essaie justement de séparer ces deux préoccupations.
L’objectif devient beaucoup plus simple :
J’ai une image de conteneur. Je veux la déployer.
Et seulement lorsque j’en ai besoin, je veux accéder aux options avancées.
C’est une philosophie que j’apprécie particulièrement.
Simple Create : commencer par le besoin, pas par l’infrastructure
Lors de la création d’une application, le portail propose une expérience simplifiée.
Dans le mode le plus simple, une bonne partie des décisions techniques est prise automatiquement. Un nom unique peut être généré et l’utilisateur peut essentiellement se concentrer sur son image de conteneur et quelques paramètres nécessaires au déploiement.
On ne commence donc plus nécessairement par se demander quel type d’environnement choisir ou comment configurer chaque composant de la plateforme.
Pour moi, c’est particulièrement intéressant dans les environnements où une équipe plateforme fournit Azure Container Apps comme service aux équipes de développement.
Le développeur ne devrait pas forcément avoir à connaître tous les détails de l’infrastructure sous-jacente pour déployer une application.
Il veut principalement savoir :
Est-ce que mon application fonctionne ? Quelle est son URL ? Comment se comporte-t-elle ? Et où puis-je voir ses logs ?
Cette nouvelle expérience va clairement dans cette direction.
Advanced Create : la simplicité ne signifie pas perdre le contrôle
Évidemment, dans mes architectures Azure, je travaille rarement avec uniquement les paramètres par défaut.
Réseaux privés, VNets, Managed Identities, Private Endpoints, règles de scaling, variables d’environnement ou encore contrôle des flux sortants font rapidement partie de la discussion.
C’est pourquoi j’apprécie particulièrement le choix fait ici : le mode avancé reste disponible directement dans le même processus de création.
On peut alors retrouver des options beaucoup plus proches de ce que l’on attend pour une architecture d’entreprise : sélection du réseau et du subnet, authentification auprès du registre avec une Managed Identity, variables d’environnement, règles de scaling, contrôles egress et autres paramètres avancés.
On conserve donc deux expériences dans une même interface :
Simple lorsque je veux aller vite. Avancée lorsque l’architecture l’exige.
C’est selon moi une meilleure approche que de présenter immédiatement toutes les possibilités de la plateforme à chaque utilisateur.
Une fonctionnalité que j’apprécie particulièrement : le Log Stream unifié
C’est probablement l’un des éléments que j’ai le plus appréciés en parcourant le portail.
Quand une application ne démarre pas correctement, la première chose que je veux généralement savoir est très simple :
Qu’est-ce qui s’est passé ?
Avec Azure Container Apps, cette réponse peut nécessiter de regarder plusieurs endroits selon le problème rencontré.
Le nouveau portail met beaucoup plus directement les informations opérationnelles importantes à disposition.
En particulier, le Log Stream unifié permet de consulter les logs applicatifs et les logs système dans une même expérience.
C’est une amélioration qui peut sembler mineure, mais qui change réellement l’expérience de diagnostic.
Une révision qui ne démarre pas, une erreur provenant du conteneur ou un problème au niveau de la plateforme : je peux beaucoup plus rapidement observer ce qui se passe sans naviguer entre plusieurs écrans.
Pour du troubleshooting rapide, c’est exactement le type d’expérience que j’attends d’une plateforme applicative moderne.
L’Overview devient réellement utile
J’aime également beaucoup le travail réalisé autour de la page Overview.
Dans beaucoup de services Azure, la page Overview sert principalement de point d’entrée vers d’autres blades du portail.
Ici, l’objectif semble différent.
On essaie de répondre rapidement aux questions que l’on se pose lorsqu’on exploite une application :
Mon application fonctionne-t-elle ?
Quelle révision est actuellement active ?
Quelle est son URL ?
Que disent les logs ?
Comment se comporte-t-elle ?
Et surtout : quelle est la prochaine action que je peux effectuer ?
Cette capacité à visualiser simplement l’état d’une application réduit énormément la friction lorsqu’on doit gérer plusieurs Container Apps.
Azure Container Apps Express : encore moins d’infrastructure
Le portail introduit également Azure Container Apps Express, actuellement en Public Preview.
Et là, Microsoft pousse encore plus loin la logique de simplification.
Avec Express, l’idée est essentiellement de supprimer une grande partie des décisions d’infrastructure traditionnellement associées à ACA.
Vous fournissez votre image de conteneur et la plateforme prend en charge une grande partie du reste.
Microsoft indique notamment qu’Express s’appuie sur de la capacité préprovisionnée, supporte le scale-to-zero et vise des démarrages et provisionnements beaucoup plus rapides que l’expérience ACA traditionnelle.
Je trouve l’approche particulièrement intéressante pour certains scénarios :
prototypes, APIs temporaires, outils internes, interfaces Web, MCP Servers ou encore workloads déployés dynamiquement par des agents IA.
Je ne remplacerais évidemment pas immédiatement une architecture ACA d’entreprise complexe par Express simplement parce que l’expérience est plus simple.
Il faut garder en tête qu’il s’agit encore d’une fonctionnalité en Public Preview et que Microsoft documente encore certaines différences fonctionnelles avec Azure Container Apps classique.
Mais la direction est intéressante.
Ce que je trouve surtout intéressant : la séparation des responsabilités
Au-delà de l’interface graphique, c’est probablement cet aspect qui m’intéresse le plus en tant qu’architecte.
Dans une organisation, les équipes plateforme peuvent continuer à gérer les éléments structurants :
réseau, sécurité, gouvernance, observabilité, identités, politiques Azure et environnements Container Apps.
Mais l’expérience proposée aux développeurs peut devenir beaucoup plus simple.
C’est exactement ce que j’attends d’une bonne Internal Developer Platform : masquer la complexité qui n’est pas nécessaire au développeur sans supprimer cette complexité de l’architecture.
Le réseau existe toujours.
Les politiques de sécurité existent toujours.
L’observabilité existe toujours.
Les contraintes d’entreprise existent toujours.
Mais elles ne doivent pas nécessairement être présentées au développeur à chaque déploiement.
Le portail Azure classique n’est pas mort
Il faut également préciser quelque chose : ce nouveau portail ne signifie pas que nous devons abandonner le portail Azure traditionnel.
Pour certaines opérations d’administration, de gouvernance ou de troubleshooting avancé, je continuerai naturellement à utiliser le portail Azure.
Et pour les environnements industriels, l’infrastructure devrait de toute façon être principalement déployée avec du Bicep, Terraform ou des pipelines CI/CD, plutôt que manuellement depuis un portail.
Je vois donc davantage cette nouvelle interface comme une expérience complémentaire.
Le portail Azure reste centré sur les ressources Azure.
Le nouveau portail Container Apps peut devenir beaucoup plus centré sur l’expérience du développeur et l’exploitation de l’application.
Et cette distinction me semble pertinente.
Mon impression après cette première prise en main
Azure Container Apps était déjà, selon moi, l’un des services Azure les plus intéressants pour exécuter des workloads conteneurisés sans avoir à supporter toute la complexité opérationnelle d’un cluster Kubernetes.
Avec ce nouveau portail, Microsoft s’attaque maintenant à une autre forme de complexité : la complexité de l’expérience utilisateur.
Et c’est probablement ce que j’apprécie le plus.
On peut commencer simplement, visualiser rapidement son application et ses logs, puis accéder aux options avancées lorsque le besoin apparaît.
Pour les développeurs, cela réduit la courbe d’apprentissage.
Pour les équipes plateforme, cela ouvre également des perspectives intéressantes pour proposer Azure Container Apps comme une véritable plateforme interne de déploiement.
Le portail est encore jeune et certaines fonctionnalités continueront certainement d’évoluer, mais après cette première prise en main, c’est clairement une expérience que je vais continuer à suivre et à utiliser.
Si vous travaillez déjà avec Azure Container Apps, je vous conseille simplement de l’essayer quelques minutes et de comparer l’expérience avec le portail Azure traditionnel.