Les microservices comme technologie d'intégration dans le secteur de la santé

Les microservices permettent aux développeurs, notamment ceux du secteur de la santé, de créer des applications qui sont constituées de services faiblement couplés, ce qui facilite les étapes de développement, de test, de déploiement et de mise à niveau. Ces avantages expliquent l'engouement croissant pour les microservices au détriment de la précédente génération de technologies d'intégration, les ESB (Enterprise Service Bus).

Le développement d'applications a considérablement évolué depuis l'apparition du modèle ESB, et celui-ci a pris du retard notamment à cause de l'essor des approches DevOps et agile.

Le pipeline DevOps désigne un cycle de développement basé sur des changements progressifs et des tests automatisés en continu. À l'ère du DevOps, ce qui faisait hier la popularité de l'ESB représente aujourd'hui un obstacle. Avec un ESB, toutes les intégrations sont déployées sous la forme d'un monolithe. Avant, il s'agissait d'un atout, mais aujourd'hui, cette caractéristique rend l'ESB incompatible avec le DevOps.

Voici les limites de l'ESB dans l'environnement de développement moderne :

• Incompatibilité avec le développement agile et les outils DevOps : souvent formés dans un environnement DevOps, les jeunes développeurs agiles sont plus productifs avec les dernières solutions DevOps, qu'ils ont l'habitude d'utiliser. Or, les ESB n'ont pas été conçus pour prendre en charge ces outils.
• Impact des modifications sur le système tout entier : pour effectuer un changement, même minime, dans la règle d'un ESB, il faut interrompre tout le moteur. Cette intervention perturbe toutes les applications qui interagissent avec l'ESB et les rend inutilisables. De la même manière, une erreur introduite par une modification est susceptible d'affecter l'ensemble des intégrations. Au final, les équipes rechignent à appliquer les mises à niveau et les correctifs, ce qui est contreproductif.
• Point de défaillance unique : comme toutes les intégrations sont routées via le même concentrateur, l'ESB représente un point de défaillance unique pour l'établissement tout entier. Si l'ESB tombe en panne, l'ensemble des intégrations est affecté.
• Impossibilité d'automatiser les tests : les tests automatisés sont une composante clé du modèle DevOps. Dans le pipeline DevOps, chaque mise à jour est testée de façon indépendante sans interrompre le processus de développement, et ce, grâce à l'automatisation. L'ESB, quant à lui, dispose d'un système de contrôle des versions et d'une interface utilisateur graphique propriétaires qui empêchent l'automatisation des tests.

Le secteur de la santé, comme d'autres secteurs d'ailleurs, a adopté les nouvelles pratiques de développement telles que les microservices, le DevOps et le développement agile. L'adoption de ces méthodes s'est étendue également aux intégrations. En effet, les applications modernes et les nouveaux points de contact numériques doivent être intégrés aux différents protocoles existants, dont HL7 et REST. Les développeurs de microservices qui travaillent dans le domaine de la santé souhaitent contrôler les intégrations et les autres applications qu'ils développent (pour les données, la diffusion, l'interface utilisateur, les systèmes de commande et contrôle, etc.) et mettre en paquets toutes les modifications sous la forme d'unités déployables transmises tout au long du processus CI/CD. Malheureusement, les limites évoquées ci-dessus empêchent l'utilisation d'une approche CI/CD pour l'intégration des applications.

Les microservices représentent l'avenir du développement et le modèle ESB n'est tout simplement pas compatible. Les microservices sont l'exact opposé des ESB monolithiques : ils permettent aux développeurs de créer des applications et des intégrations à partir de services faiblement couplés. En décomposant les applications en modules indépendants, il est plus facile de les développer, tester, modifier, retester, corriger, déployer, tester en production, mettre à niveau, et ainsi de suite.

Les microservices soutiennent le modèle DevOps grâce aux tests automatisés. En raison de leur petite taille, ils sont faciles à placer dans des conteneurs qui servent à automatiser le processus de test ainsi qu'à simplifier l'intégration et la distribution continues (CI/CD). A contrario, un ESB monolithique ne tient pas dans un conteneur et ne peut pas être décomposé ; impossible donc de le tester de la même manière.

Le principal argument en faveur de l'adoption de l'intégration basée sur des microservices est sans doute qu'elle permet aux développeurs agiles d'utiliser leurs outils DevOps favoris. Sans ESB, les développeurs sont libres de travailler dans l'environnement de développement agile de leur choix. Ils n'ont pas besoin d'être formés à l'utilisation d'un système propriétaire et peuvent ainsi concentrer leurs efforts sur une approche plus productive.

Par ailleurs, les microservices rendent l'intégration plus accessible. Elle n'est plus réservée à une équipe de spécialistes des ESB et chaque développeur peut déterminer ses propres besoins en matière d'intégration. Cette démarche est plus logique, car personne ne comprend mieux les exigences liées aux données d'une application que son développeur.

Les microservices facilitent aussi la gestion des API et, par conséquent, l'intégration basée sur des API (si besoin).

Enfin, l'intégration basée sur des microservices offre les mêmes avantages qu'un ESB, notamment la transformation graphique et la logique pour créer des règles sophistiquées concernant les transferts de données dans l'entreprise. Ainsi, si vous aimez les interfaces de développement graphiques des ESB, sachez qu'il existe des interfaces similaires compatibles avec l'intégration basée sur des microservices.

L'intégration basée sur des microservices apporte un certain nombre d'avantages :

Surveillance et gestion complètes : les développeurs agiles peuvent surveiller les microservices à l'aide des meilleurs outils (Kibana, ElasticSearch, Grafana, Prometheus, etc.) et identifier les points de défaillance, ce qui permet la résolution des problèmes avant qu'ils n'affectent l'entreprise.

Tests automatisés : les tests automatisés sont l'un des principaux avantages des microservices et du DevOps. Chaque intégration est testée en tant que composant indépendant, et ce, sans jamais perturber les autres composants de l'application ni les autres applications.

Logiciels de meilleure qualité : avec des processus plus efficaces et de meilleurs résultats de test, la qualité des logiciels s'améliore forcément.

Développement accéléré : la rationalisation du développement des intégrations grâce au DevOps et à l'automatisation ainsi que l'élimination des processus manuels permettent de réduire la durée du développement.

Évolutivité supérieure : puisqu'une application est constituée de modules séparés, chaque service peut être mis à l'échelle de façon indépendante sans affecter le reste de l'application.

Innovation encouragée : grâce à la combinaison microservices/DevOps, les développeurs peuvent imaginer des solutions d'intégration qui permettent à l'établissement de lancer de nouveaux services et de mieux servir les clients.

Agilité métier : le développement agile favorise naturellement l'agilité métier, c'est-à-dire la capacité à s'adapter rapidement à l'évolution du marché. Imaginons que de nouveaux partenaires ou fournisseurs aient besoin d'accéder à certaines données de l'établissement. Grâce aux microservices, les développeurs agiles peuvent créer rapidement les intégrations nécessaires pour permettre ces nouvelles relations professionnelles.

Expérience client améliorée : votre objectif premier consiste à servir les clients, en l'occurrence les patients qui dépendent au quotidien de vos services de soin. En améliorant les processus et en simplifiant le partage des données entre les systèmes et services, vous leur offrez une expérience satisfaisante.

Vous redoutez peut-être la migration de votre modèle d'intégration vers des microservices. Pourquoi changer ? Après tout, votre équipe maîtrise déjà les éléments propriétaires de l'ESB que vous utilisez depuis si longtemps. C'est précisément là le problème. Supposez qu'un ou deux spécialistes de l'ESB quittent votre établissement. Comment ferez-vous pour retrouver le même niveau de compétences ?

La difficulté prétendument insurmontable que représente l'abandon de l'ESB monolithique est justement la raison pour laquelle il faut relever le défi. Lorsque vous vous serez affranchi de ses limites, vous pourrez exploiter tout le potentiel d'un nouveau monde d'intégration.