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