To maximize the value of data from their connected devices, organizations needto be able to perform data analysis. There are many ways for organizations toconnect their devices to their analytics applications, and the benefits ofspecific connected device architectures can vary depending on the use case ofyour organization. To help guide you, this document describes a set of connecteddevice architectures on Google Cloud. These architectures address a broadrange of use cases and requirements for connected devices.

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

• Connected device architectures on Google Cloud overview (this document).
• A standalone MQTT Broker:AnMQTT broker provides bidirectional communication between connected devices andGoogle Cloud projects, and between the devices.
• An IoT platform architecture on Google Cloud: AnIoT platform provides additional device management capabilities along withdata connectivity, which is important when you deploy a large fleet ofconnected devices.
• A direct connection to Pub/Sub: For data ingestion, thebest choice might be for your devices to connect directly to Pub/Sub.
• Best practices for running an IoT backend on Google Cloud.
• Best practices for automatically provisioning and configuring edge and bare metal systems and servers.

Connected device architectures summary

This document groups connected device use cases into three categories, based on the following dimensions that you need to consider when you plan aconnected device architecture:

• Number of devices: It's important to consider how many devices aredirectly connected to your application. If your application has many enddevices (such as machines, sensors, or cameras), and if these devices are connectedto an intermediate gateway or other device (such as a mobile phone),it's important to identify whether those end devices must be represented andmanaged in your application. In some cases you might need to represent eachindividual device; in other cases, only the intermediate device mightneed to be represented.

• Fleet management: Consider whether you need capabilities likedevice status monitoring, software and firmware updates, configurationmanagement, and other fleet management features. These requirementshelp to determine your choice of application architecture.

• Inter-device messaging: Device communication through yourapplication architecture is an important factor. For example, someapplications depend on communication between the connected devices throughyour application architecture. Other applications have data flows thatoccur strictly between each device and your application, with no messagingbetween devices.

Summary table

Understanding the characteristics of your application can help you to choosethe best architecture for your use case. To help guide your choice, thefollowing table summarizes the support that each of the connected architecturesthat are described in this series offers:

What's next

• Read about the best connected device architecture for your use case:
  • A standalone MQTT Broker:
  • An IoT platform architecture on Google Cloud.
  • A direct connection to Pub/Sub.
• Learn how to connect devices and build 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.