ZeroMQ

Chapter 7. Advanced Architecture Using ØMQ

One of the effects of using ØMQ at a large scale is that because we can build distributed architectures so much faster than before, the limitations of our software engineering processes become more visible. Mistakes in slow motion are often harder to see (or rather, easier to rationalize away).

My experience when teaching ØMQ to groups of engineers is that it’s rarely sufficient to just explain how ØMQ works and then expect them to start building successful products. Like any technology that removes friction, ØMQ opens the door to big blunders. If ØMQ is the ACME rocket-propelled shoe of distributed software development, a lot of us are like Wile E. Coyote, slamming full speed into the proverbial desert cliff.

We saw in Chapter 6that ØMQ itself uses a formal process for changes. One reason we built this process, over some years, was to stop the repeated cliff-slamming that happened in the library itself.

Partially it’s about slowing down, and partially it’s about ensuring that when you move fast, you go—and this is essential, dear reader—in the right direction. It’s my standard interview riddle: what’s the rarest property of any software system, the absolute hardest thing to get right, the lack of which causes the slow or fast death of the vast majority of projects? The answer is not code quality, funding, performance, or even (though it’s a close answer) popularity. The answer is accuracy.

Accuracy is half the challenge, and that applies to ...