Today, we're pleased to announce that Compose RabbitMQ is generally available to all Compose users for all their messaging needs. To celebrate RabbitMQ's arrival as the sixth fully supported Compose option – following in the footsteps on MongoDB, Elasticsearch, Redis, RethinkDB and PostgreSQL – we've made this month RabbitMQ month. That means if you spin up a new deployment of RabbitMQ, in trial or on account, we'll send you a link where you can claim a limited edition, and utterly adorable, Compose RabbitMQ t-shirt.
We've taken the beta label off the messaging platform and upgraded our deployed RabbitMQ to version 3.6.5, which includes new features like "Lazy Queues". We introduced RabbitMQ in beta at the end of 2015 and during that time, Compose RabbitMQ has seen developers working on hardening the service so it's in prime condition for your messaging workloads. Existing RabbitMQ users can upgrade to Rabbit 3.6.5 too.
About RabbitMQ and Compose
For those of you unfamiliar with RabbitMQ, it isn't a database, but it does manage data. Specifically, messages between servers, services and clients. Traditionally, connected applications have evolved using a calling model where server A connects to server B, requests an operation, waits for a reply and disconnects – that's a tightly coupled connection and it can be quite brittle under load. Developers then end up writing code to handle the brittleness whilst losing flexibility.
With a message broker like RabbitMQ, server A sends a message through the broker to request an operation. That message can pass through exchanges for sorting it into the right queue. Server B connects to the broker and waits on appropriate queues for messages which it picks up, handles and responds to by posting a message back to server A. This is a loosely coupled model. In actuality, you don't even think about servers, your applications just send messages to message queues where you have other applications listening waiting to fulfil the requests.
By abstracting the connections between services and servers, the system becomes more resilient to load thanks to the decoupling, more adaptable to change. It's easy to re-configure and tune to changing or expanding workloads. For example, we use RabbitMQ inhouse at Compose to drive the fleet of cloud servers and applications which provide the Compose service. If you want to know more about how to use RabbitMQ, check out these previous Compose articles:
- Messaging, AMQP and RabbitMQ - A Speed Guide
- Getting Started with RabbitMQ
- Making Secure Connections With Compose RabbitMQ
- Configuring RabbitMQ Exchanges, Queues and Bindings: Part 1 and Part 2
- Go-ing from PostgreSQL rows to RabbitMQ messages
- Turning RethinkDB changes to RabbitMQ messages
- Deploying the Metrics Collector Microservice on Compose
The best way to get started is to spin up your own RabbitMQ deployment and start working with it. Those articles, along with the RabbitMQ documentation and tutorials and the Compose RabbitMQ help will get you up to speed and decoupling your applications in no time.
RabbitMQ and Lazy Queues
The flexibility is extended further with the latest update of RabbitMQ. Compose RabbitMQ users are now on the latest stable release and can enjoy Lazy Queues, a 3.6 feature which persists queues to disk and only loads them into memory when an application is actively consuming them. This saves precious RAM and improves performance for applications where there may be many, many queues which are only accessed occasionally.
It's an alternative persistence mode for the messaging queues of RabbitMQ which, by default, is not lazy and keeps an active cache of all messages on a queue. You don't run out of memory with lots of messages, but Rabbit and the operating system will page out unused messages and it's this paging out – and paging back in – that can hurt performance. Lazy queues eliminate that cache and the paging hit.
Of course, there's tradeoffs. For example, where transient messages are being passed without persistence, lazy queues will be make the queue use disk I/O to persist them. There, the default mode makes more sense for best performance. You can read more about how to configure and use Lazy Queues in the RabbitMQ documentation.
Getting RabbitMQ 3.6 on Compose
Existing RabbitMQ users on Compose can upgrade to 3.6.5 by selecting their RabbitMQ deployment in the Compose console, clicking on Settings in the sidebar and then clicking Change Version. New deployments of RabbitMQ – generated by signing up for a new account and selecting RabbitMQ for the first database, or by selecting Create Deployment in the Compose deployment view – will be RabbitMQ 3.6.5 (or later current version) by default.