The Importance of IoT Standards for Cloud Platforms

Summary

The technology industry has a love-hate relationship with industry standards. Some standards are very popular and have propelled industries forward. For instance, HTTP, HTML and TCP/IP underpin the Internet as we know it today. Other standards are less popular and have not been widely adopted. It has been said,“Industry standards are like toothbrushes: everyone wants to use them but no one wants to use someone else's.”
 
Widespread adoption of open industry standards is helpful in many instances, but especially in cloud computing as customers work with the big three Cloud providers: AWS, Azure and Google. As the quote implies, the cloud hyperscalers often use some aspects of open standards but add their own proprietary technology to keep customers close to the vest. 
 
A recent development highlights the detriment of not sticking to industry standards: Google deprecating IoT Core. Customers using Google IoT Core for data ingestion must scramble to engineer a new solution. Those who had already based their architecture on feeding data to GCP with open standards can easily pivot rather than being locked in, while those who were dependent on Google IoT Core now have to put in extra time and effort to solve the foundational problem of getting data to the cloud. This article will explain why those customers would have been better served going with an open standard from the beginning.

General benefits of sticking to open standards for cloud computing: 

1. Building value on top of a standards ecosystem.
Customers often buy solutions that require integration from multiple vendors. The absence of a standard requires vendors or customers to do pairwise integrations between two specific products, which is costly, inefficient and slows down innovation. If a standard becomes widely adopted, the integration work required becomes trivial and customers and vendors can immediately start to build value on top of the standards ecosystem.

2. More customer choice.
If there is an ecosystem of vendors supporting integration based on a standard, the customer has more choice to select vendors to meet the requirements for their solution. More choice for customers forces vendors to focus on value and add functionality to differentiate their product from competitors.

3. Investment protection.
How can a customer ensure a vendor will be their preferred vendor into the future? Vendors change their focus, get acquired, go out of business, etc. If the customer solution is built on a widely adopted standard, it allows for future proofing of the solution. It is easier to swap out a product at a later date if both products are based on a common standard.

4. No vendor lock-in.
Companies don’t want to be locked into one vendor. As mentioned, vendors evolve their offerings, so forward thinking customers ensure they can be agile and are not locked-in to a specific vendor. Standards help to avoid vendor lock-in.

Incomplete adoption of IoT standards

The benefits of open standards are clear, and in the IoT industry in particular a number of standards are being adopted. However, in many cases they aren’t being implemented at quite the level that would help to propel the industry forward to reap all of the benefits above. MQTT is widely adopted in the IoT industry. Hive MQ has been actively involved in the MQTT specification and has helped drive adoption.
 
One of the biggest challenges for companies today is feeding their cloud systems with complete and contextualized data, and MQTT provides the mechanism. MQTT is a client server publish/subscribe messaging transport protocol. It is ideal for cloud data ingestion because it is lightweight, open, simple, and ideal when network bandwidth is at a premium. MQTT allows any company to collect data from edge devices and get the data to the cloud in a unified and simple way.
 
MQTT is being adopted by the industry, and particularly by cloud platforms like Azure IoT and AWS IoT. Unfortunately, AWS IoT and Azure IoT claim MQTT support but they don’t implement the full specification. They miss out on features like retained messages, QoS2 support, place limitations on topic structure, etc. They also push customers towards their proprietary client SDK that sends MQTT messages but only to their respective MQTT service. Neither cloud platform provides production support for MQTT 5. Customers can’t really obtain the maximum benefit of using MQTT with these cloud services.
 
The impact of this incomplete approach is essentially a proprietary MQTT implementation. The basic MQTT support allows hardware vendors to send MQTT messages to the cloud platforms. Customers are given the appearance of an ecosystem of applications and hardware that can connect with the platform. However this is for rudimentary MQTT data ingestion.

Effects of limited adoption of IoT standards

1. Deep production and product data lock-in.
What the big three cloud providers are creating is deep lock-in to a company's production data and product data. A company that builds a new smart/connected product based on connectivity to AWS IoT or Azure IoT risks locking their company's product to the cloud platform. If the product uses the Azure/AWS SDK that is generating MQTT messages tightly coupled with the IoT service, it becomes very difficult to switch to an alternative MQTT broker. It is possible but not as simple as if you were using a fully compliant MQTT client like Eclipse Paho or HiveMQ MQTT Java client. 
 
The same can be said about data from a production process being aggregated to AWS or Azure. Key information for running the operation is locked into the cloud provider and can’t be easily moved.

2. Limited choice of enterprise services.
Data lock-in also limits the enterprise services a company can choose to use to those provided by AWS,Azure, and Google. The big cloud providers are very motivated to capture as much data as possible and then upsell on data services like analytics, machine learning, AI, etc. This lock-in makes it difficult for companies to use third party services that might better suit their business needs. 

The full benefit of the MQTT specification

The limited support for the MQTT also limits the potential use and benefits of the specification. For instance, support for MQTT retained messages or QoS 2 are key features for any reliable business critical IoT system. The absence of these features puts unnecessary limitations on the potential quality of the production system. It also limits other standards being implemented on these platforms, for example Sparkplug. Sparkplug requires the use of retained messages, so users of Azure and AWS are not able to use the Sparkplug specification.
 
In addition, the lack of support for MQTT 5 blocks users from benefiting from the latest MQTT specification. MQTT 5 was released more than three years ago, in March 2019, so the commitment by AWS and Azure to MQTT seems to be very low. 

Caveat Emptor: Not all MQTT implementations are created equal

In conclusion, industry standards are critically important for widespread adoption and acceleration of new technologies. In the case of MQTT, we have widespread adoption but we do not have equal implementations of the MQTT standard. 
 
There are lots of MQTT brokers and MQTT clients available that implement 100% of the MQTT 3 and MQTT 5 specification. These complete implementations provide the full benefit of using an industry standard: no vendor lock-in, choice of services, wide ecosystem, and investment protection. When selecting a cloud service for communicating via MQTT, it is strongly advised to consider the wisdom "caveat emptor," buyer beware, and be careful to choose a solution that exposes the full benefits of the specification.