IoT Platform Product Architecture on Google Cloud
This document outlines the architectural considerations and recommendations for deploying an IoT platform product architecture on Google Cloud. It's part of a series covering IoT architectures on Google Cloud, including connected device architectures, standalone MQTT broker architecture, and best practices for IoT backend operations and device provisioning.
Architecture Overview
The diagram below illustrates a sample architecture featuring a generic IoT platform on Google Cloud. The platform uses an MQTT broker or endpoint for device connectivity, linked to an external proxy Network Load Balancer for traffic distribution. Additional IoT applications connect via Pub/Sub or the Dataflow MQTT connector.
The IoT platform includes device management services such as:
- Device credential store
- Rules engine
- Device authentication and authorization
- Device configuration management
- Device registry
- Device update management
Further services typically include digital twin features, low-code development interfaces, alerting, notifications, and analytics.
Architectural Considerations
Ingestion Endpoints
Most IoT platforms offer MQTT and HTTPS endpoints. MQTT implementations vary:
- Connector: Connects MQTT to a message service (e.g., Kafka, Pub/Sub). Simpler, but may lack advanced MQTT features (QoS levels 1 and 2, shared subscriptions).
- Full MQTT Broker: Provides complete bidirectional MQTT capabilities. More complex and costly to manage.
HTTPS is a common alternative, offering broader device compatibility but higher overhead. CoAP is another option for constrained devices.
Load Balancing
Refer to the 'Standalone MQTT broker architecture on Google Cloud' document for load balancing best practices.
Device Authentication and Credential Management
IoT platforms integrate device identity and credential management. Common authentication methods include X.509 client certificates, JWT tokens (often with OAuth 2.0), and username/password. Some platforms support LDAP integration. The choice depends on device capabilities and security requirements. Consider encrypting the network connection separately for JWT or username/password authentication.
Managing Connected Devices
Devices publish telemetry via ingestion endpoints. A robust IoT platform should offer:
- Software and system updates
- Configuration updates
- Credential creation and management
- Rules engine and data processing
Backend Workloads
IoT platforms often use AMQP, RabbitMQ, or Kafka for internal data transport, connectable to Pub/Sub. Integrated databases (PostgreSQL) or Cloud Storage products (Cloud SQL, Firebase, BigQuery) are common choices. Applications can interact with devices via the platform's MQTT broker (if available) or Apache Beam's MQTT driver with Dataflow.
Use Cases
IoT platforms excel where standalone MQTT brokers fall short:
Smart Appliance Management
Managing multiple smart appliances requires an IoT platform's device monitoring, update management, and security features. A device information repository, state database, telemetry datastore, and analytics interface are essential.
Logistics and Asset Tracking
Tracking assets benefits from an IoT platform's robust device state database, identity management, and data ingestion capabilities. This allows for efficient onboarding and monitoring of assets, along with the collection and analysis of sensor data.
What's Next
Explore Intelligent Products Essentials for connecting devices and building IoT applications on Google Cloud. Learn more about automatically provisioning edge and bare metal systems. The Cloud Architecture Center offers further reference architectures and best practices.
