Consider a temperature sensor in your greenhouse, which is measuring the temperature. Your app could send the temperature to a message queue in a 15-minute interval (about 96 times a day), instead of processing the data in the greenhouse and be connected all the time.
Message queues for IoT are designed to provide a lightweight publish/subscribe messaging transport. Instead of keeping an application that is processing the data in your greenhouse, you simply send the data and handle the data in another service. This require less network bandwidth which might be limited for your sensor, or if your sensor communicates via satellite link.
A message queue enables your application to have a low power usage, send minimized data packets, and efficiently distribute information to one or many receivers.
Message queuing in IoT projects
Message queuing is a style of service-to-service communication. It allows applications to communicate by sending messages to each other. The basic architecture of a message queue is simple, there are client applications that create messages and deliver them to the message queue. An other application/service retrieves the message from the queue and processes the requests and information contained in the message.
A message can include any kind of information. It could, for example, have information about a process/task that should start on another application (that could be on located on an other place), or it could be just data that needs to be processed.
IoT and Asynchronous Messaging
Internet of Thing applications being reactive and asynchronous is a "must". Most IoT application should be able to handle many connections from devices and all the messages ingested from them.
Asynchronous messaging is widely used when it comes to machine to machine communication. It means that the sender does not expect an immediate response and that the sender not "block" anything while waiting for the response.
Asynchronous communication enables flexibility: An application can send a message out and after that, just keep working on other things - while in synchronised communication it has to wait for a response in real time. Instead of calling a web service and waiting for it to complete, you can write the message to a queue and let the same business logic happen later.
Queues can be great in scenarios where your application needs something done but doesn’t need it done right now, or doesn’t even care about the result.
Decoupling
Message queues can be used to achieve decoupling and it helps keeping the architecture flexible. It makes it very easy to connect two totally different applications written in different languages together.
Message queues allow each component to perform its tasks independently - it allows components to remain completely autonomous and unaware of each other. A change in one service shouldn't requires a change in the other services. It is the process of separating services so that their functionality is more self-contained.
Redundancy and Resiliency
Application crashes sometimes - it happens. It could be due to timeouts or that you simply have errors in your code that affect the whole application. A message queue force may the receiving application to confirm that it has completed the task and that it is safe to remove the task from the queue. The message will just stay in the queue if anything fails in the receiving application.
A message queue provides a temporary message storage when the destination program is busy or not connected.
By breaking your app up and separating different components by queues, you inherently create more resiliency. Your application can still be operational even if part of the backend processing is delayed.
Traffic spikes
Many applications have spikes in traffic. A doorbell app, that enables you to answer your door from anywhere, might have traffic spikes during Halloween, while a shopping app might have traffic spikes on Black Friday. By queuing data, you can be sure that your data will be persisted and processed eventually; even if that means it takes a little longer than usual due to a high traffic spike.
Message queueing for IoT with RabbitMQ
There are some IoT communication protocols and standards designed to simplify IoT designs. If you consider a queue-based solution, CloudAMQP offers hosting of the two most popular open messaging protocols; AMQP and MQTT via RabbitMQ.
AMQP is a secure and reliable protocol, with low overhead, making it perfect for Internet of Things applications. AMQP a more advanced protocol than MQTT, more reliable and have better support for security. AMQP do also have features like flexible routing, and durable and persistent queues, clustering, federation and high availability queues. The downside is that it's a more verbose protocol on the wire - depending on how you implement your solution.
MQTT is another protocol designed for IoT. MQTT advertised benefits for IoT only matter for extremely low power devices. MQTT is very wire-efficient, it has a strong focus on minimal wire footprint. It requires less effort to implement MQTT on a client than AMQP - because of its simplicity. However, MQTT lacks authorisation and error notifications from server to clients, significant limitations.
RabbitMQ is a message-queueing software called a message broker or queue manager. Simply said; It is a software where queues can be defined, applications may connect to the queue and transfer a message onto it. You can read more about CloudAMQP here.
