At MarsBased, we have worked on IoT applications for some of our most important clients, like SPIN or WorldSensing. We have used various message brokers, such as Kafka, RabbitMQ, or AWS IoT.

In our last IoT project for Ecler, we designed their entire cloud platform and the various systems that will support their connected amplifiers and sound systems, starting in 2024.

Part of the work we did was to choose the best IoT message broker solution for them.

MQTT

While our previous experience has been more focused on Kafka and RabbitMQ, when designing Ecler's IoT solution, we believed that we could benefit from the features offered by MQTT. MQTT has become the standard communication protocol for IoT devices, with most of the embedded programming frameworks supporting it.

When working with the MQTT protocol, there are many compatible message brokers available. We tested three platforms during the development phase of our project. Here are the pros and cons we found for each one of them.

Mosquitto

Mosquitto is one of the most well-known message brokers implementing the MQTT protocol. The first prototype that we built for the Ecler platform used Mosquitto under the hood.

It is easy to configure, and you can find tons of documentation and examples to help you get the software up and running in no time. For us, using well-documented software is essential when choosing a technology. Its Docker official image is easy to use both in development and production.

Our main concern with Mosquitto was scalability. It is built in C, which makes it lightweight and provides excellent raw performance. However, its architecture does not support multiple threads. Additionally, clustering is not natively supported. We have extensive experience working with single-threaded languages such as Ruby, Python, and Node.js, and we understand the risks of running single-threaded software without cluster support at scale.

Also, we find its file-based configuration to be troublesome. It is not elegant to manage in our Docker-based cloud deployments, where we prefer to manage credentials and environment-wise configurations through secret managers and environmental variables.

Mosquitto might be a good solution for many small-to-medium IoT projects, but it was not the solution we needed.

NanoMQ

As part of our research for better alternatives, we discovered an interesting performance comparison between NanoMQ and Mosquitto.

NanoMQ, immediately caught our attention due to its lightweight nature, the clustering native support and the ability to configure everything through environment variables.

We sincerely attempted to embrace NanoMQ, but our enthusiasm was short-lived. The software shows promise; however, it is not yet mature enough to meet our requirements. The documentation lacks comprehensiveness, occasionally contains outdated information, and at times references features that the current code does not support.

The final reason for discarding this alternative was the limitations that we found in the supported authentication and authorization features. However, I am sure that we'll continue to watch the project, as I am convinced it will evolve positively in the following years.

EMQX

From the beginning, we tried to avoid EMQX. It has a reputation for being scalable, powerful, and distributed, but difficult to configure and set up. I prefer simple solutions with low maintenance costs whenever possible.

Like the other brokers we tested, it has an easy-to-use Docker image, so we gave it a try in development and staging. The configuration was more straightforward than we had imagined. They use HOCON, a configuration file format, but they allow every configuration to be replaced by environment variables, including object and array settings.

We found the cluster configuration easy to set up, maybe because at MarsBased, we are already used to configuring PostgreSQL or Elasticsearch clusters, and the default configuration values provided are good enough for most needs. When something was not properly configured, the logs were descriptive and helpful, which is something that surprised us positevely.

It is true that the baseline resources required for EMQX to work are higher than Mosquitto and NanoMQ, but this is not really a problem in our current infrastructure.

There is much more to say about EMQX, such as the good documentation, the built-in dashboard or the authentication and authorization possibilities that it provides. In a future post, I'll explain how we used EMQX to create a rock-solid authentication mechanism without having to issue and keep a list of certificates per IoT device.

Until then, don't hesitate to ping me on X on any questions you might have!