At Integrella we’re always looking to improve the way we do things. So for one of our bi-weekly tech talks we had a session for our technical team about the basics and benefits of using RabbitMQ as a messaging middleware broker.
For some background: RabbitMQ is the most widely deployed open source message broker, with more than 35,000 production deployments world-wide. It is deployed at both small start-ups and large enterprises. It is also open source, which is something Malcolm Newbury (our programme director) likes a lot because he is a paid up member of the ‘open source for business’ movement.
I explained my view that using a messaging broker is always a beneficial approach in order to connect applications to share data across the different levels of an enterprise. Using messaging, applications can connect and scale by leveraging message delivery to the message broker within RabbitMQ.
Following this approach, systems can have a common platform to send and receive messages in a reliable and asynchronous manner using customisable formats. Using a message broker is a no-brainer when the application scales, since using the load balancing facilities that can be configured within a cluster of brokers and high availability nodes will enable safe growth of the business.
This technology is an interesting one for us to look at, since a message broker will always be a safe place for all the messages to live until they are received on the target applications. A good way to understand this is to see the RabbitMQ broker in the same way as we see Royal Mail in the UK – they always deliver, regardless of the amount of letters sent, even at the busiest times of the year (that reminds me – how long until Christmas?!).
I went on to explain the generic concepts involved in messaging – the idea of channels, routing, topics and queues – before diving into detailed RabbitMQ info, including the AMQP protocol on which it is based.
Concepts like exchanges and bindings are very specific to AMPQ and RabbitMQ and we had a lively discussion around the similarities of exchanges and topics between similar technologies. The use of exchanges along with routing keys and bindings is extremely versatile in order to deliver messages to multiple targets based on a specific set of rules. This adds flexibility to the routing layer inside the broker, and eases things while setting up complex routing rules.
I wrapped up the talk with a hands-on demo of federation, showing how to loosely connect different versions of RabbitMQ servers. Federation it is a unique feature that enables the mirroring of queues and exchanges between unreliably connected servers. This feature is being used in one of our client sites successfully and it was analysed and implemented with the intention of increasing the reliability of a network while delivering messages between applications connected via a VPN with high latency and potential outages.
During the demo we also looked at the intuitive RabbitMQ management console UI and some tricks to trace queued messages and how to access the management panel to monitor queues and message flows.
I must say, I lost a few of our team members for a while at some point of the presentation, as the pizza and beer delivery arrived around the time of the demo. I guess they can’t be blamed – as much as I like this technology, the smell of fresh pizza is very distracting!