Par contre, je n'ai jamais vu l'intérêt d'utiliser AMQP avec erlang: tu peux avoir l'équivalent d'un broker de service en quelques lignes de code, avec une latence qui n'a rien à voir avec un service externe (RabbitMQ).
Le reroutage à chaud des messages par exemple, le monitoring, tout un tas de règles de gestions que tu peux ajouter au runtime pour que ce soit différent par environnement (taille limite des queues par exemple), tu peux aussi ne pas vouloir stocker un nombre important de messages dans la mémoire de ton processus applicatif, être agnostique des langages avec une pléthore de langages et outils déjà existant, maintenant ils font du log distribué à la kafka,... Je ne doute pas que ça soit pas très compliqué à faire en erlang, mais il faut prévoir les choses avant et c'est toujours de la complexité en plus.
Au final, que ce soit en 100% erlang ou avec des codes externes, les applications erlang sont très similaires à des micro-services, sans k8s/docker, des load balancer HTTP, des API REST, etc.
C'est pas la même granularité. On peut dire qu'OSGi c'était aussi des microservices avant l'heure. Mais ça a tout de même des différences importantes en terme de déploiement et de ce que ça implique.
Dans les architectures que je déploie, j'ai tendance à privilégier maintenant des RPC plus agnostique par rapport au langage (gRPC, protobuf sur CoAP, voir BERT, etc) mais en aucun cas un broker de message externe.
Ça veut dire que :
tu ne fais que du requête/réponse
des messages one to one
que tu ne peux pas retirer le destinataire
que c'est celui qui envoi le message qui doit gérer la stratégie de rejeu d'un message
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
Du coup oui je comprends que tu n'es pas besoin de broker de messages :)
[^] # 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é à 3.
Le reroutage à chaud des messages par exemple, le monitoring, tout un tas de règles de gestions que tu peux ajouter au runtime pour que ce soit différent par environnement (taille limite des queues par exemple), tu peux aussi ne pas vouloir stocker un nombre important de messages dans la mémoire de ton processus applicatif, être agnostique des langages avec une pléthore de langages et outils déjà existant, maintenant ils font du log distribué à la kafka,... Je ne doute pas que ça soit pas très compliqué à faire en erlang, mais il faut prévoir les choses avant et c'est toujours de la complexité en plus.
C'est pas la même granularité. On peut dire qu'OSGi c'était aussi des microservices avant l'heure. Mais ça a tout de même des différences importantes en terme de déploiement et de ce que ça implique.
Ça veut dire que :
Du coup oui je comprends que tu n'es pas besoin de broker de messages :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll