IoT platform products typically provide basic MQTT and HTTPS data connectivity.They also let you provision devices, and they provide authentication and management,telemetry storage and visualization, data processing, and alerting.Organizations often use IoT platforms when a standalone MQTT broker isn'tsufficient for a use case and a more complete IoT platform product is needed. AnIoT platform provides a unified interface for managing a heterogeneouscollection of devices. This interface is important for many connected deviceapplications, and it's a key difference between an IoT platform and a standaloneMQTT broker. This document outlines the basic architectural considerations andrecommendations that you need to make before you deploy an IoT platform productarchitecture on Google Cloud.

This document is part of a series of documents that provide information aboutIoT architectures on Google Cloud. The other documents in this series include thefollowing:

• Connected device architectures on Google Cloud overview
• Standalone MQTT broker architecture on Google Cloud
• IoT platform product architecture on Google Cloud (this document)
• Best practices for running an IoT backend on Google Cloud
• Device on Pub/Sub architecture to Google Cloud
• Best practices for automatically provisioning and configuring edge and bare metal systems and servers

The following diagram shows an example architecture with a generic IoT platformproduct running on Google Cloud.

As shown in the preceding diagram, the IoT platform deploys an MQTT broker orendpoint for device connectivity. The IoT platform is connected to an external proxy Network Load Balancerto distribute traffic from the edge devices. Additional IoT applications canconnect to the IoT platform through Pub/Sub, or by using theDataflow MQTT connector.

The IoT platform provides a set of device management services. As shown in thediagram, these services are as follows:

• Device credential store
• Rules engine
• Device authentication and authorization
• Device configuration management
• Device registry
• Device update management

IoT platform products also generally include services such as digital twinfeatures, low-code development interfaces, alerting and notificationcapabilities, and other analytics functionality.

Architectural considerations and choices

The following sections describe the architectural choices that you can make foran IoT platform product architecture, and the impact of these choices.

Ingestion endpoints

Most commercial IoT platform applications include an MQTT endpoint, andusually also an HTTPS endpoint for data ingestion from connected devices.

MQTT

An IoT platform implements an MQTT endpoint in one of the following ways:

• A connector between MQTT and another message service
• An MQTT broker which implements the full MQTT specification

When you evaluate commercial IoT platforms, it's important to know which of thepreceding approaches the vendor has chosen for the product so that you candetermine the implications for your use case.

In some cases, the MQTT endpoint only connects the MQTT clients with a backendmessaging service, such as Kafka or Pub/Sub. This type of endpointusually does not implement the complete MQTT protocol specification, and oftendoesn't include features such as QoS levels 1 and 2, or shared subscriptions.The advantage of this approach is that it decreases complexity in the IoTplatform, because there's no separate MQTT broker application. Operational costsare lower, and maintenance is simpler than if the platform uses a separate MQTTbroker. However, because of the reduced support for more advanced MQTT protocolfeatures, this approach means that there is less flexibility and functionalityfor MQTT message transport than a standalone MQTT broker that implements thecomplete MQTT specification.

Other IoT platforms provide a complete MQTT broker as part of the platform, asshown in the example architecture in this document. This broker might be one ofthe existing open source brokers, or a proprietary broker implementation. A fullMQTT broker provides the full bidirectional MQTT capability described earlier,but a full broker can add complexity and operational costs to the management ofthe IoT platform.

HTTPS and other supplementary protocols

In addition to MQTT, many IoT platforms provide more data ingestion endpointsthan those that are shown in the main architecture that this document describes.

HTTPS is a common alternative protocol to MQTT for connected device use cases.It has higher overhead than MQTT, but it's more widely supported by mobile devicessuch as phones, and by web browsers and other applications. It's frequently usedin certain connected device applications, and it's supported by open sourceplatforms likeEclipse Hono and many commercial products.

Many constrained device applications use(Constrained Application Protocol (CoAP), defined in RFC 7252)as an MQTT alternative. CoAP targets low-overhead and small-footprintclients for embedded devices and sensors. Many commercial IoT platformapplications also provide a CoAP endpoint.

Load balancing

For more information about choosing the best load balancer for yourarchitecture, see theload balancing section of the Standalone MQTT broker architecture on Google Cloud because those considerations are applicable to this case as well.

Device authentication and credential management

Management of device credentials and authentication is a key part of theoperation of an IoT platform. The authentication methods supported by connecteddevices vary widely across applications and device form factors. It's importantto select the appropriate authentication method for the target use case, andimplement the chosen authentication scheme correctly.

Unlike a standalone MQTT Broker, an IoT platform provides integrated services tomanage device identity and credentials. Most IoT platforms use X.509 clientcertificate authentication for authentication, JWT token-based authentication(often combined with OAuth 2.0), and username and password authentication. Someplatforms also support integration with an external LDAP authenticationprovider.

For some constrained devices, JWT or username and password authentication mightbe more appropriate, because these schemes require fewer resources on aconnected device. When you use either JWT or username and passwordauthentication, it's important that you encrypt the network connectionseparately to mTLS authentication, because an encrypted connection is notrequired by either of these authentication methods. X.509 certificateauthentication, by contrast, consumes more resources on the connected device,but is typically used in an mTLS-encrypted connection and thus provides a highlevel of security.

Provisioning the authentication credentials on the edge device at manufacturingtime is also an important part of the connected device authentication scheme,but is outside the scope of this document.

For more information about authentication and credential management, seeBest practices for running an IoT backend on Google Cloud.

Manage connected devices

Typically, connected devices publish telemetry events and state information tothe platform through one of the ingestion endpoints such as MQTT. If you'reusing a multi-protocol IoT platform, devices can communicate using any of thesupported protocols.

We recommend that your organization use an IoT platform that has the followingcapabilities:

• Software and system updates: The delivery and rollback of firmware,software, and application updates to the connected devices. These updatesusually also involve storage and management of the updates themselves.
• Configuration updates: The delivery, storage, and rollback ofupdates to the configuration of applications deployed on the connected devices.
• Credential creation and management: The creation of new devicecredentials, delivery of those credentials to the connected device,auditing of device access attempts and activity, and revocation ofcompromised or expired credentials at the appropriate time.
• Rules engine and data processing: The definition and execution ofdata-driven rules and other data processing steps. This capability oftenincludes some type of low-code interface for defining rules and dataprocessing pipelines.

Backend workloads

Most IoT platforms provide their own internal data storage and transportcapabilities that let you connect to your backend workloads andapplications. AMQP, RabbitMQ, and Kafka are commonly used to provide internaldata transport. These can all be connected to Pub/Sub using thePub/Sub SDK. You can also use an integrated database system suchas PostgreSQL to store data in the platform. In many cases, the IoT platformcan be configured to use one of the Cloud Storage products directly, such asCloud SQL, Firebase, or BigQuery.

If the IoT platform has a complete MQTT broker, backend applications can alsocommunicate with devices by using the MQTT capability of the platform. If theapplication supports MQTT, the application can connect with the broker as asubscriber. If there is no MQTT support, Apache Beam provides an MQTT driver,which enables bidirectional integration with Dataflow as well asother Beam deployments.

Use cases

The following sections describe example scenarios where an IoT platform is abetter architectural choice than a standalone MQTT broker or a direct connectionto Pub/Sub.

Smart appliance management

Applications that manage multiple smart appliances are well-suited to an IoTplatform. An example of such an application is a platform to manage kitchenappliances such as dishwashers and coffee makers. These devices generallyconnect to a cloud-based application, either directly over Wi-Fi or through alocal gateway that uses a Bluetooth Low Energy (BLE) or another local protocol.The management capabilities of an IoT platform are important here, formonitoring the state of each device, managing software updates and securitypatches, and capturing device activity to provide critical intelligence to themanufacturer and the customer. These capabilities are beyond the scope of abasic MQTT broker. At a minimum, a device information repository, a device statedatabase, a telemetry datastore, and an analytics interface are all critical tobuilding a successful smart appliance platform.

Logistics and asset tracking

For a logistics and asset tracking application, an IoT platform product offersmore complete functionality than a basic MQTT broker, so is a better choice forthis use case. Monitoring the current and past state and location of a largefleet of assets depends on a robust device state database and identitymanagement system. As new assets are deployed, they need to be connected to theplatform with as little friction as possible, and subsequently monitoredthroughout the asset lifecycle. In many cases, the application also collectsother sensor information about the asset, such as local temperature, humidityand atmospheric pressure, or 3D positioning and acceleration data to detectunexpected movements or drops. All this data must be ingested and associatedwith the correct asset for analysis in any backend application, so thefull-featured device management provided by the IoT platform is an importantcapability.

What's next

• Read about connecting devices and building IoT applications on Google Cloud usingIntelligent Products Essentials.
• Learn about practices forautomatically provisioning and configuring edge andbare metal systems and servers.
• For more reference architectures, diagrams, and best practices, explore theCloud Architecture Center.