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).

Comme dans toute grande entreprise, l'environnement informatique d'un établissement de santé se compose de différents systèmes qui doivent partager des données essentielles. Des systèmes d'admission, sortie et transfert, de laboratoire et de radiologie, aux systèmes de planification et facturation, entre autres, tous doivent être en mesure de communiquer et de s'échanger des données qui peuvent s'avérer vitales en cas d'urgence médicale.

Depuis l'avènement du numérique, les professionnels de santé utilisent des dossiers médicaux électroniques, mais sans partage des données entre les différentes applications, ces dossiers présentent un intérêt limité. La problématique de l'intégration des systèmes de santé est apparue il y a plusieurs dizaines d'années, plus précisément en 1987 avec l'établissement des normes internationales HL7 (Health Level Seven) pour le transfert des données cliniques et administratives entre les applications utilisées dans le domaine médical. Ce langage commun établi, il restait à trouver les moyens de connecter les applications afin qu'elles puissent communiquer via le format HL7.

Au fil des ans, les professionnels de santé ont constaté que les connexions directes point à point entre applications étaient peu pratiques et engendraient davantage de difficultés à mesure que l'établissement s'agrandissait. En outre, malgré le langage universel HL7, il n'existait pas de méthode unique pour interpréter les champs. Pour permettre la communication entre les systèmes de santé, il fallait donc transformer les données et se doter de capacités de connexion.

La toute première technologie d'intégration adoptée par les prestataires de services de santé, l'IE (Interface Engine), était un serveur qui faisait office de concentrateur pour l'ensemble des systèmes d'un hôpital. Chaque système se connectait à l'IE, qui transformait les données et les acheminait vers les autres systèmes selon les besoins. Puis, il y a 20 ans environ, la technologie ESB (Enterprise Service Bus) a fait son apparition. Comme l'IE, un ESB est un concentrateur qui permet l'échange de données entre plusieurs applications médicales, essentiellement via le langage HL7. Compatible avec différents services web, JMS, HTTP et SOAP, l'ESB offre des fonctions de transformation des données, de conversion de protocoles et de routage, et simplifie la gestion ainsi que la surveillance. C'est la solution d'intégration la plus utilisée depuis 20 ans, dans la santé comme dans d'autres secteurs.

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.