ninog - Fotolia
Architecture Pub/Sub : les clés pour comprendre son importance
Si l’approche Pub/Sub demeure une architecture de messagerie standard depuis des décennies, il est essentiel que les développeurs et les directions IT comprennent ce que c’est, comment elle fonctionne et pourquoi elle est importante.
Grâce à (ou à cause de) l’essor de l’informatique distribuée, le traitement des données en temps réel, l’architecture pilotée par les événements et le développement modulaire, la façon dont les entreprises régissent la communication entre les composants logiciels est plus importante que jamais. Malheureusement, ces progrès ont simultanément compliqué la gestion des correspondances entre applications.
Ainsi, un nombre croissant d’équipes de développement sont contraintes de quitter le confort d’échanges fiables et individuels, en faveur d’approches plus dynamiques imposées aux systèmes de messagerie par l’adoption du cloud et de l’IoT.
Le modèle de messagerie éditeurs/abonnés (publish – suscribe ou Pub/Sub) apparaît pertinent dans les environnements cloud natifs, où les relations complexes entre les composants logiciels présentent des défis non négligeables en matière d’échanges. Ce modèle promet aux entreprises la possibilité de créer des applications et des systèmes robustes dans le cloud qui restent connectés, quelle que soit la distribution de chacun des services.
Voyons comment fonctionne cette architecture de messagerie, le type de problèmes qu’elle peut poser et évoquons les outils qui prennent en charge les implémentations Pub/Sub.
Qu’est-ce qu’une messagerie Pub/Sub ?
La messagerie pub/sub n’a rien de nouveau. Par exemple, ceux qui ont travaillé avec des paradigmes traditionnels tels que les architectures orientées services connaissent probablement le modèle Pub/Sub par le biais des bus de services d’entreprise (ESB) et des middlewares orientés messages. Si la méthodologie a évolué pour répondre aux demandes d’approches logicielles comme les microservices et les architectures orientées événements, l’idée de base reste la même.
Au sein du modèle Pub/Sub, les entités logicielles qui envoient et reçoivent des messages sont appelées respectivement « éditeurs » (Pub) et « abonnés » (Sub). Les éditeurs adressent des messages à une file d’attente – ou à un autre courtier de messagerie (broker) – où ces missives sont stockées avant d’être traitées. Pour les acheminer correctement, le courtier affecte chaque message à des « sujets » (topics) particuliers qui segmentent logiquement les opérations connexes. Les services et les composants abonnés à ce sujet reçoivent une alerte indiquant que le message est dans la file d’attente, prêt à être traité.
Avec cette approche, les services de publication sont simplement responsables du placement du message dans la file d’attente et n’ont pas besoin d’une réponse avant de passer à la tâche suivante. De même, les composants abonnés peuvent accéder aux messages à volonté, puisqu’ils ne sont plus tenus de retourner une réponse. Ce découplage permet une communication asynchrone, qui constitue la base d’applications complexes, à la fois distribuées et évolutives.
Les limites de l’approche Pub/Sub
Bien que l’approche Pub/Sub soit parfaitement viable pour de nombreux besoins de communication des applications d’entreprise à grande échelle, il existe certains cas où ses faiblesses sont flagrantes et rédhibitoires.
Cette architecture pose problème lorsque les messages doivent suivre l’ordre « premier entré, premier sorti » (« First In First Out » ou FIFO en VO). Il n’est pas idéal pour ce type d’opérations FIFO, car les messages sont traités strictement dans l’ordre où ils sont reçus. Certaines des plateformes cloud les plus importantes (Google Cloud, par exemple) autorisent la configuration de l’ordre des messages Pub/Sub. Toutefois, le découplage inhérent signifie que l’ordre FIFO n’est jamais garanti.
Ce modèle pose également certains problèmes en ce qui concerne la gestion des « couacs » liés aux messages. Inévitablement, les paquets dans la file d’attente généreront des erreurs avec l’approche Pub/Sub. Cela peut se produire pour un certain nombre de raisons, comme l’invalidité des données envoyées ou l’indisponibilité des services employés. À un moment donné, ces « ratés » doivent être traités, ce qui peut obliger les équipes de développement à effectuer des révisions manuelles du code. Bien que cette situation soit préférable à la perte totale des messages non traités, elle illustre le fait que la maintenance de cette architecture de messagerie peut parfois être un peu plus lourde que celle d’une approche traditionnelle de type « one-to-one ».
Outils et services Pub/Sub : comment choisir ?
Tout comme la communication de service à service est devenue une priorité pour de nombreuses sociétés, la messagerie Pub/Sub occupe une place centrale dans les conversations sur l’architecture des applications d’entreprise. À cette fin, il existe une multitude croissante d’outils indépendants (open source ou non) et propriétaires qui facilitent le démarrage et la mise en œuvre de la messagerie Pub/Sub à grande échelle. Toutefois, la plupart de ces fonctionnalités sont intégrées à des collections d’outils plus vastes, plutôt qu’à des offres autonomes.
Les organisations peuvent se procurer les services Pub/Sub des géants du cloud. Parmi ceux-ci, citons Amazon Simple Notification Service, Google Cloud Pub/Sub et Azure Web PubSub. Cette voie est la plus judicieuse pour les entreprises qui ont déjà investi auprès de ces fournisseurs.
Bien entendu, les développeurs ne sont pas redevables des acteurs du cloud propriétaires. De nombreuses boîtes à outils open source, telles que Redis, Ably Realtime, Dapr et Apache Pulsar offrent des fonctionnalités qui prennent en charge le modèle d’architecture Pub/Sub. La gratuité de ces librairies permet de les expérimenter assez facilement pour voir si elles répondent à vos besoins. Cela reste vrai pour les entreprises qui sont déjà liées à un fournisseur de cloud, car beaucoup de ces outils s’intègrent sans trop d’encombres à ces plateformes et sont disponibles depuis GitHub et AWS Marketplace.
L’adoption en production d’un service ou d’une plateforme Pub/Sub dépend – assez classiquement – du parc applicatif existant, de la « facilité » de prise en main pour les développeurs, des performances attendues, des spécificités nécessaires et bien évidemment du coût de déploiement et d’exécution.
Quoi qu’il en soit, l’approche Pub/Sub est une partie de l’architecture système qui ne sera pas dépassée de sitôt. La conteneurisation croissante et la multiplication des services de messagerie ne font qu’accélérer sa mise en œuvre.
