{{announcement.body}}
{{announcement.title}}

Why MQTT Has Become the De-Facto IoT Standard

DZone 's Guide to

Why MQTT Has Become the De-Facto IoT Standard

Learn more on why MQTT has become the de-facto standard for IoT communication

· IoT Zone ·
Free Resource

Happy birthday, MQTT!

This week, Andy Standford-Clark announced in a tweet the 20th anniversary of the first MQTT release. In those 20 years, it is clear that MQTT has become the de-facto standard for IoT. All major IoT cloud providers support MQTT, many popular IoT Platform vendors support MQTT, and survey results show MQTT is widely used for building IoT applications.

Happy birthday, MQTT tweet

An interesting question to ask is “Why has MQTT has been successful?” What were the factors that led to the MQTT domination of IoT?

You may also like: [DZone Refcard] Getting Started With MQTT

My journey with MQTT began 8 years ago in 2011 when Eclipse announced the M2M working group and IBM started the Eclipse Paho project. At the time, MQTT was one of many standards that were being positioned for use in M2M/IoT, standards like CoAP, LWM2M, XMPP, AMQP, and others. It was not obvious that MQTT was going to be the winner. However, looking back over the last 8 years, it is clear there were two main factors that drove MQTT’s acceptance as being the IoT standard: 1) Community and 2) Utility.

MQTT Community

In October 2011, IBM made the critical decision to submit MQTT to the OASIS standard group, and at the same time, begin the Eclipse Paho project. The combination of open-source and open-standard-removed barriers of adoption for MQTT. Anyone could implement MQTT into their product without paying royalties and Eclipse Paho provided an implementation of the MQTT client that developers could use to experiment. Around this time the Mosquitto project was also started by Roger Light to provide an open-source MQTT broker.

It wasn’t until early 2013 that the MQTT Oasis TC got rolling and Eclipse Paho code was available. From the Google Trends chart below, you can see interest starting to grow in 2013/2014 for MQTT.

Google Trends

The MQTT community continued to grow. A number of MQTT client tools were released to make it easier to debug MQTT applications. Other open-source brokers were released, including HiveMQ, VerneMQ, and others. HiveMQ published an extensive series of articles explaining in detail how to use the MQTT specification. The community was making it easy for developers to learn, experiment and adopt MQTT.

The success of MQTT has definitely been a community effort.

MQTT Utility: Solving IoT Challenges

Over the last year, I have spoken with many companies that have deployed IoT solutions using MQTT. From these conversations, it is clear that MQTT actually solves many of the difficult technical issues of building an IoT solution.

Reliable Messaging Through Unreliable Connectivity

IoT applications that connect over cellular networks must address the issue of how to maintain reliable messaging through an unreliable network. For instance, a connected car will move through dead zones of the cellular network and must deal with network latency. Maintaining a reliable message connection using HTTP is too complicated and expensive when you scale up to thousands and millions of clients.

MQTT’s publish/subscribe protocol, its ability to maintain open sessions, and retained messages uniquely solve the challenge of providing a reliable message through unreliable connectivity. For instance, BMW uses MQTT for its Share Now car-sharing service for this exact reason.

Bidirectional Messaging Between Device to Cloud

Most IoT applications involve bidirectional device to cloud messaging. In a typical scenario, device data is transmitted to the cloud and the cloud sends control information back to the device.

MQTT pub/sub protocol is by nature bidirectional. Clients subscribe to the messages they would like to receive and publish the information they want to send out to other clients. MQTT quality of service levels provide a degree of reliability that can be used to ensure a critical message is actually received.

Broadcast Messaging to Many Clients

Many IoT applications require the ability to broadcast a message out to many IoT clients. MQTT makes it possible to broadcast a single message to a thousand and every million devices.

Easy to Implement

MQTT was designed to be simple and lightweight. This has made it very easy to create MQTT clients for a wide variety of hardware platforms, including very small devices. It has also made it easy for developers to learn and implement MQTT systems. The simplicity of MQTT has been a very important part of its success.

In summary, MQTT has proven to be very useful for IoT use cases. Developers are using MQTT since it solves their problems, is easy to use, has a vibrant open source community providing tools and runtimes, and is open royalty-free standard.

What Is Next for MQTT?

MQTT has won so what is next? I expect to see a number of trends over the next 1–2 years.

Adoption of MQTT 5 Accelerates

MQTT 5 was released in 2018. This new version addresses many of the issues of deploying MQTT to large-scale, cloud-native environments and addressing a wider spectrum of IoT use cases.

Remember MQTT was developed 20 years ago before the cloud existed, so it needed to be updated. MQTT 5 will be the standard customer will expect for large scale MQTT deployments.

Industry-Specific Topic Namespaces

MQTT is an industry-standard for messaging but it doesn’t describe the payload. To achieve true interoperability within an industry, you need to have consistent payload formats. This is why initiatives such as Eclipse Tahu and Sparkplug are interesting to watch. The goal of Sparkplug specification is to define an MQTT topic namespace, payload, and session state management that can be applied generically to the overall IIoT market sector. Certainly, a big undertaking but some industries need payload consistency to achieve true interoperability.

Service-to-Service Messaging

MQTT has traditionally been used for device-to-cloud communication. However, as more and more companies adopt microservice architectures, I think we will see MQTT used for communication between services.

MQTT-SN

Andy Standford-Clark also announced that IBM has formally contributed MQTT-SN to OASIS. It will be interesting to watch the evolution of MQTT-SN especially as more and more compute processing is moved to the edge and 5G networks become more pervasive.

MQTT-SN on Twitter

MQTT: An Success Story 20 Years in the Making

It has been fun to be involved and watch the success of MQTT. It is a good reminder that new technology often takes time to see widespread adoption. However, to achieve successful adoption you need a community and the technology needs to solve important problems. MQTT has certainly accomplished both.

Congratulations to Andy and Arlen Nipper to co-creators of MQTT. Your invention has certainly accomplished a lot.

Disclosure: I work for HiveMQ on a part-time basis as their Head of Marketing

Further Reading

How to Choose the Right IoT Connectivity Protocol for Your Connected Device

MQTT for IoT Communication

[DZone Refcard] Getting Started With MQTT

Topics:
iot ,mqtt ,standard ,protocol ,mqtt 5 ,cloud-native

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}