We launched the London ZeroMQ User Group (ZeroMQLondon) on Wednesday, the 5th of December, 2012. We were extremely lucky to have one of the founders of 0mq, Pieter Hintjens, in town for TechMeshConf 2012 – and to agree to do a talk to launch the group. This was our first meetup, and it got a bit hectic towards the start… Hopefully we’ll do better in future ones. We are extremely grateful to Skillsmatter for providing us with a large enough place to hold the 50+ people that came (and with Udi speaking downstairs and “hogging” a large part of the London .NET community, that’s quite a turnout!). Whatever we lacked in terms of organisation before the talk was hopefully more than made up by Pieter’s excellent talk.
I realised Pieter is a far better speaker than he is a writer. And considering how excellent his writing is, you can only imagine how great the talk was. Well, you don’t have to imagine at all – the awesome folks at Skillsmatter already have the video up and running at http://skillsmatter.com/podcast/design-architecture/launching-london-omq-with-pieter-hintjens
I went into the talk with some expectations – I thought it’d be mostly about complex architecture, technical deep dive into Zero, the raw nitty gritty, filled with numbers and wizardry. I don’t know why I expected that, but I did. And it didn’t turn out that way - it was much better. It started off with questions form the audience about 0mq – and looking back, that is a reflection of how the 0mq community works. But more on that later. After the initial questions, came more questions – and the talk was driven by the questions. That went on for some time. Topics ranged from why, where, and how, to basic patterns, scalability and what not. However, roughly half of the talk was not about 0mq or anything technical at all – it was about the challenges the 0mq community had faced and how they resolved them, it was about how git patches are handled for the source code, it was how they recovered from a brief but painful period of breaking API changes, it was about how the single most important thing to Pieter in regards to Zero is the contributors and the community. Funnily enough, I found those bits to be more engrossing – astonishing even.
If you attended the meetup, please take a minute to leave feedback at the meetup group:
Also, please please fill the the following survey: http://www.surveymonkey.com/s/WTYR577 – it’s anonymous and only six questions on one page.
We will hopefully make this a regular thing – maybe even monthly. Seeing next month’s January, we may hold the next one in February (unless a lot of you want one in January).
A few key things (of many) that are worth putting forward:
- ZeroMQ doesn’t try to solve all problems for everybody in one package. It is a simple (API wise) thing that lets you build the exact thing you need very easily and quickly. Those things would be built on top of Zero. In practice, this is very easy since what you build will be focused at solving a single problem – YOUR problem. This all reeks heavily of many good principles that are well known in Kanban, and to a certain Space Agency who say things like “Do one thing at a time, with supreme excellence”.
- ZeroMQ isn’t just sockets. It just uses the name “Socket” for some things. It is a whole lot more and it is a LOT easier to code with. You mix and match various types of sockets to meet your use case.
- Zero doesn’t do out of the box durable messaging (though there is an element of buffered messaging). While that might sound scary to people used to durable message queues, it should not be. As an example, if your consumer goes down, connectivity is lost or any other weird stuff happening will cause messages to build up on the sender’s side. After a finite amount of space is exhausted, what will the sender do? Drop messages? Stop receiving orders? You have to cater for that scenario in your application / infrastructure code anyway. You have to deal with idempotency anyway.
- Scalability comes from certain patterns and integrating them. A lot of the patterns in the Zero Guide are for specific scenarios. In most cases, they aren’t necessary. They’re there coz somebody asked the question. The basic patterns go a long way. Router-Dealer is the most important pattern to learn.
- It is very easy to design systems with 0mq where you can elastically add and remove servers and clients.
- In many cases, simply replacing a durable queue with 0mq will be nowhere near as successful and simplifying the architecture, getting rid of cruft and using 0mq.
- 0mq can be used to build VERY VERY large systems – by building smaller systems that communicate with each other.
- It can be used from many languages through language bindings and will work exactly the same way.
Community / Process
- 0mq has no roadmap! Roadmaps make promises that aren’t kept.
- Anybody can patch main. There is no maintainer team that gates them. Everything is accepted. Usually contributors take it unto themselves to ensure they try their best to not introduce problems – it becomes a permanent footprint after all. If a problem is found, another person simply makes another patch to compensate. This might sound risky, but in practice it seems to work really good. A lot of small incremental changes are easier to deal with too.
- Early adopters pick a commit off master that’s at or near the head. Usually it’s good enough. If not, they fix it or checkout the previous commit or the one(s) before that. That rarely causes issues.
- For the mainstream, there are stable and rc tagged releases.
- After 2.x, versions 3.0 and 3.1 introduced API changes that broke back compat. 3.2 has undid that messed. Going forward, there is a promise that the API will not be broken and any new things will maintain back compat.
- You guys should really really be using v3.2+. For those on 2.x, don’t worry. The crazy days of 3.0 and 3.1 are over.
- Uses C4 process for contributions: http://rfc.zeromq.org/spec:16
- Upfront discussion is an excuse not to get involved.
- Making perfect code puts off contributors.
- Feature requests put people off. [Although paid feature request are a different thing…]
- A large test suite means something is complex with many edge cases. ZeroMq ahs a test suite that is just enough.
- If there's a problem, somebody will find it and take care of it.
- Over time, if you don't use zeromq, your software will become irrelevant.
- I prefer many contributors with few patches each over few contributors with many patches.