Earlier this year, Google announced the offering of its fully-managed IoT device management service, Cloud IoT Core, to add to its suite of cloud platform services. We supported the public beta so we’ve had a few months to use it and learn.
What is Cloud IoT Core?
Before jumping into a sample architecture and demo we built at Leverege, let’s examine what Cloud IoT Core actually offers and when you might use it. Cloud IoT Core gives enterprises a fully-managed solution for securely connecting and monitoring/managing those devices globally. This means that devices can connect to the cloud via IoT Core, instead of being processed by a gateway/another platform and having it forward the data.
Aside from eliminating another layer of the deployment process, IoT Core adds security by default and helps funnel massive amounts of sensor data into its suite of data processing and analytics products. Google’s Cloud IoT Core also automatically takes care of load balancing and horizontal scaling as part of being on their serverless infrastructure. Lastly, if you’re already on the Android Things platform, the integration with IoT Core will help push out firmware and device update seamlessly.
Google’s blog describes a sample architecture to capture data from the devices, do some analytics in the cloud, and update the config on the device. A simple example would be to turn on a smart fan when the device detects that the room is getting too hot.
While this example is nice, it doesn’t provide an end-to-end IoT deployment architecture, including the UI component. So our team at Leverege made a quick waste management example to build off one of the more popular IoT use cases.
To begin, we provisioned a small VM and modified the sample MQTT client code to build a simulator that generates positional and sensor data on a garbage truck and trash bin. After provisioning a registry on Cloud IoT Core, we created simulated devices and started to pass telemetry data onto Cloud Pub/Sub. Next, we routed those messages onto Cloud FireStore and BigQuery for real-time updates to the UI and to show analytics via Google Data Studio.
Having used Azure’s IoT Hub before, here are some things we noticed about Cloud IoT Core:
- Generating RS256/ES256 keys were very simple. This was a stark contrast to the trouble I had with using the SAS token generator for Azure’s IoT Hub.
- Some key features are still under development. Currently, device batch creation and deletion are not supported. You can loop through to accomplish this task, but as registries cannot be deleted until all associated devices are deleted, an option for batch actions will be useful for rapid prototyping.
- Integration with Pub/Sub is nice and seamless but could be better. Currently, you need to give the Cloud IoT Core account publish access to Pub/Sub before setting up the registries. Automatically creating this access when enabling Cloud IoT Core or giving a programmatic way to let Compute Engine service account this access would remove another point of friction.
- Couple of other things to watch out for if you opt to use the default settings. There is a quota for 1 configuration/state updates per device per sec. This may come in the way of your demos depending on how you plan to use Cloud IoT Core. There is also a 10,000 devices per list request, so you would need pagination if your demo/use case calls for a bigger device set.
Other than the UI and the simulator to drive the demo, the only other non-Google component we had to build was a router/logic component (message processor). Currently, Cloud Dataflow only supports Java and Python, so we wrote a quick Node.js app to direct device messages to Cloud FireStore and BigQuery.
In this demo, we did not integrate real devices to test how onboarding works for actual hardware. But given the ease of security token generation and support for both HTTP and MQTT, we don’t foresee any challenges in enriching the simulation demo with real trucks and smart trash bins.