What is wrong with amqp?

There's a long tradition that seems to be (mercifully) fading of ornately engineered solutions being developed for the most demanding of problem domains, and then subsequently being universally adopted for projects large and small because if "it's good enough for the enterprise, it's good enough for me". It's a variation of the "nobody ever got fired..." mentality.

The truth is that something with a radically reduced feature set, that's simpler to use and understand, is really all that's needed to meet a whole lot of "real world" use cases.

Read the AMQP-0.8 spec sometime. It's rather complex given that a _huge_ percentage of users just want a set of features something like:

1. A namespace to name queues 2. The ability to put things on and pull things off in FIFO order 3. The ability to persist those things on daemon start/stop (maybe) 4. Pub/sub style broadcast behavior with lossy messaging (maybe)

So redis, as an example: antirez (half-accidentally) got a lot of attention from weary queueing-system wanderers by implementing a majority of these capabilities with just a few redis commands--(l,r)push and (l,r)pop. Redis was so close to a simple, but full replacement for what they actually do with ActiveMQ, Rabbit, etc, that they begged for B(L,R)POP on many keys and PUB/SUB. And that pretty much covers it.

Of course, redis is just one of a number of other project/protocols are stealing attention from AMQP systems, like ZeroMQ, beanstalkd, etc.

But the larger trend is like Linux::"UNIX", Ruby::Java, MongoDB::Postgres, etc. Despite the hell-and-damnation warnings often bandied about by the enterprisey experts, you really can build a wide array of very useful things using these "toy" tools.

In a sense it's Worse is Better all over again (http://en.wikipedia.org/wiki/Worse_is_better), which is a lesson we seem to keep re-learning in the software industry.

However, I can personally vouch that this 'complexity' once somewhat mastered can be used to create messaging schemes in no time. What's so complex about it? You have exchanges, queues, and bindings. With a bit of practice, it's fairly simple to grasp the concepts.

"AMQP is quite unusual in that it starts low on the stack, building on protocols like TCP rather than HTTP"

This person has obviously never built anything truly high performance. Using HTTP would add a lot of latency, and he complains about message speed? Sure 0MQ is the fastest, but with RabbitMQ you get <1ms latency.

"People who today read the AMQP specifications tend to make one main complaint: the protocol is too complex."

I wonder how many of these people actually use it. He goes into a bunch of useless analogies but doesn't actually discuss WHAT'S complex about it. (Usage wise, NOT implementation wise.)

A protocol doesn't HAVE to evolve. JSON being an example. But, in the end, AMQP isn't perfect, but it can still be used to build good software.

This person knows very little about building messaging software, and he admits it himself. I'd take his complaints with a huge grain of salt.

You can use something like protobuf to get really fast de-serialization if you really want encoding.