The most valuable feature of RabbitMQ is the ability to set up workflows simply with configuration. We had some very complex problems (logging, auditing, sequential and parallel operations) that have been easily solved by inserting a queue in the middle of an existing workflow.
Improvements to My Organization:
Our software has evolved dramatically over the past 18 months of development.
Major modifications to business logic have been handled easily. This is because each operation that the software performs has been atomic. That was then wired up with other operations via RabbitMQ exchanges/queues,
Room for Improvement:
- RabbitMQ is great, but it depends on the Erlang VM.
- I understand that Erlang is the reason why RabbitMQ is what it is. However, having to install and maintain yet another VM product has been annoying.
- The configuration for RabbitMQ borders on the esoteric. Once we got all of the moving parts working, it’s been a dream. However, it was an effort just to get it going.
Use of Solution:
We’ve been developing with RabbitMQ for about 18 months now. Our product launch is scheduled for April 1, 2017.
There were stability issues. We originally tried to mirror RabbitMQ servers behind a load balancer. (This is not completely recommended, by the way.)
That suffered from stability issues when network hiccups were a problem.
We ended up moving to a central LDAP authentication with completely disconnected servers, which has been stellar for stability.
We have had no scalability issues at all. We have RabbitMQ servers behind a load balancer, with Queue listeners attached to them.
I have estimated that we will be able to scale quite dramatically without any change to network topology.
RabbitMQ is an open-source project, so the level of tech support is relatively low. The documentation is adequate. There is a decent amount of activity on Stack Overflow and that has answered most of my questions.
I did actually use an open-source plugin and had a lot of communication with the developer. He was responsive and helped me significantly.
Our initial solution was a simple web API. We quickly realized that it would be difficult to maintain.
Scalability and reliability were my primary concerns. HTTP has no reliable delivery built-in, like AMQP does. Changing API versions would have been more difficult if we had stuck with HTTP.
The initial setup was fairly complex. Installation was not difficult, but configuration of the server itself took some work.
I ended up creating code that does the RabbitMQ setup based on a configuration file. This eased the setup dramatically. I also set up a central LDAP server for authentication, which helped. Otherwise, configuration of RabbitMQ was not very straightforward.
Cost and Licensing Advice:
Being free and open-source, I have no advice here! Free is a good price!
Other Solutions Considered:
I looked at other service bus/message queue solutions. In particular, I investigated:
- Azure’s Queue Storage: No real service bus ability without plugins
- AWS’s Simple Notification Service: Not much in the way of service bus capability. It did not allow private queues on the fly.
- A few other open-source message brokers
RabbitMQ seemed the most full-featured option for what we needed.
By all means, try to reduce the amount of up-front configuration of RabbitMQ as much as possible.
At this point, we can spin up a very generic VM with RabbitMQ on it and get it in use immediately. However, that was not the case at the beginning.
RabbitMQ is very flexible, which is good and bad. Once the flexibility is understood, it’s great. Before that, you may be in for a little bit of head-scratching.
Disclosure: I am a real user, and this review is based on my own experience and opinions.