Wednesday, March 18, 2009

AMQP: Why Do I Care?

UPDATE 2009-08-18: I've been told that I signed an AMQP Reviewer Agreement, which is a different document from full licensees. I've removed the footnote as it turns out it was completely incorrect.

Aside from the fact that this blog is called "Kirk's Rants" for a reason, I get especially strident when I start talking about AMQP. So much so that in addition to a comment on one of my recent Red Hat posts, I've been asked by an online magazine (as part of an interview process) why in the world I care so much. It's simple: I care because I've been bitten in the past.

This blog's history with AMQP goes way back. In fact, it's my #2 post label (only immediately under the more generic Messaging). Let's take a trip down memory lane, shall we?

My first ever post on the subject was a lamentation. I had been having problems with the C++ client libraries for SonicMQ (an otherwise fantastic product, I must say). I grabbed the JMS client for qPid Java, and RabbitMQ, and they just didn't work together. Surely, however, that was the whole point of AMQP as an exercise? And I've been involved ever since.

I've read drafts of specifications. I've signed a Reviewer Agreement with the AMQP Working Group (though I'm not a member of it). I've met John O'Hara and Pieter Hintjens and Alexis Richardson and Carl Trieloff and gotten about as involved as you can be and not work for an MOM producer. I've gotten involved.

But why? Because it matters.

I've worked in anger with:

In addition, I've done formal evaluations on:

Every single one of them has bitten me in the ass before, usually around client libraries. For that reason, most applications are written against one broker technology, whether it's the appropriate one for all use cases in the application or not. Or, a whole firm's MOM infrastructure will be written against one broker technology, to limit all the problems that come in when applications have to support multiple client libraries, or have to select them for each application.

I view this as something that holds back MOM and keeps it in a Financial Services Ghetto. I don't view it as odd that the "Messaging Is Not Just For Investment Banks" presentation at qCon attracted more people than the AMQP presentation. Getting your head around what you can do with fully asynchronous fire-and-forget APIs is hard enough; getting your head around the fact that if you're not adhering perfectly to the JMS spec [2] you have to learn and work with completely different client APIs, half of which are broken at any given time is just too much. It's why so many people just jump into using XMPP: it may not have the best semantics, but at least it interoperates. This needs to end.

For MOM to reach completely widespread adoption, I need to tie my clients to my programming language and operating environment, not to what the provider of my broker technology is willing and capable of supporting. In order to make that a viable proposition, I need to consolidate to one protocol. Therefore, in order to get to a situation where enough engineering work is going into the client libraries to make them really really good, I need to have very few of them, namely 1.

Imagine if the web didn't have HTTP. Imagine if instead of having one protocol that would talk to everything I had to have separate client libraries for Apache, and Netscape Web Server, and IIS, and Zeus, and anything else that I wanted to support. Imagine, further, that Apache is 2% of the market. That's the situation we're in with messaging at the moment. To break out of that situation, we need the HTTP of messaging (only with less text and more binary, natch). That's AMQP.

Again, remember the Apache being 2% of the market scenario. In order for AMQP to be a success, it has to embraced by the 98% of the market using proprietary solutions, so that applications which rely on those solutions can be converted. Once those applications are converted to AMQP, users (not developers) can try different brokers and see if there are perhaps ones that suit their applications better. Once that happens, we'll have proper innovation in the MOM space. I want to live to see that day.

I've spent a lot of time with Alexis Richardson and the rest of the RabbitMQ team. Given that they're in London, I'm in London, I personally get along with them down t'pub, and I spent a fair amount of time hanging out while looking for a Cash Money Gig, this shouldn't be surprising. Furthermore, the fact that I originally discovered AMQP through Steve Vinoski discussing that Erlang is ideally suited to Message Oriented Middleware implementation and thus RabbitMQ was a really good use of Erlang means of course I'm going to be interested in hanging out with them. However, let me be very clear about something: I have never received a single pound from any provider of message oriented middleware solutions [3]. Since starting this blog ferreals I've received money from exactly two sources: Derivatives Company A, and Big Bank B.

In sum, I care about this stuff because proprietary MOM clients have bitten in me in the ass way too many times, and because fundamentally I hate closed protocols. I'm a practitioner in this space, who never (again) wants to:

  • deal with another application that can send out messages to Broker Technology A, where I'm using (or want to use) Broker Technology B;
  • be stopped from using Interesting Technology C because the Broker Technology I have to connect to doesn't support it;
  • be nearly into production with a system, only to find out that the client library has a hideous bug that I can't fix because it's a proprietary protocol.
In short, I care because I'm experienced enough in the space that I've learned to care.

Every practitioner should care so much about this type of thing. If you don't care anymore about the fundamental constraints of the space in which you develop, why are you still in the game?

Footnotes:
[1]: REMOVED (see update at top of post).
[2]: Not using Java? So sorry, there's nothing equivalent in any other language, and each vendor decides how to map JMS onto C++ in a completely different way.
[3]: Okay, I let Hans Jesperson from Solace buy me a hot chocolate. Guilty!

blog comments powered by Disqus