TL;DR​

• Erlang 24 will ship in May and it offers significant performance gains to RabbitMQ users
• Supporting Erlang 24 and 22 at the same time is not feasible, so in early May 2021, Erlang 22 support will be dropped
• If you run on Erlang 22, upgrade to 23.2 today: it should be a drop-in replacement
• Users of the RabbitMQ Kubernetes Operator, the Docker community image and modern releases of VMware Tanzu RabbitMQ for VMs are not affected as those projects all use Erlang 23 today

We have been constantly improving the monitoring capabilities that are built into RabbitMQ since shipping native Prometheus support in 3.8.0. Monitoring the broker and its clients is critically important for detecting issues before they affect the rest of the environment and, eventually, the end users.

RabbitMQ 3.8.10 exposes client authentication attempts metrics via both the Prometheus endpoint and the HTTP API.

We are pleased to announce that the RabbitMQ Operator for Kubernetes is now generally available. The RabbitMQ Operator makes it easy to provision and manage RabbitMQ clusters consistently on any certified Kubernetes distribution. Operators inform the Kubernetes container orchestration system how to provision and control specific applications. The Kubernetes (hereafter K8s) Operator pattern is a way to extend the K8s API and state management to include the provisioning and management of custom resources -- resources not provided in a default K8s deployment. In this post, we’ll discuss how the Operator enables the K8s system to control a RabbitMQ cluster.

This month in RabbitMQ features a blog from Michael Klishin on deploying RabbitMQ on Kubernetes. Also this month: RabbitMQ consumers on AWS, a three-part series on developing microservices with Lumen and RabbitMQ, and several articles on RabbitMQ and ASP.NET Core.

It’s not the holidays yet, but the RabbitMQ community has presents for you anyway! The RabbitMQ Kubernetes cluster operator is now open-sourced and developed in the open in GitHub. Also, Gavin Roy has a new Python app that migrates queues between types. Finally, a webinar on RabbitMQ consumers from Ayanda Dube, Head of RabbitMQ Engineering at Erlang Solutions.

Over time, we have seen the number of Kubernetes-related queries on our community mailing list and Slack channels soar.

In 2024, the answer to most Kubernetes-related question is: use the Kubernetes Operator built by the RabbitMQ Core Team. It incorporates all the best practices and is the strongly recommended option.

This post explains the basics of a DIY deployment of RabbitMQ on Kubernetes: what Kubernetes resources will be necessary, how to make sure RabbitMQ nodes use durable storage, how to approach configuration of sensitive values, and so on.

This month in RabbitMQ features the release of the RabbitMQ Cluster Kubernetes Operator, benchmarks and cluster sizing case studies by Jack Vanlightly (@vanlightly), and a write up of RabbitMQ cluster migration by Tobias Schoknecht (@tobischo), plus lots of other tutorials by our vibrant community!

In this post I am going to cover perhaps the most commonly asked question I have received regarding RabbitMQ in the enterprise.

How can I make RabbitMQ highly available and what architectures/practices are recommended for disaster recovery?

RabbitMQ offers features to support high availability and disaster recovery but before we dive straight in I’d like to prepare the ground a little. First I want to go over Business Continuity Planning and frame our requirements in those terms. From there we need to set some expectations about what is possible. There are fundamental laws such as the speed of light and the CAP theorem which both have serious impacts on what kind of DR/HA solution we decide to go with.

Finally we’ll look at the RabbitMQ features available to us and their pros/cons.

This month, Jack Vanlightly continues his blog series on Quorum Queues in RabbitMQ. Also, be sure to watch the replay of his related webinar.

Finally, Episode 5 of TGI RabbitMQ is out -- Gerhard Lazu walks us through how to run RabbitMQ on Kubernetes. Don’t miss!

The team was recently asked about whether and how quorum queues can offer the same message ordering guarantees as classic queues given that they will deliver messages from a local queue replica (leader or follower) when possible. Mirrored queues always deliver from the master (the leader), so delivering from any queue replica sounds like it could impact those guarantees. 

That is the subject of this post. Be warned, this post is a technical deep dive for the curious and the distributed systems enthusiast. We’ll take a look at how quorum queues can deliver messages from any queue replica, leader or follower, without additional coordination (extra to Raft) but maintaining message ordering guarantees.