Pourquoi les architectures basées sur les files de messages sont-elles moins populaires aujourd’hui ?

xguru · 2024-06-21T11:03:01+09:00

Jusqu’au début des années 2010, on parlait beaucoup de la construction de systèmes distribués basés sur les MQ, mais aujourd’hui il y a beaucoup moins d’articles à ce sujet J’ai quelques hypothèses en tête, et je me demande si c’est l’une d’elles ou si d’autres ont un autre avis Redis couvre désormais la plupart des cas d’usage, y compris le cache, donc exploiter un broker de messages séparé n’a plus vraiment d’intérêt. Kafka, lui, est parti sur du très grand volume. Les BD, au sens large, sont devenues bien meilleures pour traiter de gros volumes, donc les traitements « temporaires » se font dans le stockage principal On a fini par comprendre que les architectures basées sur les MQ ne fonctionnaient pas aussi bien qu’espéré, donc on utilise maintenant d’autres approches En réalité, la technologie MQ est simplement entrée en phase de maturité, donc elle n’est plus assez intéressante pour qu’on écrive dessus. Mais elle reste largement utilisée hnthrowaway_99 Beaucoup d’architectures « populaires » de la fin des années 2000 et du début des années 2010 ont fini par disparaître quand on a compris une chose : « Vous n’êtes pas Google. Votre entreprise ne deviendra jamais Google » À cette époque, il y avait un fort désir de « construire comme les grandes entreprises à succès » Mais depuis, beaucoup ont compris que 99 % des entreprises n’ont pas besoin de cette complexité Le matériel et les bases de données standards se sont énormément améliorés, donc le nombre d’entreprises qui ont besoin de ce genre de « scalability trick » diminue de plus en plus Mon seuil pour « Y a-t-il une raison pour laquelle on ne pourrait pas faire tout ça avec Postgres ? » est bien plus élevé qu’il y a 10 ans Commentaires sous ce message On dispose maintenant de machines uniques bien plus puissantes à un coût raisonnable. Avant, il fallait de petits clusters, mais aujourd’hui un seul système peut absorber beaucoup de charges variées Pour être honnête, j’ai participé chez Google à plusieurs projets visant à supprimer les files d’attente. Donc c’est peut-être plus qu’un simple recul de popularité biglain C’est cynique, mais selon moi les architectures MQ et les blogs à leur sujet relevaient du « Resume Driven Development » : des gens faisaient des choses qui auraient pu tourner sur un seul laptop, sans jamais devoir dépasser le monolithe. Ce sont probablement les mêmes personnes qui ont construit des désastres microservices cauchemardesques coûtant des dizaines de milliers d’euros par mois sur AWS Les gens « qui donnent la priorité à l’accumulation d’exploits techniques dans leur carrière plutôt qu’à la résolution pragmatique de vrais problèmes métier » font aujourd’hui du battage autour de l’IA dans leurs blogs tuckerconnelly J’ai récemment abandonné des microservices pour revenir à un monolithe, car c’était trop complexe et il y avait trop de code dupliqué. Sans microservices, le besoin de files de messages diminue Pour les tâches asynchrones, j’ai utilisé RabbitMQ sur un projet, et ça m’a paru beaucoup trop ancien et surconçu Et beaucoup d’outils de son écosystème (Celery) n’étaient pas aussi bons que des outils modernes construits autour de Redis (bullmq) Pour les processus multi-étapes de type DAG, je préfère si possible tout faire dans une grosse tâche, ou en divisant en un petit nombre de tâches Si on a vraiment besoin d’un DAG, il existe des outils conçus spécifiquement pour ça (Airflow). Mais j’ai entendu dire que le débogage y est difficile, donc mieux vaut éviter si possible Je reste sur un nœud Redis unique, car je trouve son architecture multi-nœuds ridiculement trop complexe et problématique à faire évoluer. Mais le sharding manuel me convient et fonctionne bien pour moi Commentaire de kypro sur ce message D’après mon expérience, le monolithe ne réduit pas la complexité, il ne fait que la déplacer Le plus gros problème du monolithe, c’est que la séparation des préoccupations entre domaines n’est ni claire ni explicite ; avec le temps, le code finit facilement en énorme plat de spaghetti hautement interconnecté C’est encore plus vrai lorsqu’on construit de grands projets avec beaucoup de développeurs, surtout si nombre d’entre eux ne comprennent pas toute la complexité métier du code qu’ils manipulent Le monolithe convient aux petits projets avec peu de développeurs, mais sinon la plupart des équipes finissent par regretter ce choix au bout de quelques années Je ne suis pas non plus d’accord sur le sujet de la duplication de code. Si on utilise le même langage et qu’on partage des packages entre projets, je ne vois pas pourquoi ce serait un gros problème En tout cas, en travaillant sur des microservices, je n’ai jamais rencontré ce genre de problème Et je voudrais aussi remettre en question l’idée que les microservices sont en moyenne plus complexes que les monolithes Ce que je préfère dans l’architecture microservices, c’est à quel point il est simple de comprendre un microservice individuel et d’y contribuer L’architecture et le provisioning peuvent être plus complexes, mais du point de vue du développeur qui travaille dessus, c’est bien plus simple qu’un monolithe democracy Cette idée me semble juste : « La technologie MQ est simplement arrivée à maturité, elle n’est plus assez intéressante pour qu’on écrive dessus, mais elle reste largement utilisée » Les architectures basées sur la messagerie sont très populaires Commentaires sur ce message casper14 : d’accord. C’est juste devenu un outil parmi d’autres. Plus personne n’écrit d’articles sur la manière d’utiliser des machines virtuelles dans le cloud bwhaley : c’est exactement ça. Je parierais que presque tous les systèmes distribués exécutés à grande échelle utilisent des files de messages d’une manière ou d’une autre ipsum2 : c’est probablement l’explication. Avant, les posts sur la réécriture d’Angular en React étaient populaires ; aujourd’hui, tout le monde utilise juste React, ou écrit sur la réécriture de React en Vue busterarm Je vais donner une réponse impopulaire Les files, les streams et le Pub/Sub sont des concepts que la plupart des ingénieurs ne comprennent pas bien Ils ne savent pas quand en avoir besoin, ni comment les utiliser correctement, et ils les emploient pour de mauvaises raisons Je travaille encore avec tout ce qui précède (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub) Je travaille dans une entreprise qui ne recrute que les ingénieurs les plus « brillants », issus des 3 ou 4 meilleures universités d’Amérique du Nord, et c’est presque toujours leur premier emploi Nos ingénieurs ont fait ce genre de folies : pousser en un instant des dizaines de milliers de messages de 100 MB dans RabbitMQ, puis se demander pourquoi tout explose envoyer régulièrement des messages assez volumineux dans RabbitMQ malgré tous les avertissements disant de ne pas le faire démarrer un nouveau projet en 2024 avec la dernière version de RabbitMQ et vouloir utiliser des classic queues créer des quorum queues sans politique de réplication, ou littéralement ne rien faire pour assurer la HA exposer un cluster sur Internet avec un utilisateur d’administration guest/guest voir l’architecte le plus haut gradé de l’organisation déclarer un nouveau pattern d’architecture, organiser une réunion générale et faire une démo en louant la vertu de mettre un message dans une file, puis de créer un backchannel pour qu’un second consommateur puisse traiter à la demande les messages présents dans la file (et que ce ne soit donc plus vraiment une file) et à part moi, personne n’a demandé « pourquoi mettre dans une file un message qui doit être traité dans l’ordre ? », et ce « pattern » s’est installé ! utiliser Kafka comme file de messages par défaut transférer des données d’un data center central vers des data centers répartis dans le monde entier, avec verrou global sur l’objet et toutes les opérations qui vont avec jusqu’à confirmation par chaque data center destinataire de la réception de l’objet mis à jour, puis prétendre que le processus est asynchrone parce que les données étaient envoyées avec une requête AJAX Au final, les gens réussissent malgré tout, même sans avoir à faire des choses particulièrement extraordinaires. Donc ces outils sont parfois mal utilisés, surutilisés ou sous-utilisés Là où ils sont bien utilisés, vous n’en entendez probablement pas parler Fait important : dans notre organisation, il y a plus de 30 microservices par ingénieur. Pitié, tuez-moi. Je préférerais littéralement devenir Kurt Cobain plutôt que de travailler dans une autre organisation avec une énorme monorepo contenant des milliers de microservices Commentaires sur ce message zug_zug : pour étayer cette théorie avec des données réelles J’ai travaillé à New York dans une startup qui utilisait Akka (le système de queueing orienté événements de Scala) Pourquoi ? Parce qu’un manager d’un emploi précédent avait « sauvé » son entreprise avec cette approche « quand tout était lent », et il l’avait donc imposée dans son nouveau poste Quels besoins justifiaient réellement cette mise en file ? Afficher les 401k des employés via un site web, leur permettre de modifier l’allocation d’actifs, et envoyer quelques centaines d’e-mails par jour, rien de plus Comme on pouvait s’y attendre, presque personne ne se connectait au site 401k Environ un an après mon arrivée, j’ai réalisé que les serveurs étaient continuellement mal configurés et que, fondamentalement, la concurrence sur les requêtes web était de 0 (on ne s’en était pas rendu compte parce que deux serveurs de production suffisaient à traiter tout le trafic nécessaire) Akka a finalement été supprimé parce qu’il ajoutait une complexité inutile et superflue Le mois dernier, cette entreprise a fait un nouveau tour de financement avec option de récupération en cash ; sa valorisation a visiblement augmenté et elle semble toujours bien se porter scary-size : ça ne ressemble pas vraiment à une équipe qui n’embauche que des ingénieurs « brillants », non ? roncesvalles : on dirait surtout qu’il n’y a pas de processus de design review. Et moi, je préférerais recruter un développeur avec 2 à 5 ans d’expérience issu d’une université inconnue plutôt qu’un jeune diplômé d’une fac célèbre. Ce qu’un ingénieur logiciel apprend et la façon dont il progresse pendant ses 5 premières années de carrière sont énormes, probablement plus que sur tout le reste de sa carrière réuni. burutthrow Je pense que les MQ se sont largement commoditisés Si on achète Kafka comme service chez Confluent, RedPanda ou MSK, on n’a plus besoin de l’administrer soi-même La capture de données de changement (CDC) est aussi devenue excellente et mainstream. Écrire les données dans un SGBDR, puis capturer les changements pour les propager vers d’autres systèmes, est relativement simple Par exemple, les files de messages ne sont alors que la colonne vertébrale utilisée par le système CDC pour transporter les messages ; ce type de pattern fait que les gens n’écrivent pas forcément sur Kafka lui-même Ces architectures existent clairement toujours et répondent aux contraintes de la plupart des organisations Le fait d’avoir des files du type write once, read many, comme Kafka, permet d’exposer des API à d’autres parties de l’organisation. Beaucoup d’entreprises utilisent ce pattern pour partager et mélanger des données entre équipes Une petite équipe qui possède énormément de microservices fait très « développement piloté par le CV », mais dans une entreprise de plus de 100 ingénieurs, ce pattern peut avoir du sens angarg12 Les MQ sont un outil de la boîte à outils des systèmes distribués. Quand le contexte s’y prête, ça marche très bien Si l’une de tes théories est vraiment la bonne, je pense que c’est celle-ci : « En général, les gens écrivent des billets de blog sur les nouveautés brillantes » Personnellement, j’utilise toujours des files dans mes conceptions, surtout pour transférer des données entre systèmes différents nécessitant un fort découplage La seule vraie douleur que j’ai connue, c’est lorsqu’un système amont a rejoué 7 jours de données et a bouché la file avec de vieilles requêtes En fonctionnement normal, il aurait fallu plus de 100 heures pour tout traiter, et la latence des nouvelles données aurait aussi explosé La solution a été de purger manuellement la file, puis de recharger manuellement les données récentes manquantes Il faut faire attention à la taille non bornée des files, mais je pense toujours que c’est un excellent outil rossdavidh Les MQ, dans le Gartner Hype Cycle, ont dépassé le « Peak of inflated expectations » le « trough of disillusionment » et se dirigent vers le « Slope of Enlightenment », voire le « plateau of productivity » robertclaus Je trouve très intéressant que le commentaire disant « manifestement, nous utilisons toujours tous des files de messages et des workers, nous n’écrivons simplement plus d’articles à ce sujet » soit noyé derrière les débats sur les microservices et la vraie scalabilité Un ingénieur junior qui lit ce fil pourrait avoir à tort l’impression qu’il ne faut plus déporter les calculs lourds du serveur web vers des workers pm90 Il y a moins de billets de blog à ce sujet parce que la technologie est devenue ennuyeuse Et c’est une bonne chose. Par exemple, la documentation officielle de RabbitMQ est bien meilleure et très utile Les gens l’utilisent comme ils utilisent Postgres/MySQL : comme un outil de base Il n’y a rien de particulièrement spectaculaire non plus dans le fait de concevoir une architecture autour de ça J’adore les logiciels ennuyeux : « I love boring software » slowmovintarget La plupart de ces architectures tournaient dans des data centers d’entreprise Avec la transition vers le cloud et la montée de petits services stateless (avec l’arrivée des SPA), le besoin de systèmes complexes orientés événements, étape par étape, a diminué Par exemple, sur AWS, utiliser SQS avec un peu de SNS, ou Kinesis pour quelques cas, suffit largement. Les MQ ne sont alors plus au centre de la conception Les architectures basées sur les MQ sont très adaptées au traitement de données, mais pas aux sites web interactifs ; si la plupart des gens construisent des sites interactifs, le choix devient assez évident Je conçois encore des systèmes événementiels pour le traitement des données (surtout lorsqu’il existe de nouveaux faits, mais qu’il s’agit de données métier immuables pour lesquelles il faudrait « corriger » ou connaître d’autres informations à un instant antérieur) Mais pour la plupart des applications… ce n’est pas nécessaire mannyv Tout notre backend est basé sur des files Si c’est asynchrone et qu’un temps de réponse rapide n’est pas nécessaire, j’utilise des files. C’est simple, fiable, et les files peuvent piloter des lambdas Les files facilitent aussi la collecte de métriques et de données de performance sous forte charge, la file peut gonfler jusqu’à plusieurs millions de messages puis redescendre avec le temps ou on peut lancer des centaines de lambdas pour traiter tous les messages selon les besoins vishnugupta D’après mon expérience, les MQ ont été abstraits, pas supprimés Par exemple, une file SQS + polling est devenue un processus qui appelle moins les serveurs. Il y a toujours une file de messages quelque part, elle n’est simplement plus exposée AWS SNS, qui est un niveau d’abstraction au-dessus de SQS, est aussi devenu si riche fonctionnellement qu’il peut pratiquement remplacer SQS De plus, le streaming est devenu une technologie très stable, donc les cas d’usage qui utilisaient les files comme pipeline de streaming ont migré vers de vraies solutions de streaming memset Cela vient peut-être du fait que les lambdas (fonctions cloud) sont devenues plus populaires et sont prises en charge sur plusieurs plateformes Quand on ajoute quelque chose dans une file, il faut ensuite l’en retirer et le traiter. Une lambda fait cela en une seule invocation. Et il n’y a pas besoin d’exécuter ni de faire scaler des workers Je pense que Kafka reste populaire parce qu’il sert de stockage temporaire de données, avec tout un grand écosystème pour la collecte depuis les streams Personnellement, j’utilise beaucoup les files et je construis une alternative open source à SQS. Je me demande si une alternative open source à Lambda serait aussi utile liampulles « La technologie MQ est simplement entrée en phase de maturité, donc elle n’est plus assez intéressante pour qu’on écrive dessus. Mais elle reste largement utilisée » Oui, c’est ça. Pour les cas simples de communication asynchrone via une messagerie Pub/Sub simple, c’est très utile et pas trop difficile à utiliser Nous (en tant que communauté de développeurs) avons dépassé l’event sourcing, les réseaux complexes et la construction d’échelles inutiles. Autrement dit, nous avons dépassé le cycle du hype Notre équipe utilise NATS pour le Pub/Sub asynchrone et pour le Request/Response synchrone C’est un modèle orienté commandes, et nous avons une énorme table de logs contenant tous les messages que nous avons envoyés Les schémas et l’usage de ces messages sont internes à notre équipe, et ils sont supprimés de NATS après usage Nous faisons de l’at-least-once delivery et nous attendons des gestionnaires de messages qu’ils soient idempotents Nous avons eu un ou deux problèmes de messages rejoués ou manquants à cause d’une mauvaise configuration de NATS, mais dans l’ensemble cela a été un vrai succès, et nous étions une équipe de trois développeurs Pour moi, c’est comme Kubernetes : si on s’en tient aux bases et qu’on n’essaie pas d’être trop malin, ça marche bien

(news.ycombinator.com)

49 points par xguru 2024-06-21 | 11 commentaires | Partager sur WhatsApp

Jusqu’au début des années 2010, on parlait beaucoup de la construction de systèmes distribués basés sur les MQ, mais aujourd’hui il y a beaucoup moins d’articles à ce sujet
J’ai quelques hypothèses en tête, et je me demande si c’est l’une d’elles ou si d’autres ont un autre avis
- Redis couvre désormais la plupart des cas d’usage, y compris le cache, donc exploiter un broker de messages séparé n’a plus vraiment d’intérêt. Kafka, lui, est parti sur du très grand volume.
- Les BD, au sens large, sont devenues bien meilleures pour traiter de gros volumes, donc les traitements « temporaires » se font dans le stockage principal
- On a fini par comprendre que les architectures basées sur les MQ ne fonctionnaient pas aussi bien qu’espéré, donc on utilise maintenant d’autres approches
- En réalité, la technologie MQ est simplement entrée en phase de maturité, donc elle n’est plus assez intéressante pour qu’on écrive dessus. Mais elle reste largement utilisée

hnthrowaway_99

Beaucoup d’architectures « populaires » de la fin des années 2000 et du début des années 2010 ont fini par disparaître quand on a compris une chose : « Vous n’êtes pas Google. Votre entreprise ne deviendra jamais Google »
À cette époque, il y avait un fort désir de « construire comme les grandes entreprises à succès »
Mais depuis, beaucoup ont compris que 99 % des entreprises n’ont pas besoin de cette complexité
Le matériel et les bases de données standards se sont énormément améliorés, donc le nombre d’entreprises qui ont besoin de ce genre de « scalability trick » diminue de plus en plus
Mon seuil pour « Y a-t-il une raison pour laquelle on ne pourrait pas faire tout ça avec Postgres ? » est bien plus élevé qu’il y a 10 ans
Commentaires sous ce message
- On dispose maintenant de machines uniques bien plus puissantes à un coût raisonnable. Avant, il fallait de petits clusters, mais aujourd’hui un seul système peut absorber beaucoup de charges variées
- Pour être honnête, j’ai participé chez Google à plusieurs projets visant à supprimer les files d’attente. Donc c’est peut-être plus qu’un simple recul de popularité

biglain

C’est cynique, mais selon moi les architectures MQ et les blogs à leur sujet relevaient du « Resume Driven Development » : des gens faisaient des choses qui auraient pu tourner sur un seul laptop, sans jamais devoir dépasser le monolithe.
Ce sont probablement les mêmes personnes qui ont construit des désastres microservices cauchemardesques coûtant des dizaines de milliers d’euros par mois sur AWS
Les gens « qui donnent la priorité à l’accumulation d’exploits techniques dans leur carrière plutôt qu’à la résolution pragmatique de vrais problèmes métier » font aujourd’hui du battage autour de l’IA dans leurs blogs

tuckerconnelly

J’ai récemment abandonné des microservices pour revenir à un monolithe, car c’était trop complexe et il y avait trop de code dupliqué. Sans microservices, le besoin de files de messages diminue
Pour les tâches asynchrones, j’ai utilisé RabbitMQ sur un projet, et ça m’a paru beaucoup trop ancien et surconçu
Et beaucoup d’outils de son écosystème (Celery) n’étaient pas aussi bons que des outils modernes construits autour de Redis (bullmq)
Pour les processus multi-étapes de type DAG, je préfère si possible tout faire dans une grosse tâche, ou en divisant en un petit nombre de tâches
Si on a vraiment besoin d’un DAG, il existe des outils conçus spécifiquement pour ça (Airflow). Mais j’ai entendu dire que le débogage y est difficile, donc mieux vaut éviter si possible
Je reste sur un nœud Redis unique, car je trouve son architecture multi-nœuds ridiculement trop complexe et problématique à faire évoluer. Mais le sharding manuel me convient et fonctionne bien pour moi
Commentaire de kypro sur ce message
- D’après mon expérience, le monolithe ne réduit pas la complexité, il ne fait que la déplacer
- Le plus gros problème du monolithe, c’est que la séparation des préoccupations entre domaines n’est ni claire ni explicite ; avec le temps, le code finit facilement en énorme plat de spaghetti hautement interconnecté
- C’est encore plus vrai lorsqu’on construit de grands projets avec beaucoup de développeurs, surtout si nombre d’entre eux ne comprennent pas toute la complexité métier du code qu’ils manipulent
- Le monolithe convient aux petits projets avec peu de développeurs, mais sinon la plupart des équipes finissent par regretter ce choix au bout de quelques années
- Je ne suis pas non plus d’accord sur le sujet de la duplication de code. Si on utilise le même langage et qu’on partage des packages entre projets, je ne vois pas pourquoi ce serait un gros problème
- En tout cas, en travaillant sur des microservices, je n’ai jamais rencontré ce genre de problème
- Et je voudrais aussi remettre en question l’idée que les microservices sont en moyenne plus complexes que les monolithes
- Ce que je préfère dans l’architecture microservices, c’est à quel point il est simple de comprendre un microservice individuel et d’y contribuer
- L’architecture et le provisioning peuvent être plus complexes, mais du point de vue du développeur qui travaille dessus, c’est bien plus simple qu’un monolithe

democracy

Cette idée me semble juste : « La technologie MQ est simplement arrivée à maturité, elle n’est plus assez intéressante pour qu’on écrive dessus, mais elle reste largement utilisée »
Les architectures basées sur la messagerie sont très populaires
Commentaires sur ce message
- casper14 : d’accord. C’est juste devenu un outil parmi d’autres. Plus personne n’écrit d’articles sur la manière d’utiliser des machines virtuelles dans le cloud
- bwhaley : c’est exactement ça. Je parierais que presque tous les systèmes distribués exécutés à grande échelle utilisent des files de messages d’une manière ou d’une autre
- ipsum2 : c’est probablement l’explication. Avant, les posts sur la réécriture d’Angular en React étaient populaires ; aujourd’hui, tout le monde utilise juste React, ou écrit sur la réécriture de React en Vue

busterarm

Je vais donner une réponse impopulaire
Les files, les streams et le Pub/Sub sont des concepts que la plupart des ingénieurs ne comprennent pas bien
- Ils ne savent pas quand en avoir besoin, ni comment les utiliser correctement, et ils les emploient pour de mauvaises raisons
- Je travaille encore avec tout ce qui précède (SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub)
Je travaille dans une entreprise qui ne recrute que les ingénieurs les plus « brillants », issus des 3 ou 4 meilleures universités d’Amérique du Nord, et c’est presque toujours leur premier emploi
Nos ingénieurs ont fait ce genre de folies :
- pousser en un instant des dizaines de milliers de messages de 100 MB dans RabbitMQ, puis se demander pourquoi tout explose
- envoyer régulièrement des messages assez volumineux dans RabbitMQ malgré tous les avertissements disant de ne pas le faire
- démarrer un nouveau projet en 2024 avec la dernière version de RabbitMQ et vouloir utiliser des classic queues
- créer des quorum queues sans politique de réplication, ou littéralement ne rien faire pour assurer la HA
- exposer un cluster sur Internet avec un utilisateur d’administration guest/guest
- voir l’architecte le plus haut gradé de l’organisation déclarer un nouveau pattern d’architecture, organiser une réunion générale et faire une démo
  - en louant la vertu de mettre un message dans une file, puis de créer un backchannel pour qu’un second consommateur puisse traiter à la demande les messages présents dans la file (et que ce ne soit donc plus vraiment une file)
  - et à part moi, personne n’a demandé « pourquoi mettre dans une file un message qui doit être traité dans l’ordre ? », et ce « pattern » s’est installé !
- utiliser Kafka comme file de messages par défaut
- transférer des données d’un data center central vers des data centers répartis dans le monde entier, avec verrou global sur l’objet et toutes les opérations qui vont avec jusqu’à confirmation par chaque data center destinataire de la réception de l’objet mis à jour, puis prétendre que le processus est asynchrone parce que les données étaient envoyées avec une requête AJAX
Au final, les gens réussissent malgré tout, même sans avoir à faire des choses particulièrement extraordinaires. Donc ces outils sont parfois mal utilisés, surutilisés ou sous-utilisés
Là où ils sont bien utilisés, vous n’en entendez probablement pas parler
Fait important : dans notre organisation, il y a plus de 30 microservices par ingénieur. Pitié, tuez-moi. Je préférerais littéralement devenir Kurt Cobain plutôt que de travailler dans une autre organisation avec une énorme monorepo contenant des milliers de microservices
Commentaires sur ce message
- zug_zug : pour étayer cette théorie avec des données réelles
  - J’ai travaillé à New York dans une startup qui utilisait Akka (le système de queueing orienté événements de Scala)
  - Pourquoi ? Parce qu’un manager d’un emploi précédent avait « sauvé » son entreprise avec cette approche « quand tout était lent », et il l’avait donc imposée dans son nouveau poste
  - Quels besoins justifiaient réellement cette mise en file ? Afficher les 401k des employés via un site web, leur permettre de modifier l’allocation d’actifs, et envoyer quelques centaines d’e-mails par jour, rien de plus
  - Comme on pouvait s’y attendre, presque personne ne se connectait au site 401k
  - Environ un an après mon arrivée, j’ai réalisé que les serveurs étaient continuellement mal configurés et que, fondamentalement, la concurrence sur les requêtes web était de 0
  - (on ne s’en était pas rendu compte parce que deux serveurs de production suffisaient à traiter tout le trafic nécessaire)
  - Akka a finalement été supprimé parce qu’il ajoutait une complexité inutile et superflue
  - Le mois dernier, cette entreprise a fait un nouveau tour de financement avec option de récupération en cash ; sa valorisation a visiblement augmenté et elle semble toujours bien se porter
- scary-size : ça ne ressemble pas vraiment à une équipe qui n’embauche que des ingénieurs « brillants », non ?
- roncesvalles : on dirait surtout qu’il n’y a pas de processus de design review. Et moi, je préférerais recruter un développeur avec 2 à 5 ans d’expérience issu d’une université inconnue plutôt qu’un jeune diplômé d’une fac célèbre. Ce qu’un ingénieur logiciel apprend et la façon dont il progresse pendant ses 5 premières années de carrière sont énormes, probablement plus que sur tout le reste de sa carrière réuni.

burutthrow

Je pense que les MQ se sont largement commoditisés
Si on achète Kafka comme service chez Confluent, RedPanda ou MSK, on n’a plus besoin de l’administrer soi-même
La capture de données de changement (CDC) est aussi devenue excellente et mainstream. Écrire les données dans un SGBDR, puis capturer les changements pour les propager vers d’autres systèmes, est relativement simple
Par exemple, les files de messages ne sont alors que la colonne vertébrale utilisée par le système CDC pour transporter les messages ; ce type de pattern fait que les gens n’écrivent pas forcément sur Kafka lui-même
Ces architectures existent clairement toujours et répondent aux contraintes de la plupart des organisations
Le fait d’avoir des files du type write once, read many, comme Kafka, permet d’exposer des API à d’autres parties de l’organisation. Beaucoup d’entreprises utilisent ce pattern pour partager et mélanger des données entre équipes
Une petite équipe qui possède énormément de microservices fait très « développement piloté par le CV », mais dans une entreprise de plus de 100 ingénieurs, ce pattern peut avoir du sens

angarg12

Les MQ sont un outil de la boîte à outils des systèmes distribués. Quand le contexte s’y prête, ça marche très bien
Si l’une de tes théories est vraiment la bonne, je pense que c’est celle-ci : « En général, les gens écrivent des billets de blog sur les nouveautés brillantes »
Personnellement, j’utilise toujours des files dans mes conceptions, surtout pour transférer des données entre systèmes différents nécessitant un fort découplage
La seule vraie douleur que j’ai connue, c’est lorsqu’un système amont a rejoué 7 jours de données et a bouché la file avec de vieilles requêtes
- En fonctionnement normal, il aurait fallu plus de 100 heures pour tout traiter, et la latence des nouvelles données aurait aussi explosé
- La solution a été de purger manuellement la file, puis de recharger manuellement les données récentes manquantes
Il faut faire attention à la taille non bornée des files, mais je pense toujours que c’est un excellent outil

rossdavidh

Les MQ, dans le Gartner Hype Cycle, ont dépassé
- le « Peak of inflated expectations »
- le « trough of disillusionment »
- et se dirigent vers le « Slope of Enlightenment », voire le « plateau of productivity »

robertclaus

Je trouve très intéressant que le commentaire disant « manifestement, nous utilisons toujours tous des files de messages et des workers, nous n’écrivons simplement plus d’articles à ce sujet » soit noyé derrière les débats sur les microservices et la vraie scalabilité
Un ingénieur junior qui lit ce fil pourrait avoir à tort l’impression qu’il ne faut plus déporter les calculs lourds du serveur web vers des workers

pm90

Il y a moins de billets de blog à ce sujet parce que la technologie est devenue ennuyeuse
Et c’est une bonne chose. Par exemple, la documentation officielle de RabbitMQ est bien meilleure et très utile
Les gens l’utilisent comme ils utilisent Postgres/MySQL : comme un outil de base
Il n’y a rien de particulièrement spectaculaire non plus dans le fait de concevoir une architecture autour de ça
J’adore les logiciels ennuyeux : « I love boring software »

slowmovintarget

La plupart de ces architectures tournaient dans des data centers d’entreprise
Avec la transition vers le cloud et la montée de petits services stateless (avec l’arrivée des SPA), le besoin de systèmes complexes orientés événements, étape par étape, a diminué
Par exemple, sur AWS, utiliser SQS avec un peu de SNS, ou Kinesis pour quelques cas, suffit largement. Les MQ ne sont alors plus au centre de la conception
Les architectures basées sur les MQ sont très adaptées au traitement de données, mais pas aux sites web interactifs ; si la plupart des gens construisent des sites interactifs, le choix devient assez évident
Je conçois encore des systèmes événementiels pour le traitement des données (surtout lorsqu’il existe de nouveaux faits, mais qu’il s’agit de données métier immuables pour lesquelles il faudrait « corriger » ou connaître d’autres informations à un instant antérieur)
Mais pour la plupart des applications… ce n’est pas nécessaire

mannyv

Tout notre backend est basé sur des files
Si c’est asynchrone et qu’un temps de réponse rapide n’est pas nécessaire, j’utilise des files. C’est simple, fiable, et les files peuvent piloter des lambdas
Les files facilitent aussi la collecte de métriques et de données de performance
- sous forte charge, la file peut gonfler jusqu’à plusieurs millions de messages puis redescendre avec le temps
- ou on peut lancer des centaines de lambdas pour traiter tous les messages selon les besoins

vishnugupta

D’après mon expérience, les MQ ont été abstraits, pas supprimés
Par exemple, une file SQS + polling est devenue un processus qui appelle moins les serveurs. Il y a toujours une file de messages quelque part, elle n’est simplement plus exposée
AWS SNS, qui est un niveau d’abstraction au-dessus de SQS, est aussi devenu si riche fonctionnellement qu’il peut pratiquement remplacer SQS
De plus, le streaming est devenu une technologie très stable, donc les cas d’usage qui utilisaient les files comme pipeline de streaming ont migré vers de vraies solutions de streaming

memset

Cela vient peut-être du fait que les lambdas (fonctions cloud) sont devenues plus populaires et sont prises en charge sur plusieurs plateformes
Quand on ajoute quelque chose dans une file, il faut ensuite l’en retirer et le traiter. Une lambda fait cela en une seule invocation. Et il n’y a pas besoin d’exécuter ni de faire scaler des workers
Je pense que Kafka reste populaire parce qu’il sert de stockage temporaire de données, avec tout un grand écosystème pour la collecte depuis les streams
Personnellement, j’utilise beaucoup les files et je construis une alternative open source à SQS. Je me demande si une alternative open source à Lambda serait aussi utile

liampulles

« La technologie MQ est simplement entrée en phase de maturité, donc elle n’est plus assez intéressante pour qu’on écrive dessus. Mais elle reste largement utilisée »
- Oui, c’est ça. Pour les cas simples de communication asynchrone via une messagerie Pub/Sub simple, c’est très utile et pas trop difficile à utiliser
Nous (en tant que communauté de développeurs) avons dépassé l’event sourcing, les réseaux complexes et la construction d’échelles inutiles. Autrement dit, nous avons dépassé le cycle du hype
Notre équipe utilise NATS pour le Pub/Sub asynchrone et pour le Request/Response synchrone
- C’est un modèle orienté commandes, et nous avons une énorme table de logs contenant tous les messages que nous avons envoyés
- Les schémas et l’usage de ces messages sont internes à notre équipe, et ils sont supprimés de NATS après usage
- Nous faisons de l’at-least-once delivery et nous attendons des gestionnaires de messages qu’ils soient idempotents
Nous avons eu un ou deux problèmes de messages rejoués ou manquants à cause d’une mauvaise configuration de NATS, mais dans l’ensemble cela a été un vrai succès, et nous étions une équipe de trois développeurs
Pour moi, c’est comme Kubernetes : si on s’en tient aux bases et qu’on n’essaie pas d’être trop malin, ça marche bien

11 commentaires

finnchoi 2024-06-25

Il existe des situations où une file de messages est nécessaire. Cependant, pour la plupart des tailles de système et des usages, utiliser une file ou faire fonctionner le système en cluster augmente souvent la complexité sans apporter de réel avantage en termes de performances. Le moment où les architectures complexes dont se vantent les grandes entreprises, conçues pour la scalabilité et de très gros volumes de données, deviendront réellement adaptées à mon système pourrait bien ne jamais arriver.

Même face à des technologies récentes très séduisantes et à des architectures élégantes, il est nécessaire de réfléchir aux problèmes concrets afin de choisir une solution appropriée. Dans la plupart des cas, il n’y a pas tant de données à traiter, et PostgreSQL suffit souvent.

Nous avons pris conscience de ce problème et développons une base de données capable de traiter, sur un seul nœud, des données de l’ordre du téraoctet tout en conservant une architecture simple. Avec un peu de prudence, nous vous recommandons aussi d’y jeter un œil comme autre option.
Mettre les données de jurisprudence dans un état permettant une recherche rapide

dakbutfly 2024-06-24

La programmation procédurale est largement perçue comme facile à comprendre, alors qu’une approche fondée sur des files de messages n’est pas forcément intuitive au premier abord et peut rendre l’architecture difficile à saisir. Dans une entreprise, le niveau de connaissances n’est généralement pas uniforme, et lorsqu’on utilise des MQ avec une mauvaise compréhension, cela peut vite tourner à l’enfer.

Cela ne vaut pas seulement pour les MQ : je pense que ce genre de problème survient toujours quand on applique, sans formation globale suffisante, des technologies qui exigent un certain niveau de connaissances.

nemorize 2024-06-21

Avec PHP, les MQ sont pratiquement indispensables...

halfenif 2024-06-21

Aïe !

En ce moment, je travaille justement sur un toy project dont le nom contient Quee.

kandk 2024-06-21

Honnêtement, si le service est destiné à 99 % uniquement à notre marché national, je pense que tout ça est inutile..

superwoou 2024-06-21

Ne devrait-il pas être plus important de considérer, plutôt que le périmètre du service, sa nature et le niveau d’exigence en matière de rentabilité des coûts ?

2024-06-21

[Ce commentaire a été masqué.]

bus710 2024-06-22

Est-ce simplement parce que les processus de prise de décision sont verticaux, et que ce qui est « orienté procédure » est donc davantage préféré ou jugé plus adapté ?
Je me demande aussi si, lorsque les départements et les équipes sont organisés de manière plus souple, une architecture moins orientée procédure fonctionne plus facilement, et si, par conséquent, les applications de ces files d’attente peuvent mieux fonctionner.

savvykang 2024-06-21

On dirait que le développement guidé par le CV est le mot-clé qui traverse ce genre de phénomène de mode.

hyeonseokoh94 2024-06-22

Waouh, c’est une formule mémorable : le développement piloté par le CV...

savvykang 2024-06-23

Son produit dérivé, le développement piloté par le battage médiatique, existe aussi.