Decoding The Google IoT Core Conundrum

This year, in mid-August, Google Cloud announced that it would be shutting down its IoT Core service in a year, providing their existing customers until mid-August 2023 to move their existing solutions from Google IoT Core to an alternative IoT (Internet Of Things) platform of choice.

Google IoT Core — A Quick Overview

Google Cloud’s IoT Core offering is a fully managed service that acts as a point of ingest of telemetry and event data from devices deployed in the field. This also serves as the interface to any updates required to be made to devices in the field. 

As in a typical lambda architecture pattern for IoT deployments, telemetry and event data from devices are ingested at scale via the IoT Core service, which is then routed into a data pipeline based on relevant service offerings from the Google Cloud Service portfolio to enable IoT applications. 

What Prompted The Announcement

While the announcement may seem to have been surprising to many in the industry (particularly in the IoT domain), Google hadn’t been focusing on their IoT portfolio for quite some time. 

In an extremely competitive IoT Cloud Services market where vendors are constantly trying to innovate to achieve that extra edge over their competitors, Google has neither provided any engineering updates to the IoT Core service since 2019 nor have they launched any new IoT service in the ecosystem. 

Hence, the decision to discontinue the service is probably a business decision to repurpose Google’s strengths in alternative services they provide (such as smart homes) considering that there has been no real progress on improving industry adoption of its IoT services.

Considerations Towards Minimising The Impact Of Similar Disruptions

Some strategic considerations that can help reduce the risk of similar situations in the future would include:

• Adopting IoT platform services offered by the service vendor across multiple cloud vendors: This would mean significant investment and confidence in business from the service.  
• Ensure cloud vendor neutrality: A trend today is to build neutral platforms using CNCF components (e.g., Kubernetes), thus enabling easy migration of workloads across cloud vendors if the need arises.
• Architecting the edge software stack to be independent of the cloud vendor agent: This can be achieved by using open-source edge gateway stacks with cloud platform-specific agents deployed on top. Such a strategy would compartmentalise the impact of the change to replacing the agent software — while the remaining parts require minimal changes. 
• Pre-define and document a migration strategy upfront: The solution architecture should consider buffering in some such elements as hygiene factors.
• Over-The-Air (OTA) should be a crucial element of the IoT solution: The solution should ensure that there are systems built into the solution proactively to enable a switch to a new platform, especially in consumer deployments. Firmware, configuration, and certificate updates based on OTA are crucial to address a large mass of geographically dispersed device deployments spread across before triggering a bootstrap to the new platform.

Acting On The Need To Migrate

Customers on Google IoT Core services need to start planning right now for the migration considering they have to complete migration to a new platform by August 2023. 

The situation might be a little challenging considering that the process may involve development, testing, updating of deployed devices in the field, monitoring of new deployments, and ensuring smooth coordination of logistics, among other considerations. There are multiple alternatives available when adopting a migration path:

• Migrate to other offerings present in the market: Platforms such as ClearBlade promise an automated and quick replacement of the Google IoT Core service with an alternative. However, it is important to confirm the popularity of market adoption of the new service too.
• Gradual move rather than a big bang approach: Replace the ingest service (Google IoT Core) with an offering from another vendor (Azure IoT Hub, AWS IoT Core) providing similar services in the same region but maintain the downstream services as-is (Google Services). This of course needs to be evaluated in terms of performance/latency impact, complexity, etc. Migrate the downstream services to the offerings from the chosen vendor at a later point in time. 
• Adopt a readily available vendor IoT platform: While we can adopt a different platform, it is important to ensure the vendor offering is cloud agnostic, has an established market, and has proven adherence to SLAs for scale, performance, etc.
• Build and adopt a cloud vendor agnostic platform in-house: While this approach is beneficial in the long run, it has a high time to market.

It is a business imperative for customers invested in IoT solutions based on Google’s IoT Core service to move early and embark on a defined platform migration journey to ensure minimal risk, but structured, migration implementation. 

A migration assessment (to understand active device portfolio, business, technical, and regulatory requirements), followed by a planning phase to explore migration alternatives, identify process, timelines, impact assessment, etc.) and finally a migration execution (across phases such as pilot, MVP, mass migration) with relevant tools and processes will enable a smooth switchover of the solution to a new platform.

Note: We at Inc42 take our ethics very seriously. More information about it can be found here.