Stay organized with collections
Save and categorize content based on your preferences.
Last reviewed 2024-09-09 UTC
To maximize the value of data from their connected devices, organizations need
to be able to perform data analysis. There are many ways for organizations to
connect their devices to their analytics applications, and the benefits of
specific connected device architectures can vary depending on the use case of
your organization. To help guide you, this document describes a set of connected
device architectures on Google Cloud. These architectures address a broad
range of use cases and requirements for connected devices.
This document is part of a series of documents that provide information about
IoT architectures on Google Cloud. The other documents in this series
include the following:
Connected device architectures on Google Cloud overview (this document).
A standalone MQTT Broker:
An
MQTT
broker provides bidirectional communication between connected devices and
Google Cloud projects, and between the devices.
An IoT platform architecture on Google Cloud: An
IoT platform provides additional device management capabilities along with
data connectivity, which is important when you deploy a large fleet of
connected devices.
A direct connection to Pub/Sub: For data ingestion, the
best choice might be for your devices to connect directly to Pub/Sub.
This document groups connected device use cases into three categories, based on the following dimensions that you need to consider when you plan a
connected device architecture:
Number of devices: It's important to consider how many devices are
directly connected to your application. If your application has many end
devices (such as machines, sensors, or cameras), and if these devices are connected
to an intermediate gateway or other device (such as a mobile phone),
it's important to identify whether those end devices must be represented and
managed in your application. In some cases you might need to represent each
individual device; in other cases, only the intermediate device might
need to be represented.
Fleet management: Consider whether you need capabilities like
device status monitoring, software and firmware updates, configuration
management, and other fleet management features. These requirements
help to determine your choice of application architecture.
Inter-device messaging: Device communication through your
application architecture is an important factor. For example, some
applications depend on communication between the connected devices through
your application architecture. Other applications have data flows that
occur strictly between each device and your application, with no messaging
between devices.
Summary table
Understanding the characteristics of your application can help you to choose
the best architecture for your use case. To help guide your choice, the
following table summarizes the support that each of the connected architectures
that are described in this series offers:
Device support limits
Inter-device messaging
Fleet management support
MQTT Broker
Millions
Recommended
Not supported
IoT platform
Millions
Some support
Recommended
Device to Pub/Sub
Hundreds
Some support
Not supported
What's next
Read about the best connected device architecture for your use case:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2024-09-09 UTC."],[[["\u003cp\u003eOrganizations need data analysis to maximize the value of data from connected devices, and there are various ways to connect these devices to analytics applications.\u003c/p\u003e\n"],["\u003cp\u003eThis document outlines several connected device architectures on Google Cloud, addressing a variety of use cases and requirements.\u003c/p\u003e\n"],["\u003cp\u003eKey considerations when planning a connected device architecture include the number of devices, the necessity of fleet management, and the need for inter-device messaging.\u003c/p\u003e\n"],["\u003cp\u003eThe document classifies connected device use cases into three categories, considering the number of devices, fleet management needs, and inter-device communication requirements.\u003c/p\u003e\n"],["\u003cp\u003eThe document provides a summary table that compares connected architectures: MQTT Broker, IoT Platform, and device to Pub/Sub, highlighting their support for device limits, inter-device messaging, and fleet management.\u003c/p\u003e\n"]]],[],null,["# Connected device architectures on Google Cloud\n\nTo maximize the value of data from their connected devices, organizations need\nto be able to perform data analysis. There are many ways for organizations to\nconnect their devices to their analytics applications, and the benefits of\nspecific connected device architectures can vary depending on the use case of\nyour organization. To help guide you, this document describes a set of connected\ndevice architectures on Google Cloud. These architectures address a broad\nrange of use cases and requirements for connected devices.\n\nThis document is part of a series of documents that provide information about\nIoT architectures on Google Cloud. The other documents in this series\ninclude the following:\n\n- Connected device architectures on Google Cloud overview (this document).\n- [A standalone MQTT Broker](/architecture/connected-devices/mqtt-broker-architecture): An [MQTT](https://mqtt.org/) broker provides bidirectional communication between connected devices and Google Cloud projects, and between the devices.\n- [An IoT platform architecture on Google Cloud:](/architecture/connected-devices/iot-platform-product-architecture) An IoT platform provides additional device management capabilities along with data connectivity, which is important when you deploy a large fleet of connected devices.\n- [A direct connection to Pub/Sub](/architecture/connected-devices/device-pubsub-architecture): For data ingestion, the best choice might be for your devices to connect directly to Pub/Sub.\n- [Best practices for running an IoT backend on Google Cloud](/architecture/connected-devices/bps-running-iot-backend-securely).\n- [Best practices for automatically provisioning and configuring edge and bare metal systems and servers](/architecture/connected-devices/best-practices-provisioning-configuring-bare-metal).\n\nConnected device architectures summary\n--------------------------------------\n\nThis document groups connected device use cases into three categories, based on the following dimensions that you need to consider when you plan a\nconnected device architecture:\n\n- **Number of devices:** It's important to consider how many devices are\n directly connected to your application. If your application has many end\n devices (such as machines, sensors, or cameras), and if these devices are connected\n to an intermediate gateway or other device (such as a mobile phone),\n it's important to identify whether those end devices must be represented and\n managed in your application. In some cases you might need to represent each\n individual device; in other cases, only the intermediate device might\n need to be represented.\n\n- **Fleet management:** Consider whether you need capabilities like\n device status monitoring, software and firmware updates, configuration\n management, and other fleet management features. These requirements\n help to determine your choice of application architecture.\n\n- **Inter-device messaging:** Device communication through your\n application architecture is an important factor. For example, some\n applications depend on communication between the connected devices through\n your application architecture. Other applications have data flows that\n occur strictly between each device and your application, with no messaging\n between devices.\n\nSummary table\n-------------\n\nUnderstanding the characteristics of your application can help you to choose\nthe best architecture for your use case. To help guide your choice, the\nfollowing table summarizes the support that each of the connected architectures\nthat are described in this series offers:\n\nWhat's next\n-----------\n\n- Read about the best connected device architecture for your use case:\n - [A standalone MQTT Broker](/architecture/connected-devices/mqtt-broker-architecture):\n - [An IoT platform architecture on Google Cloud](/architecture/connected-devices/iot-platform-product-architecture).\n - [A direct connection to Pub/Sub](/architecture/connected-devices/device-pubsub-architecture).\n- Learn how to connect devices and build IoT applications on Google Cloud using [Intelligent Products Essentials](/architecture/intelligent-products-essentials-architecture).\n- Learn about practices for [automatically provisioning and configuring edge and\n bare metal systems and servers](/architecture/best-practices-provisioning-configuring-bare-metal).\n- For more reference architectures, diagrams, and best practices, explore the [Cloud Architecture Center](/architecture)."]]
