top of page
Rechercher
  • Photo du rédacteurJocelyn Pichonnat

Sur le pouce - Architecture orientée événements

Pourquoi adopter une architecture orientée événements ?


Vous avez énormément d'applications qui interagissent ensemble et vous souhaitez améliorer la maintenabilité en réduisant le stress d'une mise en production qui brise la chaîne de données ? Ce que vous souhaitez faire s'appelle "découpler les applicatifs" et les rendre moins dépendantes directement les unes des autres. Et cela tombe bien, l'architecture orientée événements (que je vais abrégé AOE) est idéale pour cela !


En addition, cela vous permet :

  • d'avoir une immuabilité des données (c'est à dire, que les événements ne peuvent être altérés par le stagiaire de fin d'études)

  • d'offrir la possibilité d'avoir plus de données : les événements sont tous les changements d'une données donc vous pouvez imaginer faire des analyses et des régressions linéaires à gogo (j'espère ne pas avoir donner des PDSD aux personnes ayant fait (trop) de mathématiques)

  • de rejouer ou régénérer des données (si vous utiliser une solution PUB/SUB)


Un Pub c'est pour aller boire entre amis. Mais c'est quoi Pub/Sub ?


Si nous nous concentrons 2 minutes sur les AOEs, il existe 2 grandes familles :

  • Queue : lorsque un message est produit, il est consommé une seule fois. Les solutions de type Queue sont basées généralement sur du FIFO (First In First Out) et sont idéales pour traiter des données asynchrones. Par contre, souvent, le message est supprimé dès qu'il est consommé.

  • Pub/Sub : lorsque qu'un message est produit, il peut être consommé plusieurs fois. Cette solution est idéale pour diffuser des données à travers plusieurs applications de manière asynchrone. Elle supporte très bien le balancement de charge, très facile à accroître ces capacités. Enfin les messages ne sont supprimés seulement lorsque la politique de rétention de données passe par là.


Prêts pour partir vers l'AOE ? Mais comment choisir ?


Plusieurs points à prendre en considération :

  • La capacité (= le temps) qu'aura vos équipes à apprendre les nouvelles technologies. Si vous avez besoin de livrer hier, peut-être réfléchir à quelque chose de simple. Sinon, cela prend ce quelque chose de précieux à tous chef-e-s ou directeurs-trices de projets : du temps. S'il vous plaît, laissez le temps aux gens de se former et ne les jeter pas sous le train de la pression !

  • Les cas d'usages que vous souhaitez couvrir : Event Sourcing ? Event Stream Processing ? Communication 1 à 1 ou broadcasting de messages ? Data Mesh ?

  • Les configurations importantes sur vos données : les solutions Queue et Pub/Sub ont des caractéristiques différentes, chaque solution a souvent même des contraintes de durée de rétention de données, de taille de message etc. Vous devez prendre le temps de faire un comparatif.

  • L'intégration à votre écosystème actuel : si vous êtes dans Azure, peut-être il sera plus simple d'y rester. Pareil pour n'importe quel fournisseur de service de cloud ou de technologies.


Donc si je conclus...


Prenez le temps de bien regarder ce que chaque solution d'AOE vous propose en fonction de vos besoins. La question est rarement "est-ce que vous devriez faire de l'AOE?" mais plutôt "quelle(s) solution(s) je devrais choisir ?".


Et oui j'ose mettre un "s" car vous pouvez aussi combiner des solutions. Le monde en informatique n'est pas toujours binaire.

Posts récents

Voir tout

Comments


bottom of page