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.
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.
Don't throw out ActiveMQ if you want a lightweight solution -- just use it's STOMP support. STOMP is great, it is "enterprise compliant", but lightweight and very easy to understand. I am also a fan of redis and its pub/sub features, but using STOMP on ActiveMQ will let the complexity of your messaging infrastructure grow along with your needs. Evetually need persistence? flip a switch. Need a CBR or other ESB features? Start turning them on.
seconded.
I think every messaging broker needs to support the STOMP protocol now. It is cross-language and a whole lot of products are being built around the protocol, including some that wean you away from JMS (e.g.HornetQ, previously known as JBoss Messaging Server)
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.
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.
It would not be much of a surprise if you had watched this unfold over the past couple of years. The 0MQ guys lost the AMQP fight and apparently decided that they would instead pivot to fast & lightweight, but non-durable, queues (and whine to anyone who would listen about how AMQP sucks now that they are no longer a part of the effort.) These ephemeral queues have gained a lot of attention recently for simple pubsub, job queues, and other misc tasks in the application stack. Unfortunately they pivoted right into the redis steamroller. Sucks to be them, but as the saying goes: "karma's a bitch..."
AMQP's scope is too large. STOMP or 0mq give most of what's good without all the bloat, and you can handle brokering, exchanging, transformation &etc with your applications resident on the bus.
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.