Migrer dix applications d’Azure Web Apps vers Kubernetes

Le problème

La plateforme reposait sur Azure Web Apps, un modèle qui convient tant que les applications restent simples et peu nombreuses. À une dizaine d’applications réparties entre segments clients historiques et nouveaux, les limites étaient devenues structurelles : contrôle réduit sur l’exécution, mise à l’échelle grossière, isolation insuffisante entre segments, et coûts qui suivaient mal l’usage réel.

Les données, elles, vivaient dans un pool de bases managé — une base par client, 150 au total — que la migration ne devait pas toucher.

La solution

Les applications ont été portées sur Kubernetes (AKS), réparties sur des clusters multi-régions correspondant aux segments clients. Chaque segment obtient son isolation, sa fenêtre de maintenance et son dimensionnement propres.

La migration a été menée sans interruption de service, application par application, avec possibilité de retour arrière à chaque étape.

La livraison a suivi le même mouvement. Les pipelines Azure DevOps construisent les images, exécutent les tests et publient dans Azure Container Registry ; ArgoCD déploie ensuite les charts Helm en continu, en alignant le cluster sur ce que décrit le dépôt. Ce qui tourne en production est ce qui est écrit quelque part, pas ce qui a été appliqué depuis un poste.

Les résultats

• Une dizaine d’applications migrées
• Clusters multi-régions séparant les segments clients
• Isolation et dimensionnement indépendants par segment
• Déploiements maîtrisés et reproductibles via Helm
• Chaîne CI/CD Azure DevOps et déploiement continu GitOps avec ArgoCD

Ce que j’en retiens

Kubernetes n’est pas un gain en soi, et un service managé plus simple reste le bon choix pour beaucoup de charges. Ce qui a justifié la migration ici, c’est le besoin d’isoler des segments clients aux exigences différentes — un besoin d’architecture, pas une préférence technique.