So, you have ten minutes to explain 0MQ to a crowd of curious programmers. It's quite difficult. I'll try to give some tips.
First, don't try to explain 0MQ. You can't. You might as well try to explain crusty French bread to prehistoric hunters.
Second, don't try to say too much. Ten minutes goes by really quickly. If you have 30 minutes, you can go into some detail but really, you can say exactly one thing, explain it somewhat, repeat it again, and if you're lucky the audience will remember what you said.
Third, don't make too many slides. Personally, I don't use slides at all because they get the audience to focus on a shiny screen somewhere instead of the only thing that matters: you.
Fourth, speak slowly, clearly, loudly. This is really hard, and if you practice one thing, it's this. Slower. More clearly. Louder. You will be using strange words, and people need time to absorb what you are talking about.
Lastly, your goal should be to get people curious enough to take the next steps. You know that once they download and try 0MQ, they're probably going to love it. But we're cynical. Why should I spend that effort on downloading and trying 0MQ? Give me just one good reason!
What you cannot do is give a tutorial in ten minutes. Don't even try, it's like trying to explain bread to those cavemen by showing them how bread is made. So, you need a single clear message, something any engineer can understand, and believe. We call this a "hook".
What are the good hooks for 0MQ? It depends a lot on your audience. This is one reason to not make slides. The best hook might simply be the previous talk, where someone explains all the problems they had making a distributed system.
A good hook is simple to explain, instantly meaningful to the audience, controversial, challenging, memorable, funny. You tell the cavemen, "this magic star food smells like heaven and fills your belly, and you don't have to run to catch it". Here are some hooks I like to use when "explaining" 0MQ:
- 0MQ is the fastest way to make multithreaded apps that scale linearly to any number of cores. In detail, because it uses a lock-free message passing model similar to the Actor Model (though independently invented). You can demonstrate a minimal multithreaded server and client to prove your point.
- 0MQ is the simplest and cheapest way to build a scalable cloud. In detail, because the same 0MQ tasks will scale across cores, processes, and boxes. You can demonstrate with a two-task example over inproc, and the same over TCP. You can point out that some languages like Erlang do the same, but 0MQ works with any language, and does more than this.
- 0MQ is how we built product X (where X is some highly scalable distributed system). In detail, explain the choices you had, and why you went for 0MQ, and how it affected your project. You can demonstrate with before-and-after figures, that works much better than code examples.
- 0MQ is this magic star stuff that will let you connect thousands of pieces together, cheaply. In detail, because it's free, portable to any OS, and language, and gives you a simple scalable model for connectivity, based on the socket paradigm. The key here is cost: commodity hardware and OSes, common languages, no license fees, scale on demand.
- 0MQ is cool, look at these projects using it. The first wave of 0MQ users were mostly in the financial world and we don't know their names (or can't tell). But you can point to Mongrel2, Salt, rsyslog, dotcloud.com, and other projects. Admittedly this hook will work better when there are some really large names using 0MQ.
- Why smart cloud builders are betting everything on 0MQ. In detail, compare to the alternatives. Hand-rolling your own TCP stack is insane. Using any broker-based product won't scale. Buying licenses from IBM or TIBCO would eat up your capital. Supercomputing products like MPI aren't designed for this scale. There is literally no alternative.
- Why 0MQ is better than option Y, where Y is familiar to the audience. In detail, it's simpler, has an easier learning curve, a highly fungible API, pre-existing smart patterns, better scaling, more language bindings, better performance, and so on. It's best if you actually know product Y really well, because people will challenge your analysis. But if you know your ground this can be a powerful pitch. Show code examples using both products. That should make your case.
- Why 0MQ has so many language bindings. In detail, because 0MQ is really a community, not a library. And it's a powerful, smart, ambitious community that really knows the problem of high-performance messaging, and is determined to solve it. When you download 0MQ, you are getting the accumulated knowledge of hundreds of expert contributors. Show the same code fragment in C, Erlang, PHP, Perl.
- 0MQ is actually a box of magic pixies. In detail, imagine ultrafast servers you can embed in your app, and talk to over a simple socket-like API. These servers interconnect in magic, perfect ways, like pubsub, request-reply, pipeline. They run so fast it's insane, and they scale out over all the cores and boxes you can throw at them. We call them "sockets" but really, they're magical pixies from Mars. Approximately. This is the hardest hook but can work if your audience knows messaging already.
You can't communicate more than one hook in a presentation, that just gets confusing. Choose one that you are happiest explaining, and that you think will resonate with your audience. Then get up close, smile, and explain it, carefully and slowly, and leave time for questions.
@andyl: tl;dr: to prepare a good 10-minute talk, first make sure you have an excellent 30-second pitch. Always consider your target audience, their background knowledge, and their top concerns. Defining a narrow target audience can simplify things a great deal. Don't try to be everything to everyone. Remember: pain pills sell better than vitamin pills. Highlight the risk and pain of competitive solutions, which is easy to do.
Written: 07 Jun 2011 16:40
Revised: 09 Jun 2011 04:42
If you found this page useful, please rate it up so others will find it.
- An Introduction to ØMQ
- Coding Style Guidelines
- Guidelines for ØMQ bindings
- Installing on Windows
- libzmq Source Git Repository
- Mailing Lists
- Message API Goals
- ØMQ Contribution Policy
- ØMQ Cookbook
- ØMQ Distributions
- ØMQ Labs
- ØMQ Owners
- ØMQ Release Policies
- ØMQ/2.1 Class Diagram
- ØMQ/3.0 Roadmap
- ØMQ/3.2 Roadmap
- Process Manager
- Projects using ØMQ
- Release notes for ØMQ/4.0.0
- Reporting and Tracking an Issue
- The native ØMQ API (libzmq)
- The ØMQ Guide
- Trademark Policy
- Tuning ØMQ
- Upgrading from 2.0 to 2.1
- Upgrading from libzmq 2.x to 3.2
- Upgrading to 4.1 from 4.0
- Using Valgrind
- Welcome from AMQP
- ZeroMQ Feature List
Who's watching this page?Dominic Luciano
Fernando J Quintero
... and more