Comparison of MQTT Support by IoT Cloud Platforms

The success of MQTT can be measured by the widespread adoption by the different IoT cloud vendors. However, support for MQTT is not always equal across the cloud vendors. In fact, Microsoft states clearly on its website that:

Open standards are important to avoid vendor lock-in. If a vendor partially supports a standard like MQTT then it is one step towards vendor lock-in. For this reason, we think it is interesting to evaluate the support of MQTT by some IoT cloud vendors, including AWS IoT, HiveMQ Cloud, and MS Azure IoT.

The following is a detailed analysis based on the documentation available for each of these vendors.

• HiveMQ

• AWS IoT

• MS IoT Hub

Deviations From Specification

Basic MQTT features such as QoS 2, Retained Messages and guaranteed message ordering are often used to implement business critical systems. In order to be MQTT compliant these features are not optional but mandatory, which means cloud platforms that do not support these features are not compliant to the MQTT specification. HiveMQ provides support for MQTT 3.1, MQTT 3.1.1 and MQTT 5. In fact, HiveMQ has supported MQTT 5 since December 2018.

What does this mean for you as a user of these cloud platforms that do not support MQTT 5 features? You will miss out on critical features such as shared subscriptions, session and message expiry, topic aliases, user properties and negative acknowledgements. These features are essential for successful deployments of mission critical user cases in key industries, such as manufacturing.

AWS IoT Core announced support for MQTT 5, but they do not support shared subscriptions. Microsoft Azure IoT support for topic names and topic filters is very limited. From the Microsoft document:

It would appear all MQTT messages in Azure IoT need to be from a topic namespace of

devices/{device_id}/messages/events

This greatly reduces the flexibility of designing a topic namespace to fit the organizations' IoT use case. It also tightly ties the IoT application to Azure IoT.

Finally, it is important to consider the SDKs that can be used to connect devices to each service. HiveMQ Cloud and MS Azure allow for open-source MQTT client SDKs (ex. Eclipse Paho) to be used to connect to their service. AWS IoT only supports device connectivity using the AWS IoT SDK. MS also has the MS IoT SDK to connect to the MS Azure IoT Hub. Restricting device connectivity to the cloud services via a proprietary vendor SDK limits the options for changing the MQTT cloud service at a later date.

Deviations From MQTT Specification

^[1] AWS IoT QoS is defined as delivered zero or more times. MQTT 3.1.1 spec defines QoS 0 as at most once delivery.

^[2] When a client subscribes to a topic, there might be a delay between the time the message broker sends a SUBACK and the time the client starts receiving new matching messages.

^[3] Topic need to follow specific format of 'devices/{device_id}/messages/events'

^[4] Microsoft has a very restrictive way that you can use a MQTT library.

Limitations of MQTT Support

AWS IoT and MS Azure IoT impose a number of limitations on their MQTT broker that restrict the potential use cases for their services.

Both AWS and MS make it impossible to create an MQTT client back-end consumer service that could subscribe to all the messages in the system so they can be stored in a database or another enterprise system. AWS limits each client to 100 publish events per second and throughput of 512kb/second/connection. MS limits the publishing rate to 120 events/sec/unit and throughput is limited to 300MB per device stream. A scalable back-end MQTT client consumer service would require much higher rate limits. In addition, the lack of MQTT 5 Shared Subscriptions makes it even more difficult to implement. The integration with other backend services must be done using the AWS or MS proprietary event handle services, which locks companies into proprietary cloud functionality.

AWS IoT restricts the QoS 1 retry interval to 1 hour meaning if a device was offline for more than an hour, the message would not be received. For many enterprise IoT use cases, like connected cars that can go offline for extended periods of time, it is unacceptable to lose messages after a period of time. This limitation effectively makes QoS 1 support in AWS IoT non-functional.

AWS and MS limits the size of the MQTT message. AWS limits messages size to 128kb and MS limits messages size device to cloud at 256kb and cloud to device at 64kb. The MQTT specification specifies the MQTT message size limit to be 256MB. HiveMQ supports the MQTT specification of 256MB.

MQTT Limitations

Ref: AWS Limitations, MS Azure IoT

Conclusion

MQTT is a widely used and accepted ISO IoT standard. Standardization of functionality across vendors is one of the key success factors for MQTT, as this protects customers from vendor lock-in of their IoT devices, which are very often part of a company’s value chain. Unfortunately, not all MQTT cloud services have implemented the entire specification and are not MQTT compliant since they lack mandatory features that are required to implement the MQTT 3.1.1 standard. These deviations from the MQTT standard often lead to using the vendor’s proprietary IoT SDKs to send the MQTT message. The use of proprietary SDKs promote vendor lock-in and makes it difficult to switch MQTT cloud services at a later point in time. Open standards are important to avoid vendor lock-in but incomplete implementations of open standards might lead to vendor lock-in.

Cavest emptor - Buyer beware