Je pense que séparer et communiquer à travers des interfaces claires te fait largement gagner en maintenabilité ce que tu peux perdre en latence. 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).
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.
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.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Comparatif avec d'autres langages orientés "actor model"
Posté par Jean Parpaillon . En réponse à la dépêche Sortie d’Erlang/OTP 24. Évalué à 2. Dernière modification le 30 juillet 2021 à 10:21.
Je pense que séparer et communiquer à travers des interfaces claires te fait largement gagner en maintenabilité ce que tu peux perdre en latence. 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).
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.
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.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier