top of page
Rechercher
  • Photo du rédacteurJocelyn Pichonnat

Sur le pouce - Comparaison de solutions d'architecture orientée évènements

Si vous êtes ici, c'est que vous avez déjà lu mon précédent article au minimum ou que vous vous y connaissez suffisamment en architecture orientée évènements


Aujourd'hui je vais parler de 6 solutions pour l'architecture événementielle. Pourquoi ces 6 en particulier et pas d'autres ? Parce que je ne peux pas m'amuser à l'infini, j'ai une vie ! Si vous avez des suggestions, n'hésitez pas à les partager !

Pour ne pas mélanger choux et carottes, je vais séparer les solutions entre celles qui sont de type Queue, et celles qui sont de type Pub/Sub en me focalisant sur :

  • La courbe d'apprentissage (ou la capacité) nécessaire aux équipes

  • La possibilité de faire de l'Event Sourcing, de l'Event Stream Processing

  • Les particularités sur les configurations majeures comme la rétention de données, la volumétrie et la latence

  • La facilité d'intégration avec des écosystèmes


 

Comparatifs des Queues

 

RabbitMQ

  • Courbe d'apprentissage : extrêmement simple, très bien documenté, aucun défi à appréhender

  • Event Sourcing / Event Stream Processing : Malheureusement ici, que du Event Sourcing. Il va falloir intégrer manuellement une autre solution pour faire du traitement en temps réel

  • Rétention de données : par défaut, les messages sont détruits lorsqu'ils sont consommés. Par contre, tant que vous avez de l'espace de stockage, il n'y a pas vraiment de limite (si ce n'est votre portefeuille)

  • Volumétrie : de l'ordre de plusieurs centaines de messages par seconde (environ 30-35 MBytes/s)

  • Latence : extrêmement faible quelque soit la charge

  • Intégration : assez facile (peut être containerisé)


EDIT (20/07/2023)

Avec RabbitMQ Streams (lien ci-dessous), il est possible de faire d'avoir des fonctionnalités Pub/Sub. Dans cet article, je parle d'un usage "vanille" de RabbitMQ.


AWS SQS

  • Courbe d'apprentissage : simple, très bien documenté

  • Event Sourcing / Event Stream Processing : Event Sourcing seulement mais vous pouvez brancher des services AWS pour le traitement de données

  • Rétention de données : 14 jours maximum (pas plus)

  • Volumétrie : plusieurs millions de messages par seconde (pas de limite explicite)

  • Latence : extrêmement faible quelque soit la charge

  • Intégration : très facile dans un environnement AWS, peut être plus difficile sinon


Azure Service Bus

  • Courbe d'apprentissage : simple, très bien documenté

  • Event Sourcing / Event Stream Processing : Event Sourcing seulement mais vous pouvez brancher des services Azure pour le traitement de données

  • Rétention de données : 90 jours maximum avec le plan le plus cher

  • Volumétrie : plusieurs millions de messages par seconde (pas de limite explicite)

  • Latence : extrêmement faible quelque soit la charge

  • Intégration : très facile dans un environnement Azure, peut être plus difficile sinon


 

Comparatifs des Pub/Sub

 

Apache Kafka

  • Courbe d'apprentissage : difficile pour des novices

  • Event Sourcing / Event Stream Processing : Support natif très bien fourni pour les 2 choix. Les Kafka Streams seront vos meilleurs amis !

  • Rétention de données : dépend de la taille de votre portefeuille (de quelques jours à plusieurs années)

  • Volumétrie : Extrêmement grosse volumétrie

  • Latence : faible

  • Intégration : facile notamment grâce à Kafka Connect


AWS SNS

  • Courbe d'apprentissage : simple, très bien documenté

  • Event Sourcing / Event Stream Processing : Event Sourcing seulement mais possibilité de coupler avec AWS Lambda, Amazon Kinesis Data Streams, Apache Flink, Apache Kafka

  • Rétention de données : quelques heures

  • Volumétrie : modérée

  • Latence : faible

  • Intégration : facile dans un environnement AWS, peut être plus difficile sinon


Azure Event Hubs

  • Courbe d'apprentissage : complexe pour les débutants (peut-être moins que Apache Kafka)

  • Event Sourcing / Event Stream Processing : Event Sourcing seulement mais possibilité de coupler avec Azure Stream Analytics, Azure Functions, Apache Flink, Apache Kafka

  • Rétention de données : 90 jours maximum

  • Volumétrie : Extrêmement grosse volumétrie

  • Latence : faible

  • Intégration : facile (et même une compatibilité native avec les clients Kafka !)



Et qu'est-ce que je peux conclure ?


Évidemment, ce n'est qu'une liste non exhaustive de ce qui existe et votre choix (ou vos choix) dépend de votre situation.


J'ai toujours un penchant pour Kafka, mais ce n'est pas le plus facile à adopter donc lorsque les deadlines sont serrées, un autre choix peut être plus judicieux.


Prenez toujours le temps de prendre en considération vos besoins et ce qui vous ait offert pour vous limiter les mauvaises surprises.

Posts récents

Voir tout

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 e

Comments


bottom of page