Zeromq will have changed a lot since then, but some time in the 2010s, I prototyped a system using it (which was going to be a major production system in a large tech company) and had weird unexpected blocking issues with it. To debug, I sat down to read a bunch of the zeromq code, just to realize that it was using assert() to handle wire protocol errors (unrelated to the blocking bug).

I've never dropped a piece of software as quickly as that.

More or less my experience as well. Asserting on bad user configuration, asserting on OS errors that weren't in a particular list. I followed their recommendation of having a "small, simple, reliable" broker and it kept crashing on asserts in the library at the worst times.

I don't know if the ZMQ people have ever admitted to it, but you'd be crazy to expose ZMQ to the public internet.

This is the equivalent to "trust me bro".

Do you have any specific reasons why this is a bad idea? Especially if it's been secured, as the article implies it was.

See my response to a sibling of the comment you're responding to. The library had shocking code quality issues. It's unlikely that they're all peachy now.

The other side of this is that while Pieter's writing was marketing genius, it was also woefully understating the complexity of any practical use case. The way I tried to summarize that to folks who were keen to try zeromq then was that they should start at the back of the book with the most complex example, and that's by far the simplest setup that they could hope to end up with once they start thinking about putting something into production. And everything leading up to that - a book no less - was exclusively educational/toy use cases.

I normally assume that any software which is not specifically designed to be exposed to internet, should not be exposed.

Security is hard, and proxies/VPNs are cheap.

> internal, but by design usually accessible on the public internet

Your API can be accessible obviously, but put ZeroMQ behind a firewall so only the API server can reach it.

If it’s running on the same server, at least block the port ZeroMQ is listening on from the outside world.

People make fun of Kubernetes or "resume driven development" for making things more complex than they need to be, but this is why you want mTLS via a sidecar with short auto renewed certificates on a mesh inside your distributed system of a operating stack, when the system is big enough to justify that complexity. Something the size of, like, Airbnb should have that.

Or a wireguard VPN. Or even just socat with mTLS inside systemd.

There are easier ways to achieve that than kubernetes with sidecar mesh.