Migration MuleSoft vers Azure — architecture et choix techniques

Le point de départ

La plateforme existante repose sur les composants habituels d'une offre d'intégration propriétaire : moteur d'exécution, gestionnaire d'API, broker de messages, magasin d'objets, supervision, gestion des accès.

Les flux mobilisent une large palette de connecteurs — HTTP, SFTP, FTP, bases de données, SAP, e-mail, files de messages et ordonnanceur — et une partie des systèmes reste hébergée sur site.

La méthode d'étude

Nous avons produit une analyse composant par composant plutôt qu'une architecture unique : hébergement applicatif, broker de messages, passerelle d'API et répartition de charge, cache et stockage d'objets, connectivité réseau, observabilité, chaîne de livraison.

Pour chacun, les options disponibles sur Azure ont été comparées sur leurs caractéristiques techniques, leur complexité d'exploitation et leur coût de possession. Ces options ont ensuite été combinées en trois scénarios cohérents, chacun assorti de ses variantes.

L'arbitrage central portait sur l'hébergement : Azure Container Apps contre Azure Kubernetes Service. AKS offre un contrôle et une portabilité supérieurs, mais suppose une expertise Kubernetes permanente et donc un renforcement de l'équipe. Container Apps a été retenu pour sa simplicité d'exploitation et son auto-scaling piloté par des signaux métier.

Livrables de cette phase : un document des choix techniques et une documentation d'architecture au format C4, construits lors d'ateliers menés avec les équipes infrastructure et intégration du client.

L'architecture cible

• Hébergement applicatif — microservices Camel conteneurisés sur Azure Container Apps, sur trois environnements (développement, pré-production, production). L'auto-scaling s'appuie sur des signaux métier, dont la profondeur des files d'attente, et pas seulement sur la charge CPU.
• Broker de messages — RabbitMQ conservé et auto-hébergé en cluster. Le protocole AMQP reste identique, ce qui évite de refondre le code applicatif des 90 flux — c'est l'argument décisif face à un broker natif du cloud, qui aurait imposé une réécriture.
• Exposition et sécurité — une Application Gateway assure la terminaison TLS, le pare-feu applicatif et le routage par chemin, complétée par un contrôleur d'entrée pour le routage fin.
• Cache et stockage — cache Redis managé pour les jetons et les données de session ; stockage d'objets pour les fichiers volumineux issus des flux batch et SFTP.
• Connectivité — passerelle VPN site à site vers les systèmes on-premise, dimensionnée pour la charge réelle. Une liaison privée dédiée a été écartée : surdimensionnée au regard de 300 à 400 requêtes par minute, pour un coût et un délai de mise en place sans commune mesure.
• Observabilité — supervision applicative, traces distribuées et journaux centralisés, alimentés par des métriques exposées depuis les routes Camel.
• Secrets et identités — coffre de secrets managé et identités gérées ; authentification et habilitations adossées à l'annuaire d'entreprise.

Arbitrages de sécurité

Deux composants, initialement envisagés en exposition publique, ont été basculés en accès privé pour s'aligner sur la politique de sécurité du client : la passerelle d'API et le registre de conteneurs. Un arbitrage pris en cours de conception, qui a des conséquences sur le plan d'adressage et sur les chaînes de déploiement.

L'infrastructure as code

L'infrastructure est décrite en Terraform, organisée en modules réutilisables — Container Apps, RabbitMQ, passerelle, réseau, supervision — et déclinée par environnement :

modules/
  container-apps/
  rabbitmq/
  api-gateway/
  network/
  monitoring/
environments/
  dev/
  staging/
  prod/

L'état est stocké à distance avec verrouillage, les variables sont externalisées par environnement, et des tests d'infrastructure sont exécutés en pipeline.

Les chaînes de livraison

Deux pipelines coexistent sur Azure DevOps.

Microservices Camel — compilation Maven et tests unitaires, tests d'intégration sur conteneurs éphémères, analyse qualité, construction d'une image Docker multi-étapes, publication au registre avec versionnement sémantique, puis déploiement automatique en développement et sur approbation en pré-production et en production.

Infrastructure — validation et formatage des fichiers Terraform, prévisualisation des changements, application sur approbation, tests, et régénération automatique de la documentation.

Le POC Apache Camel

Avant d'engager la migration des flux, un proof of concept valide les points qui décideront de la faisabilité :

• le fonctionnement de bout en bout de la chaîne de livraison ;
• la communication avec les systèmes réels — SAP, SFTP, files de messages, bases de données, HTTP ;
• l'exécution en parallèle des API exposées vers l'extérieur, pendant la période de bascule ;
• la consommation processeur et mémoire des conteneurs applicatifs, mesurée sous charge.

Il s'accompagne d'un template de dépôt Camel — structure type d'application Spring Boot, routes d'exemple, tests, Dockerfile variabilisé, configuration d'observabilité, fichiers de pipeline — et d'un guide de bonnes pratiques destiné aux équipes qui reprendront les développements.