I was curious about use of ZeroMQ since I use it extensively with my own RPC, PubSub system.
Spotify's Hermes
Hermes is a network messaging stack created at Spotify, on top of existing open source stack such as ZeroMQ, protobuf and gevent. We are migrating backend service from legacy stack to Hermes and this session explains the rationale behind some of the choices. It also gives a brief introduction of some typical network topology for backend messaging at Spotify. Finally we discuss some lessons learned from building such large scale Python systems and the problems we are facing.
Resources
1. https://us.pycon.org/2013/schedule/presentation/185/
2. https://www.diva-portal.org/smash/get/diva2:706244/FULLTEXT01.pdf
3. https://speakerdeck.com/mattgruter/the-story-of-why-we-migrate-to-grpc-and-how-we-go-about-it
4. https://github.com/spotify/netty-zmtp
Why did they move away from ZeroMQ to GRPC?
Just more of convenience.
gRPC is slower than any ZeroMQ RPC, but gRPC is maintained and exposes RPC, Pub/Sub and other mechanisms to support messaging operations that people generally don't want to touch. Pretty much, if someone had built everything that gRPC has onto ZeroMQ they would have stayed using ZeroMQ as their transport mechanism.
Hermes doesn't do what gRPC does and why maintain things what you don't feel is core to the business.
Personally, I don't think it is important the kind of transport you decide to use as long as there are choices. ProtoBuf over ZeroMQ, or ProtoBuf over HTTP (gRPC) or Protobuf over UDP are all acceptable choices if they meet your usability, performance and reliability expectations.
As for me
I may add HTTP3/QUIC in the future as one of the transports for my system since it is UDP based. I definitely want to see how fast HTTP3/QUIC will be first!