About me

Paolo Iannelli Picture

Paolo Iannelli

Big Daddy at Mega Labs

Amsterdam Area, Netherlands
Information Technology and Services
C, Python, Big Data, Scalability, High Availability, Performance
Expert Software Engineer with more than 12 years of experience.
Strong in critical thinking, problem solving and high performance architectures.
Paolo Iannelli Labs Rss

RabbitMQ in real world

Posted on : 19-03-2011 | By : Paolo Iannelli | In : Monitoring, Python, Software Development, System Administration

Tags: , , , , , , , , , ,


What is RabbitMQ?

Shortly, RabbitMQ is a message broker that allows you to exchange messages between heterogeneous applications.
You can find more information at http://www.rabbitmq.com.
What you do with it is just sending messages (that can be any kind of information : binary / plain-text, doesn’t matter!)  to a so-called “queue”. Any client attached to this queue will retrieve the messages.

Cool ! But why RabbitMQ and not an API ?

Well, choosing between API and messaging might be hard if you are not familiar with messaging services, but I will show you just an example where RabbitMQ is really powerful compared to a simple API.
Imagine you have 4 temperature sensors in 4 different racks. Each of these sensors are attached to a server connected to the internet. Your goal is to read the temperature of every rack and display it.
What you can do is having an API in those servers that just output the value read from the sensor. Then, from the client, you request via a REST API this value.
Alternatively you can have a centralized REST API and force each server to run a script every X seconds to update the value with a PUT request to this REST service.

REST API for temperature monitoring

So, everyone agree that the second solution would work pretty nicely. In fact, is true.
But, what if tomorrow we want to organize those “temperature servers” by location, representing for instance a datacenter in USA and one in Canada?
I have no doubt that the first thing will come in your mind is : I change the API and put a “location” field somewhere so I know from where the data comes from.
Probably the change wouldn’t take so much effort but still you have to modify an API to achieve the goal.

Comments (4)

A good article but the links to the second and subsequent pages go to a redirect loop because of the trailing ‘/’.

I managed to read the article by editing the URLs on those pages but I’m guessing most people are missing all but the first page :-)

Thanks for letting me know!
I believe this is now fixed :)


RabbitMQ does seem neat, as far as the message brokering is concerned, but what if I have to integrate disparate and maybe legacy applications. Suppose I have service consumers and producers that make SOAP calls or use JMS API, can I hook them onto RabbitMQ somehow? Or do I need to change these components to conform to AMQP now? Has RabbitMQ taken a stance that protocol translation is something best left to the ESBs?

Hi Jit,

from what I can say from my experience, most of the times when switching from SOAP to RabbitMQ, you must always have a bit of architectural changes in your applications.

In fact, you have first to analyze if your application can relay on asynchronous communication or if it strictly need to interface to other components synchronously. If the latter is the case, you may not want to go for RabbitMQ (especially on real-time or near real-time systems).
Secondarily, you have to consider that adding a new component to the architecture may lead in additional costs for operations and maintenance.

The “immediate-switching” therefore is not possible, because there must be some code (adapt application to AMQP) and architectural changes in your applications, but I must say that if you go for it on applications that you are already planning to expand heavily in the future (also in terms of scalability), the time spent for some rewrite and analysis might be really worth to speed up new features, implementations and integrations on your apps.

Write a comment