
What is wrong with amqp? - cageface
http://www.imatix.com/articles:whats-wrong-with-amqp
======
jamwt
My answer, as someone who recently switched an AMQP backend to using redis for
queues and pub/sub broadcast: AMQP is wrong the same way RDBMSes or Java are
"wrong." It's too heavy, too slow, or too complex for a great-many use cases.

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.

~~~
foobarbazetc
If your AMQP broker is slow, you're using the wrong broker.

We do something like 1.2 million cluster durable messages per second through
RHM on Intel SSDs.

Once you add all the necessary stuff to your hacky ZeroMQ/Redis/beanstalkd
implementation, you'll end up with a poorly designed implementation of a
decent AMQP broker.

If you don't need persistance, durability or clustering, then by all means,
use whatever works for you.

~~~
aaronblohowiak
is RHM MRG?

------
cageface
The great thing about this piece is that it not only offers a very specific
critique of AMQP but also a lot of useful general advice on building complex
systems as layers of simpler systems.

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.

------
VMG
What is ampq?
[http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protoc...](http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol)

------
cmer
2 words: too complicated. Beanstalkd FTW!

------
revoltingx
I understand and partially agree that AMQP is a bit complicated. Much like XML
is a complicated version of JSON.

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.

~~~
defen
> 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.

The author of the article is the main author of AMQP/0.8 and OpenAMQ, and the
founder of the company that produces ØMQ.

~~~
revoltingx
Which surprises me given those comments.

He himself admits not to be a messaging expert.

~~~
heresy
He's being humble.

~~~
revoltingx
Well, he makes a LOT of false or illogical statements in this article.

Not something I'd expect from someone like that. 

