Google Cloud IoT Core Focuses On Simplicity And Scale

Google announced the availability of the beta of Cloud IoT Core, its enterprise IoT platform offering. The service has been in the private preview for select customers and partners. Let’s take a closer look at Google’s IoT platform as a service in its current form.

Google Cloud Platform

Technically speaking, Google had all the essential building blocks for developing and deploying scalable IoT solutions in its cloud platform. However, it lacked the glue that connects the dots among existing services to deliver an end-to-end device management and data processing pipeline. With Cloud IoT Core, Google exposes an industry-standard MQTT broker and a device registry to onboard connected devices and sensors.

An enterprise IoT PaaS must have a scalable device management layer complemented by a robust data processing pipeline. The below diagram represents the reference architecture of an enterprise IoT platform.

IoT Platform

Device Registry

The device registry acts as a central repository of all the devices connected to the platform. It contains device metadata such as serial number, make, model, location, asset id and more. The credentials associated with each device are securely stored in the registry. The registry also stores the digital twin of the device which contains the last known reported state of the device. Applications can query the device’s digital twin to get the metadata and latest data.

In Google Cloud IoT Core, the device registry is provisioned and exposed as an endpoint in a particular region. The endpoint can be used to connect the devices for the first time and for sending machine-to-machine (M2M) commands. The registry also stores per-device security credentials, which are used for whitelisting and blacklisting devices. It can also contain 32KB of metadata for each device. Customers can associate a pair of certificates with each device. When connecting devices to the service, the JWT-formatted signature is used for authentication.

One side of the registry exposes MQTT and REST endpoints while the other end is connected to the Cloud Pub/Sub service. Devices send messages to each other via secure MQTT or REST endpoints. These messages are delivered to other GCP services through the Pub/Sub topics.

Cloud IoT Core supports industry standard MQTT broker that needs no changes to existing code. Developers familiar with Paho or any other MQTT client library can target Cloud IoT Core without modifying the code. This is one of the best design decisions of Google’s IoT platform.

Device Ingestion

The MQTT endpoint of the device registry acts as the gateway for sending commands and messages among connected devices. Once authenticated, certain devices ingest high-velocity data for processing. Some data points of the stream are analyzed in real-time while other are routed to a data store for analyzing historical trends.

Google Cloud Pub/Sub acts as the endpoint for ingesting high-velocity data. For processing the inbound data, customers can create a pipeline in Cloud Dataflow. Based on Apache Beam, Cloud Dataflow service supports both real-time and batch processing of data. If customers already have a Hadoop cluster, data can be quickly routed to Cloud Dataproc, GCP’s own Big Data platform based on managed Hadoop and Spark stack. Implementing a data lake is also possible by routing the raw data to Google Cloud Storage. Finally, BigQuery, the most popular data warehouse in the cloud can be used to aggregate and query the data.

Orchestration, Dynamic Rules and Predictive Analytics

Google Cloud Pub/Sub is a robust and scalable data ingestion service in the cloud. Every inbound message into the Cloud IoT Core enters the Pub/Sub platform through the designated topic. The device registry becomes the publisher with multiple services acting as subscribes to the same topic.

Cloud Functions, Google’s Functions as a Service (FaaS) offering, can be one of the subscribers to the Pub/Sub topic. A simple code snippet deployed in Cloud Functions can evaluate the data points and invoke another contextual service. This may include republishing the message to another topic of MQTT or invoking a 3rdparty web service such as Twilio or SendGrid to push a notification. Developers can also take advantage of Firebase, the backend data store for integrating IoT data with mobile applications.

Customers will be able to integrate predictive analytics with IoT through the TensorFlow-based Cloud ML Engine. Cloud Functions can invoke a web service exposing a ML model for performing predictive analytics on the sensor data. This integration opens up interesting scenarios such as predictive maintenance (PdM), remaining useful life (RUL), and anomaly detection.

Almost any service in the GCP portfolio can become a subscriber to Pub/Sub to deal with sensor and device data ingested into the platform.

Key Takeaway

Google’s Cloud IoT Core reflects the principles of GCP – lightweight, simple, secure, robust and scalable. The key differentiator of the service is the integration of serverless components of the platform such as Cloud Functions, Dataflow, Dataproc and BigQuery. Implementing industry standard MQTT broker will help Google in on-boarding existing devices into the platform.

Though a bit late to the party, Google Cloud IoT Core will become a viable alternative to existing cloud-based IoT platforms. GCP customers will benefit from the seamless integration with existing services.

Comments

Popular posts from this blog

3 ways employees can risk your firm’s cybersecurity (and what to do about it)

H]ardOCP: Google Is Hurting Themselves with Their Poor Support of Windows

Scientists Discover Unlikely Source Of Electricity