Migration d'une plateforme d'intégration MuleSoft vers Azure et Apache Camel

Le contexte

Dans une entreprise, les applications ne travaillent pas isolément : le logiciel de commandes parle à celui de facturation, qui parle à la comptabilité, qui reçoit des fichiers de partenaires extérieurs. Une plateforme d'intégration est le carrefour qui organise tous ces échanges — elle les transporte, les convertit et les surveille.

Notre client utilise pour cela une plateforme éditée par MuleSoft. Elle fonctionne, mais sa licence pèse lourdement sur le budget informatique, et les évolutions prévues du système d'information devaient l'alourdir encore.

Applications concernées

30

Échanges à reprendre

90

Charge

300 à 400 échanges/min

Hébergement cible

Azure

L'enjeu

Il existe une alternative reconnue à cette plateforme : Apache Camel, un logiciel libre, largement adopté et soutenu par une communauté active, qui sait faire la même chose sans licence à payer.

Mais un logiciel libre ne se substitue pas à un service clés en main : il faut lui construire ce que l'éditeur fournissait jusque-là — l'infrastructure qui l'héberge, la supervision, la sécurité, les outils de mise en production. C'est précisément l'objet de notre mission. Elle doit aussi répondre à deux contraintes : rester dans l'environnement Azure déjà utilisé par le client, pour ne pas ajouter un fournisseur de plus à maîtriser, et continuer à dialoguer avec les serveurs restés dans leurs locaux.

Ce que nous faisons

Une étude d'architecture, d'abord. Plutôt que de proposer une solution unique, nous avons examiné chaque brique nécessaire — hébergement, transport des messages, sécurité des accès, supervision, mise en production — et comparé les options disponibles sur Azure, sur leur coût comme sur la charge d'exploitation qu'elles impliquent.

Ces options ont ensuite été combinées en trois scénarios cohérents : un scénario au budget contraint, un scénario d'équilibre, un scénario taillé pour la performance et des engagements de service stricts. Chacun a été chiffré et documenté, avec ses avantages et ses limites, pour que le choix appartienne au client. C'est le scénario d'équilibre qui a été retenu.

La construction de la plateforme, ensuite. L'infrastructure est décrite sous forme de code, ce qui permet de la recréer à l'identique sur chaque environnement, et de tracer chaque modification. Les mises en production sont automatisées, de la compilation jusqu'au déploiement, avec les contrôles de qualité et les validations humaines aux bons endroits.

Une validation par la preuve, enfin. Avant d'engager la reprise des 90 échanges, une maquette technique vérifie les points qui décideront de la faisabilité : le dialogue avec les systèmes réels, le fonctionnement en parallèle de l'ancienne et de la nouvelle plateforme pendant la bascule, et la consommation de ressources sous charge.

Où en est le projet

Les ateliers d'analyse et la documentation d'architecture sont terminés. L'infrastructure et les chaînes de mise en production sont en place, et la plateforme est en cours d'installation et de validation sur les environnements de test : liaison avec les serveurs du client, supervision, répartition de charge, sécurité des accès et transport des messages.

La maquette Apache Camel et le déploiement d'un premier composant constituent l'étape suivante, avant la reprise des échanges proprement dite et l'accompagnement à l'exploitation.