Study Writeup: Message Queues

From Matt Morris Wiki
Jump to navigation Jump to search

This is a Study Leave topic.

What Is It?

Message Queues allow asynchronous communication between software components.

Why Study It?

It's a fundamental building block of having fine-grained services in place.

Also, it's very interesting because it's a huge source of dissent and contention: the source of this is ultimately political in nature - people recognise that if you control messaging your influence is tremendously pervasive. There is a lot of power in being entangled with the guts of how people exchange information..

Toggl code

Toggl code is WRITEUP-MQ

Deliverables

Max 3 hours of time. Need to include at the very least:

Done:

  • Protocol wars!
    • AMQP
    • ZeroMQ
    • AMQP timeline and controversy
  • Broker vs Brokerless
  • RabbitMQ
  • 0MQ
  • ActiveMQ
  • NOT ZeroC / ICE, which is RPC style and not messaging based

Writeup

Architectures

The classic messaging architecture is that all communication goes through a central broker. This provides discovery/directory services, allows sender and receiver lifetimes to be separated, and can provide robustness by storing messages in the event of application failure. However there are drawbacks: increased network communication generally and the prospect of the broker being a bottleneck.

One can split out the broker functions:

  • Directory service (can be central or distributed)
  • Distributed queues (so each link has its own subqueue)

The extreme would be a distributed directory service and having queues for each relationship (hopefully still with the ability to control and monitor these queues from a central point).

At the other extreme you could go completely "brokerless" but then you've got the prospect of chaos both on the discovery/directory and on the lifetime/robustness fronts.

At the broker-based end we have Advanced Message Queueing Protocol (AMQP), a broker-oriented protocol that is offered by a number of provider, including RabbitMQ, OpenAMQ and ActiveMQ.

At the more distributed end we have ZeroMQ. Interestingly the company that kicked AMQP off (iMatix) ended up splitting away after a lot of heated argument, to pursue the ZeroMQ philosophy.

There is clearly a lot of fuzziness around the idea of "broker vs brokerless" and it would probably be better to instead talk about breaking out broker functions as above so the precise degree of (de)centralisation can be assessed for any given option.

Protocols

The gist: if I want to go with a broker and a quick+easy start, I should try AMQP 0.9.1 via RabbitMQ. If I want something more decentralised, which may involve some effort, then ZeroMQ.

STOMP

Streaming Text Oriented Messaging Protocol (STOMP)

Text-based so relatively easy to implement, but less efficient than binary formats

AMQP

Advanced Message Queueing Protocol (AMQP)

Binary, broker oriented

ZeroMQ

ZeroMQ

Binary, decentralised (does not require a central broker)

AMQP vs ZeroMQ

A quick timeline of the two protocols:

People:

Pieter/iMatix began to become disillusioned with the course AMQP was taking in late 2006. He viewed 0.9.1 as the last valid step (he was still involved with this version), with 0.10 being a dump from an existing implementation (Apache Qpid) and 1.0 an overly complex and unworkable mess that did not represent a coherent way forward.

ZeroMQ view: [1]

  • AMQP is essentially a family of protocols (AMQP/0.8, AMQP/0.9, AMQP/0.9.1, AMQP/0.10, AMQP/1.0) which are not forwards or backwards compatible. The AMQP community is converging on AMQP/0.9.1: a clean specification but it is a deprecated protocol branch. AMQP/1.0 has no exchanges, no bindings, no queues and a fully incompatible wire level protocol. There is no backwards compatibility.
  • The ØMQ community rests on the BSD socket API, which was released with 4.2BSD in 1983. Other products like OpenPGM are now also moving to a BSD socket API. ØMQ 3.0 will simplify its API further but keep the same semantics. Future versions of ØMQ's wire level protocol will be backwards compatible.
  • AMQP is heading for conflict between its community and the workgroup. ØMQ is becoming a 'category killer'.
  • When you switch to ØMQ you will have to unlearn the AMQP patterns and learn new ones. Essentially, ØMQ gives you intelligent sockets to which you can delegate various messaging patterns. It is like having small brokers all over the network. The lack of a single "stable" point of reference may be disorienting at first.
  • Both technologies are open, fairly cheap to learn and use, and better than anything else that exists. Where they overlap, ØMQ does it better, with smarter queuing, less management costs, less complexity, and significantly better performance. A smart team would learn them both and possibly use both in parallel, i.e. applications talking to a central broker via AMQP but also to each other via ØMQ. If AMQP/0.9.1 survives its own working group, it may become an IETF standard for messaging.

Main Providers

RabbitMQ: leading AMQP implementor (along with Apache Qpid). Therefore a broker architecture, so very easy to use and deploy, because advanced scenarios like routing, load balancing or persistent message queuing are supported in just a few lines of code. Has standard broker issues: extra latency, big message envelopes. Written in Erlang. Supports other protocols too (as do others in this sphere).

ZeroMQ: very lightweight, designed for high throughput/low latency scenarios. Very flexible and supports many advanced messaging scenarios. But effort required to do anything more complicated than sending messages between 2 peers. Supports other protocols too (as do others in this sphere).

Apache ActiveMQ: in the middle ground. Like Zmq, it can be deployed with both broker and P2P topologies. Like RabbitMQ, it’s easier to implement advanced scenarios but usually at the cost of raw performance. There is a next generation version, Apollo.

All 3 products have good client API coverage, strong documentation and active support.

Apache Kafka: interesting but less uptake as yet. Offers higher throughput but (at least initially) less routing options than RabbitMQ. See here for a description: Apache frees Kafka messaging app from LinkedIn.

Apache Qpid: Also AMQP - similar space to RabbitMQ but RabbitMQ is easier to set up.

OpenAMQ: Was an APMQ offering from iMatix, who pioneered implementation of APMQ, but are now pushing ZeroMQ and decentralised messaging generally.

Views on APMQ's Future

It is hard for me to see how APMQ is going to move forward:

22 Oct 2012 "Burning Down the House: AMQP revisited", Pieter Hintjens

  • AMQP/0.9.1 is legally and technically dead. The old spec is copyrighted by the AMQP Working Group and not remixable. There are no mechanisms for extensions, patches, fixes, anything. AMQP/1.0 is touted as an upgrade for AMQP/0.9.1 when it's not. The two operate at different layers. One is a transport layer, one is a model layer. A healthy stack would swap transport layers over time and keep semantics compatible. The pain that AMQP/1.0 will cause was entirely avoidable. It was plausible to replace the 0.9.1 transport layer but keep the exchange-binding-queue semantics. Even offer a gradual migration to other semantics. The 1.0 authors just couldn't be bothered. A matter of pride and greed. The house had to go.
  • 95% of the AMQP community has invested in a dead standard. I count 4,528 repositories on GitHub that refer to AMQP. There are 244 that refer to AMQP/1.0. That makes 95% of the community wrong. This isn't marginal. There is no documented cost/benefit argumentation. The costs of change cannot simply be ignored. There must be argumentation, explanation, justification for what is so wrong with AMQP/0.9.1 that it had to be destroyed.
  • AMQP/1.0 does not define semantic interoperability. The primary requirement for AMQP (to ensure interoperability between implementations) has been dropped. It's up to each vendor how they do messaging. AMQP/1.0 is great for big vendors, tragic for users. The only value of a standard is to level the playing field so clients can choose vendors. AMQP/1.0 doesn't level the field, and is barely worth calling a 'standard'. The whole point of the AMQP/1.0 change was to screw users. I can't believe a determined five-year effort to tilt the playing field against competition was just stupidity. The goal is control over the billion dollar messaging market.

Even RabbitMQ's support for AMQP 1.0 is less than enthusiastic, as shown by this message from RabbitMQ's Simon MacMullen from January 2012:

Q: Also, why would RabbitMQ consider not supporting 1.0? Is the thinking that it may not see industry adoption, or something else?

A: [..] it's such a big difference from 0-9-1 that I view it as a different protocol really, despite the name. [..] So yes, I'd like to support it, but I'd also like to support MQTT and SQS and [..] And it may not see much industry adoption, [..] And without wanting to complain too much, it is rather heavy and complicated, so to support it properly we'd be looking at not doing quite a lot of other stuff we want to. Of course, if AMQP 1.0 takes off substantially then that could well change things.

Further Reading

Retrieved from "http://www.matthew-morris.com/wiki/index.php?title=Study_Writeup:_Message_Queues&oldid=166271"