Cloud Platforms for Connected Products

What an IoT cloud platform does

Google's architecture guide to IoT platform products sums up the usual job list: they "provide basic MQTT and HTTPS data connectivity", let you provision devices, and provide "authentication and management, telemetry storage and visualization, data processing, and alerting". It also notes the difference from a plain message broker: an IoT platform "provides a unified interface for managing a heterogeneous collection of devices".

In practice, the platform sits between your devices and everything else: the database that stores readings, the rules that raise alerts, the firmware update service, and the API that your mobile and web apps call. The apps rarely talk to the devices directly; they talk to the cloud, as our guide on connecting a device to a mobile app explains.

Amazon and Microsoft each offer a dedicated service:

• AWS IoT Core, which "provides the cloud services that connect your IoT devices to other devices and AWS cloud services". Its documentation lists support for MQTT, MQTT over secure WebSockets, HTTPS and LoRaWAN.
• Azure IoT Hub, which Microsoft describes as "a managed service that acts as a central message hub in a cloud-based IoT solution", supporting device-to-cloud messages, file uploads from devices and request-reply methods to control devices.

MQTT, the common language

Most connected devices talk to the cloud using MQTT. The MQTT site says "MQTT is an OASIS standard", with MQTT 5 the current OASIS Standard and MQTT 3.1.1 an older ISO and OASIS Standard. The MQTT 5.0 specification describes it as "a Client Server publish/subscribe messaging transport protocol" that is "light weight, open, simple, and designed to be easy to implement", which suits devices with little memory and power.

A standard protocol does not mean every platform behaves the same. Two examples from the providers' own documentation:

• AWS says its MQTT support is "based on the MQTT v3.1.1 specification and the MQTT v5.0 specification, with some differences". For example, it supports quality of service levels 0 and 1, but not level 2.
• Microsoft says IoT Hub's device endpoints support MQTT v3.1.1, but "IoT Hub isn't a full-featured MQTT broker and doesn't support all the behaviors specified in the MQTT v3.1.1 standard". For a cloud-hosted MQTT broker, it points to Azure Event Grid instead. IoT Hub also requires TLS, so it does not accept unencrypted MQTT on port 1883.

So the firmware should be written against the behaviour of the platform you choose, and tested against it, not only against the standard.

Device identity and the registry

Every platform keeps a list of the devices allowed to connect, and each device proves who it is with its own credentials.

• AWS IoT provides a registry "that helps you manage things", where a thing "is a representation of a specific device or logical entity".
• In Azure, "Every IoT hub has an identity registry that stores information about the devices and modules permitted to connect". A device can only connect once it has an entry there, and it authenticates with credentials stored in the registry.

Plan how devices get their identity in the factory, and how a lost or stolen device is blocked, before production starts. Unique credentials per device are also part of the security rules covered in our IoT security guide.

Device state: shadows and twins

Devices go offline: batteries sleep, signal drops, Wi-Fi changes. Both platforms keep a copy of each device's state in the cloud so apps do not have to wait for the device.

• The AWS IoT Device Shadow service "can make a device's state available to apps and other services whether the device is connected to AWS IoT or not".
• Azure device twins "are JSON documents that store device state information including metadata, configurations, and conditions", with desired properties set by the back end and reported properties sent by the device. Microsoft notes that device twins are only available in IoT Hub's standard tier.

This is how an app can show "heating set to 21 degrees, will apply when the thermostat next connects". The shape of these documents becomes part of your product, so design it carefully.

The Google Cloud IoT Core retirement

Google offered a comparable service, Cloud IoT Core. Google's own services summary from July 2023 says "IoT Core will be discontinued on August 16, 2023 and is not accepting new customers", and Google's Eventarc deprecations page lists support for Cloud IoT events as deprecated on August 16, 2022 and shut down on August 16, 2023. Google's old IoT Core page now leads to an architecture guide for running third-party IoT platform products on Google Cloud.

Products built on it had a year to move every device to another platform. For devices already in customers' homes and fields, that means updating the firmware over the air, which only works if the update path itself is robust.

Keeping your options open

You cannot avoid depending on a platform, but you can make a future move cheaper:

• Use standard MQTT on the device and keep platform-specific code in one clearly separated layer of the firmware.
• Make sure devices can be updated over the air, including the endpoint they connect to and their credentials.
• Own your data: store readings in a database you control as well as in platform-specific services, and know how to export them.
• Put an API of your own in front of the apps, so the mobile and web apps do not depend on platform details. Our guide on choosing a backend for a mobile app covers this side.
• Keep every cloud account in your company's name, with access for more than one person.

The radio you choose also affects this: cellular, Wi-Fi and LoRaWAN devices reach the cloud in different ways, as our guide on choosing connectivity explains.

A checklist

• List what the cloud must do: connectivity, device registry, state, storage, alerts, updates, app API.
• Check the platform's MQTT support against what the firmware needs (versions, quality of service, encryption).
• Plan device identity in production, and how to block a device.
• Design the device state document (shadow or twin) as part of the product.
• Confirm the tier you need supports the features you use.
• Keep platform-specific code and data paths contained, and devices updatable.
• Keep accounts, data and code under your company's control.

Frequently asked questions

Do we need AWS IoT Core or Azure IoT Hub, or can we run our own MQTT broker?

Either can work. Google's architecture guidance describes both a standalone MQTT broker and a full IoT platform, and says organisations often use an IoT platform when a standalone broker is not enough, because the platform adds device management. A small fleet with simple needs may not need the full platform; a large one usually benefits from it.

Is MQTT the only option for devices?

No. AWS IoT Core, for example, also accepts HTTPS and LoRaWAN. MQTT is common because it is a light, open publish/subscribe standard designed for constrained devices.

What happens to our devices if a cloud service is shut down?

They have to be moved to another service before the shutdown date, usually with a firmware update. When Google discontinued Cloud IoT Core on 16 August 2023, the deprecation notice had been published a year earlier. Devices that cannot be updated over the air would have to be updated by hand or replaced.

Are device shadows and twins available on every plan?

Not always. Microsoft notes that Azure IoT Hub device twins are only available in the standard tier, not the basic tier. Check which features each tier includes before you design around them.

Building a connected product? We build the firmware connectivity, the backend that collects and acts on device data, and the mobile and web apps, with security planned in from the first prototype. See our IoT development service and all our services, or email [email protected].