RabbitMQ, my alternative for Service Bus for Windows Server

I thought of writing a nice article for Easter. So what’s more appropriate than writing about RabbitMQ? Not a bunny, but it has big ears. Close enough.

A couple of months ago Microsoft announced it would no longer support the on-prem version of it’s popular Azure Service Bus Messaging, also known as Service Bus for Windows Server. Why? Because apparently everyone is moving to the cloud and hybrid is the future. This is true, a lot of companies are moving to the cloud, but since they are keeping stuff on-prem, there is also some integration going on there. We need tools on-prem as well and can’t rely on a cloud-only solution here.

Luckily I was already a couple of months in with a project and actually advised to use RabbitMQ for our on-prem solution. Compared to Microsoft’s on-prem solution there are just a couple of advantages you can’t ignore. And now, that support for Service Bus for Windows Server stops, I am really glad we took the decision to use RabbitMQ over Microsoft’s solution.

Why RabbitMQ?

So let me sum up why we chose RabbitMQ and why it will be my go-to choice for the future.

• It’s AMQP, just like Service Bus Messaging.
• It’s widely accepted, it’s probably the most used queuing solution on-prem at the moment.
• It’s mature, it is currently celebrating it’s 10th anniversary.
• It’s stand-alone and doesn’t use SQL server (or any other commercial database). An advantage, why should I also have to pay for SQL Server for something like queuing?
• High availability only requires 2 machines, whereas Service Bus for Windows Server requires at least 3 machines in its farm.
• It’s cross-platform: Windows, Linux (multiple distributions) and Mac.
• It supports all popular programming platforms and languages. This is really neat. No more Mono stuff needed, just use Java or PHP.
  • This is the list of languages that are supported.
    • Python
    • Java
    • Ruby
    • PHP
    • C#
    • JavaScript
    • Go
    • Elixir
    • Objective-C
    • Swift
• It has a built-in management portal to manage about everything. A really big pro if you ask me. Microsoft only offers a proprietary Windows-forms program (built by somebody at Microsoft who wanted more control over service bus). There are still a few things you’ll need to manage through the Command Line, Powershell, or Bash, but I don’t want to be out of a job soon. So that’s fine for me.
• It has built-in stats for your exchanges, queues. E.g. memory usage and disk usage on queue level. You can even see who is listening and connected at the moment.
• And last but not least, the comprehensive documentation!
• Ow… and MSMQ is not an alternative, go wash your mouth.

Are there downsides? Of course. But I could only think of two…

• There’s no adapter in BizTalk (so we programmed a WCF binding in a few days time probably).
• You’ll need to get used to the “Rabbit-way-of-working”, but you are never too old to learn.

Support and Cloud

Although RabbitMQ is open source, there are several ways to get support. Pivotal is probably the best-known of them all.

You can also run RabbitMQ in up there, in the cloud if you’d like to. Rabbit specific there is CloudAMQP, but you can also choose the big vendors, Microsoft Azure, Google Cloud Platform or AWS.

What are the differences with Service Bus Messaging?

In the end it comes down to getting used to terminology and the implementation of the protocol. It’s not really that different. Where Microsoft keeps it simple and gives you a choice between queues and topics, the approach in RabbitMQ is a little bit different.

RabbitMQ works with exchanges. Every message you send to RabbitMQ, is sent to an exchange. The type of the exchange determines how routing works. There are four types:

• headers
• fanout
• topics
• direct

I will go over them here shortly and follow up with a series of articles.

Headers

The Headers exchange type routes messages based upon message headers to the correct queue.

Fanout

Fanout is straightforward and sends all the messages it receives to all bound queues.

Topics

The routing key for a topic is sent with dots in between and (regex) patterns are used to match the subscriptions. The messages will only be sent to the queues which match the patterns in the bindings.

Direct

Direct exchanges will send messages to the queues configured in the binding to match the exact same key.

Linux

And in the process of all this, RabbitMQ also got me back on board with Linux – Ubuntu in my case. Well, this and .Net Core 🙂 Although there is an alternative to run RabbitMQ on a Windows Server machine, there’s something with open source and getting it to work on Linux. There are many advantages of not deploying a full-fledged Windows machine for something like RabbitMQ.

I hadn’t touched Linux for at least 10 years (internally, my websites all run on Linux) and had to get back into it. After a couple of hours I was getting the hang of it again though. And, like I said earlier, you are never too old to learn. Just give it a try.

It will take a few hours (and days, or weeks) of messing around, but I am pretty sure we will need it in the long run. More and more things are happening in the open source space. Even .Net is open sourcing and running on Linux. One day there won’t be an excuse anymore to deploy (expensive) Windows machines for small solutions like RabbitMQ and this knowledge will come in handy!

Download RabbitMQ yourself

No. This isn’t a sponsored article. I just really like RabbitMQ. The ultra-fast setup, the multi-platform support, the multi-languages support, the out-of-the-box management portal, and the comprehensive guides they offer online. It’s just so easy to get going and I would always recommend it for on-prem queuing mechanisms.

Give it a try and download RabbitMQ. If you are a Windows guy, just download the Windows installer and install it. If you are a Ubuntu guy, add the apt-get library and install it from there. Yes… it’s that simple.

https://www.rabbitmq.com