First of all some words about RabbitMq
RabbitMq is an implementation of the Amqp specification. RabbitMq is written in Erlang. This programming language shines for situations where high availability and parallel processing are a must. One of the language designer once said: "If Java is 'write once, run anywhere' then Erlang is 'write once run forever'". Today we can see some kind of revival of the Erlang VM. Reborn in Elixir. Elixir is for Erlang what Kotlin is to Java. In my personal opinion these kind of languages are more actual than ever. We live in a world where parallel processing is more important than ever. The main reason is the upcoming of the internet with its millions of users as well as the modern processor architectures needing multi threaded software to get the boost out of them. 'Modern' languages as Java, .Net etcetera are more object orientated approaches and they really try to suite better the need for concurrency with functional approaches. The problem stays the same: They were not designed right from the start for parallel processing. They were focused on object orientated programming.
An interesting comparison between Java, Scala and Erlang can be found here.
RabbitMq implements the Amqp specification. Pivotal - the company behind RabbitMq - make some exceptions in their implementation where they think they can do better. A good example is the request-response pattern. In the Amqp specification they make use of a temporary reply-queue together with a correlation-id. As it is some kind of overhead creating every time a temporary reply-queue, Pivotal avoided this overhead by implementing the 'direct reply-to'.
RabbitMq can be downloaded and installed as a on-promise solution. If you prefer an on-demand solution there are plenty of providers offering you full managed clusters as CloudAMQP or Azure.
Moving your head into messaging
​
Let's be honest. Most of standard developers have as nearly as no clue about messaging. They are used to work with standard frameworks without knowing much about other topics as 'routing', 'exchanges' and so on. I personally believe - and I have seen it - when they are forced to dive into this subject they start thinking in messaging patterns and afterwards they can hardly imagine building a distributed system without a messaging backbone. Also they realise having re-invented the wheel dozens of times. Without need because most mechanisms are already here: In the messaging infrastructure.
​