What the world looked like in May 2014
RabbitMQ 3.3 was one month old. Erlang/OTP 17 had been out for a few weeks. Docker 1.0 was still a month away, and nobody had heard of Kubernetes.
That’s when this cluster started moving messages. It hasn’t stopped since.
It isn’t alone. A handful of the dedicated clusters created on CloudAMQP in 2014 are still running today. We don’t know exactly what they do, and we won’t tell you who owns them. But we know what they’ve lived through because we were there for it all.
Nothing under them is from 2014
The clusters are 12 years old, but nothing they run on is. The VMs, the disks, and the operating systems have all been replaced, some of them more than once. When they started, RabbitMQ 3.3 was the newest version and Erlang/OTP 17 was brand new. Today they run RabbitMQ 3.13 on Erlang 26.
What stayed the same is everything the customer sees: the cluster, its name, its connection URL, its users, queues, and exchanges. Their apps have been publishing to the same place for 12 years, while everything underneath has been swapped out.
That’s the job. Not keeping the same server alive forever, but making sure nobody has to care which server it is.
Who’s been looking after them?
We started CloudAMQP in 2012, because running RabbitMQ was harder than it should be. Two years later, these clusters showed up. We’ve been looking after them ever since.
That means every RabbitMQ and Erlang upgrade, every security patch, and every server swap, done so the apps on top never had to notice. Our team is spread across time zones on purpose, so someone is always awake. Most nights, nothing happens. For a 12-year-old cluster, that’s thousands of quiet nights in a row.
12 years, one year at a time
From RabbitMQ 3.3 to 4.4, here’s everything they’ve lived through.
Pick a year, or let it play.
-
2014, Newest RabbitMQ: 3.4
RabbitMQ 3.3 and Erlang/OTP 17 are new. On May 6, the oldest dedicated cluster still running on CloudAMQP is created.
-
2015, Newest RabbitMQ: 3.6
RabbitMQ 3.5 in March, 3.6 in December. Erlang/OTP 18 arrives in June. Mirrored queues are how you make RabbitMQ highly available.
-
2016, Newest RabbitMQ: 3.6
We let customers pick their own RabbitMQ version and automate Erlang and RabbitMQ upgrades across a whole cluster. No more upgrading node by node.
-
2017, Newest RabbitMQ: 3.7
RabbitMQ 3.7 ships in November, almost 2 years after 3.6.
-
2018, Newest RabbitMQ: 3.7
In January, Spectre and Meltdown show that almost every modern processor can be tricked into leaking data between programs. Our clusters weren't exploitable, but some of the clouds under them had to restart their host machines.
-
2019, Newest RabbitMQ: 3.8
RabbitMQ 3.8 brings quorum queues, built on Raft, and feature flags. Quorum queues are built to replace mirrored queues.
-
2020, Newest RabbitMQ: 3.8
The world goes remote, and message traffic doesn't care. Erlang/OTP 23 in May. We start telling everyone the reasons to switch to quorum queues.
-
2021, Newest RabbitMQ: 3.9
RabbitMQ 3.9 adds streams. In August, the RabbitMQ team announces that classic queue mirroring will be removed in 4.0. In December, Log4Shell. RabbitMQ runs on Erlang, not the JVM, and isn't affected.
-
2022, Newest RabbitMQ: 3.11
RabbitMQ 3.10 in May, 3.11 with super streams in September. We write the guide to moving from mirrored queues to quorum queues.
-
2023, Newest RabbitMQ: 3.12
RabbitMQ 3.12 in June. Lazy mode stops mattering: every classic queue now moves messages to disk early to save memory.
-
2024, Newest RabbitMQ: 4.0
RabbitMQ 3.13 in February, with MQTT 5 and Khepri as an opt-in. Then 4.0 in September: classic queue mirroring is gone, and AMQP 1.0 becomes a core protocol, next to AMQP 0.9.1.
-
2025, Newest RabbitMQ: 4.2
RabbitMQ 4.1 in April. 4.2 in October makes Khepri the default metadata store for new clusters.
-
2026, Newest RabbitMQ: 4.4
RabbitMQ 4.3 in April removes Mnesia for good. On May 6, our oldest cluster turns 12. RabbitMQ 4.4 follows in October.
Why so many clusters are still on RabbitMQ 3.13
All of the 2014 clusters run RabbitMQ 3.13 today. They’re not alone there either. About half of the dedicated RabbitMQ clusters we run are on 3.13.
There’s a reason for that. 3.13 is the last version with classic queue mirroring. RabbitMQ 4.0 removed it, so the jump to 4.x isn’t just a version bump. If you use mirrored queues, you need to move to quorum queues first. That means changing how your queues are declared, not pressing a button in a console.
Upgrading RabbitMQ is usually the boring part. We do it all the time, and we wrote about how it works. This one asks a little more of you. If you’re still on 3.13, our guide to moving from classic mirrored queues to quorum queues is a good place to start.
If you’re changing things anyway, you can also move to LavinMQ. It speaks AMQP 0.9.1 too, so your queue declarations can stay as they are, and the migration feature in the CloudAMQP console moves your setup and messages over for you.
Boring is the feature
A few weeks ago I wrote that nobody talks about message queues, and that’s the point. This cluster is the proof.
For 12 years, it has done the same thing every day. Through RabbitMQ 3.3 to 3.13, a stack of Erlang releases, a pandemic, Spectre, Meltdown and Log4Shell, new servers, and new operating systems. Nobody wrote a post-mortem about it. Nobody gave a conference talk about it. Someone set it up in 2014 and then moved on with their life.
Since 2013, developers have created over a million free Little Lemur instances on CloudAMQP, more than 70,000 of them in the last 12 months. Many come and go. We know we have been a great learning resource. A few grow into something a business runs on for a decade.
So happy 12th birthday, whoever you are. We hope nobody notices the next 12 either.