Posté par barmic 🦦 .
En réponse à la dépêche Sortie d’Erlang/OTP 24.
Évalué à 2.
Dernière modification le 30 juillet 2021 à 19:10.
Mais je suis plutôt partisan des approches 'lean' où on évite des usines à gaz pour 2-3 fonctionnalités qui nous intéressent.
J'évite de penser de cette façon. Les mots clefs n'ont pas toujours du sens en soit. Est-ce que c'est lean d'avoir de la complexité un peu partout plutôt que de regrouper tout ce sujet à un seul endroit ? Ça dépend de pleins de choses.
Il est parfois plus rapide de coder une fonctionnalité que d'apprendre à utiliser (et maintenir, et déployer, etc) des outils complexes. Je ne suis pas non plus partisan de l'approche inverse que consiste à tout coder tout seul.
C'est aussi pas simple de faire un passage de l'un à l'autre. Mais pour l'exemple le fait de regrouper tout cette problématique au même endroit permet d'avoir un comportement homogène partout.
one-to-one
Voir le module elixir Registry.
Est-ce que c'est à l'émetteur de se soucier de la liste de ses destinataires ? C'est un choix. 'fin c'est un choix jusqu'à ce que tu ai un grand nombre de destinataires ou que la liste des destinataires soit très mouvant.
que tu ne peux pas retirer le destinataire
Grâce au mécanisme de supervision des processus, le module Registry ci-dessus gère parfaitement la connexion/reconnexion d'un client. Est-ce cela dont tu parles ?
Tu garde un couplage entre l'emmeteur et le destinataire. Le plantage/mise à jour du destinataire impose un travail en plus à l'émetteur.
Oui, sauf que mettre en œuvre une stratégie à base de timeouts, de retries, voire de files d'attentes différentiées se fait en quelques dizaines de lignes de code, à comparer à la configuration d'un outil comme RabbitMQ (+ configuration du code client).
Je me doute, mais elle a donc de potentiels bugs, doit donc être pensée complètement en amont (tu as bien moins de flexibilité lors de ton run). La configuration d'un client rabbitmq c'est quelques lignes (et vraiment on parle en ligne et pas en dizaines de lignes) quelque soit le langage. La configuration d'un rabbitmq c'est fait une bonne fois pour toute.
que tu ne peut pas lisser ta charge en empilant des messages dans une fille ou si tu le fait c'est plus fragile parce que la file est géré par le destinataire et pas commune à plusieurs instances du destinataire
Voir GenStage
Si j'ai bien compris c'est l'émetteur qui doit gérer la disponibilité ou non du destinataire.
GenStage gère très bien le back pressure.
C'est très cool, ça n'est pas naturel avec AMQP (ça l'est déjà bien plus avec kafka).
Mais la back pressure ce n'est pas forcément le lissage de charge. Tu peux avoir du code qui reçoit des requêtes à un débit qui est acceptable pour toi, mais qui doit transmettre à quelqu'un d'autres qui a plus de mal. Si c'est intermittent le fait de laisser un brocker stocker les messages pour les donner tranquillement au destinataire c'est pertinent. Si tu veux être élastique de scale les destinataires en fonction de ce que tu empile, tu dois faire la remonté d'alerte ou de monitoring à la main pour ensuite avoir une autre partie qui gère tes déploiement. Avec des brocker ça peut se faire avec un peu de conf et se faire sur tout ou partie du système sans modification du code.
Je n'ai rien contre RabbitMQ (écrit en erlang en plus :D ) mais j'ai vu plusieurs cas où son utilisation n'était pas justifiée et créait un overhead énorme, pas seulement en terme de latence mais surtout en terme d'intégration et de maintenance.
Moi je n'ai pas d'action chez eux. Je répond juste à ton message qui ne voyais pas d'intérêt. Tu te retrouve à tout faire à la main (avec une certaine simplicité mais l'ajout de différentes bibliothèques) et tu n'es plus agnostique. Et surtout tu fais un choix de où tu place les responsabilités (avec ce que ça implique dans un sens comme dans l'autre). Sans aller dans l'idée qu'il faut que tout soit toujours agnostique, je me fais de petits outils amqp qui ne sont pas avec le même langage que le reste et j'en suis bien content.
Après je ne te parle pas des workflows surprenant comme router du trafic environnement pour des tests/expérimentations/bench qui te permettent de récupérer du contenu d'un environnement pour le jouer localement ou sur un autre environnement sans avoir à ajouter du code dédié à ton expérimentation.
[^] # Re: Comparatif avec d'autres langages orientés "actor model"
Posté par barmic 🦦 . En réponse à la dépêche Sortie d’Erlang/OTP 24. Évalué à 2. Dernière modification le 30 juillet 2021 à 19:10.
J'évite de penser de cette façon. Les mots clefs n'ont pas toujours du sens en soit. Est-ce que c'est lean d'avoir de la complexité un peu partout plutôt que de regrouper tout ce sujet à un seul endroit ? Ça dépend de pleins de choses.
C'est aussi pas simple de faire un passage de l'un à l'autre. Mais pour l'exemple le fait de regrouper tout cette problématique au même endroit permet d'avoir un comportement homogène partout.
Est-ce que c'est à l'émetteur de se soucier de la liste de ses destinataires ? C'est un choix. 'fin c'est un choix jusqu'à ce que tu ai un grand nombre de destinataires ou que la liste des destinataires soit très mouvant.
Tu garde un couplage entre l'emmeteur et le destinataire. Le plantage/mise à jour du destinataire impose un travail en plus à l'émetteur.
Je me doute, mais elle a donc de potentiels bugs, doit donc être pensée complètement en amont (tu as bien moins de flexibilité lors de ton run). La configuration d'un client rabbitmq c'est quelques lignes (et vraiment on parle en ligne et pas en dizaines de lignes) quelque soit le langage. La configuration d'un rabbitmq c'est fait une bonne fois pour toute.
Si j'ai bien compris c'est l'émetteur qui doit gérer la disponibilité ou non du destinataire.
C'est très cool, ça n'est pas naturel avec AMQP (ça l'est déjà bien plus avec kafka).
Mais la back pressure ce n'est pas forcément le lissage de charge. Tu peux avoir du code qui reçoit des requêtes à un débit qui est acceptable pour toi, mais qui doit transmettre à quelqu'un d'autres qui a plus de mal. Si c'est intermittent le fait de laisser un brocker stocker les messages pour les donner tranquillement au destinataire c'est pertinent. Si tu veux être élastique de scale les destinataires en fonction de ce que tu empile, tu dois faire la remonté d'alerte ou de monitoring à la main pour ensuite avoir une autre partie qui gère tes déploiement. Avec des brocker ça peut se faire avec un peu de conf et se faire sur tout ou partie du système sans modification du code.
Moi je n'ai pas d'action chez eux. Je répond juste à ton message qui ne voyais pas d'intérêt. Tu te retrouve à tout faire à la main (avec une certaine simplicité mais l'ajout de différentes bibliothèques) et tu n'es plus agnostique. Et surtout tu fais un choix de où tu place les responsabilités (avec ce que ça implique dans un sens comme dans l'autre). Sans aller dans l'idée qu'il faut que tout soit toujours agnostique, je me fais de petits outils amqp qui ne sont pas avec le même langage que le reste et j'en suis bien content.
Après je ne te parle pas des workflows surprenant comme router du trafic environnement pour des tests/expérimentations/bench qui te permettent de récupérer du contenu d'un environnement pour le jouer localement ou sur un autre environnement sans avoir à ajouter du code dédié à ton expérimentation.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll