Grâce à l’expansion des smartphones, les individus modernes sont dorénavant habitués à l’instantanéité des applications, des services ou des communications, quels qu’ils soient. Ces nouveaux paradigmes s’infiltrent dans le monde de l’entreprise, ne serait-ce qu’à travers les KPI « live » ou les messageries d’entreprise ; de nombreuses applications récentes proposent également des API, permettant une communication en temps réel, notamment avec la multiplication des offres SaaS comme SalesForce, SAP ou SnowFlake. Les DSI doivent intégrer dans leur périmètre ce que peut offrir et permettre un ESB (Enterprise Service Bus), afin de faciliter la communication interapplicative, en explorant les meilleures façons d’aborder cette nouvelle philosophie, et les impacts inhérents aux besoins de leurs Systèmes d’Information. L’ESB peut se rajouter à la longue liste des concepts informatiques aux acronymes mystérieux mais qui, finalement, ne représentent que certaines idées simples qu’on regroupe.
On peut dire que l’ESB est une façon de développer et de déployer certains types de flux de données, en complément des batchs. Là où les systèmes classiques de flux effectuent généralement le traitement de données en masse, l’ESB va gérer des événements unitaires, qualifiés de messages, sans typage particulier (bien qu’un message soit généralement structuré en XML ou JSON). Cette différence nécessite de modifier les paradigmes de conception ; en effet, on ne peut pas appliquer les mêmes techniques de gestion de la donnée lorsqu’on traite des messages unitaires dont la fréquence et la volumétrie ne peuvent être qu’estimée. On se doit de garantir le traitement de la donnée le plus rapidement possible, mais sans mettre en péril l’infrastructure du SI, l’application ou le message lui-même (risque de perte).
Côté développement, on va retrouver essentiellement des web services (CXF et CXFRS) et des routages (en Java ou autre langage répandu), des petits services permettant d’être déclenchés par un événement précis ; celui-ci définit également le chemin au sein du SI que prendra l’information contenue dans le message (pour ceux qui ont commencé à travailler avant 2010, pensez EAI), à destination des applications cibles. La plupart des méthodes appliquées en développement peuvent être retrouvées dans le livre de Gregor Hohpe et Bobby Woolf, « Enterprise Integration Patterns », qui classifie les fonctions attendues dans le traitement d’un message, comme le routage, la transformation ou l’enrichissement.
Côté architecture, l’ESB repose sur des conteneurs d’exécution distribués et permet une certaine facilité de scalabilité qu’on ne retrouve pas dans les applications classiques. L’utilisation d’un agent (broker) de messages, qui stocke et fournit les messages aux consommateurs et producteurs de messages, permet aussi de traiter les messages en mode asynchrone, c’est-à-dire envoyer un message sans acquittement de routage (contrairement au web service, qui est toujours synchrone car chaque appel donnera une réponse).
Alors que le développement et l’architecture ESB permettent de repenser totalement comment les applications du SI communiquent entre elles, la grande force de l’exploitation d’une infrastructure réside dans la facilité de déploiement (on peut d’ailleurs tout à fait y appliquer des principes et des outils DevOps) et de scalabilité ; on pourra rapidement ajouter des conteneurs d’exécution en cas de forte volumétrie de messages, éteindre un conteneur défectueux ou effectuer des migrations sans couper le service… on y gagne une meilleure continuité de service, le KPI technique de plus en plus sous les feux des projecteurs.
La mise en place de l’ESB n’est pas sans défis. Par exemple, afin de maîtriser au mieux les capacités du système, il est très utile de garder un lien avec la communauté des utilisateurs ou même des développeurs, si possible ; comprendre le chemin que prendra un système dans le futur (tous les ESB sont dans une démarche évolutive), partager les meilleures pratiques et communiquer sur les failles du système sont des atouts majeurs pour la réussite ; ces liens ne sont pas forcément des automatismes au sein des DSI.
Mais le plus grand défi pour réussir à long terme la mise en place d’un système ESB au sein d’un SI est d’éviter la multiplication des flux redondants. Les facilités décrites plus haut peuvent créer des silos de développement, où les équipes n’ont pas forcément la notion des fonctionnalités pouvant être réutilisables. La solution à cette problématique passe par l’urbanisation, terme de moins en moins usité à tort… Il est primordial dans ce type de système d’avoir une notion globale de tous les flux de l’acheminement ainsi que des données transmises afin d’avoir la meilleure factorisation des développements, la meilleure optimisation de la dissémination d’une information ou même la meilleure vue sur les destinataires d’une information spécifique (par exemple, pour le RGPD).
Comprendre l’ESB permet de proposer des solutions innovantes à des besoins immédiats de plus en plus variés. Ce n’est pas une solution révolutionnaire permettant de tout remplacer, mais d’ajouter des possibilités à son portefeuille de conception (en complément de celles déjà existantes), ouvrant la voie à une couverture plus large des techniques de communication interapplicatives. Une maîtrise forte des cheminements des flux du SI, dans ce contexte, devient alors absolument nécessaire pour garantir la meilleure intégration de l’ESB.
Comments