Alternatives to Google Cloud IoT Core—Where to Migrate?

Google will sunset its IoT Core on August 16, 2023. Some of the edge devices may become unavailable, experts say.

What happened and why the urgency

Last year, Google announced that it would retire the Cloud IoT Core service soon, giving customers one year to migrate. It was also noted that the documentation for the product will no longer be available after August 15, 2023.

Until now, Cloud IoT Core was used by customers for device authentication, communication with the edge, updating configuration, data ingestion, etc. The main components of the product include a device manager and two protocol bridges (MQTT and HTTP) for connecting to Google Cloud Platform (GCP). Telemetry data is forwarded to a Cloud Pub/Sub topic and can then be used for analysis with other GCP services.

A typical workload using IoT Core (image credit)

Since the announcement, companies have put their effort into migrating off the platform. Most likely, the majority of them have already either finalized the migration or at least are in the process. Last month, a Reddit user posted a message mentioning 10,000 devices under high load that are still in ongoing migration due to complexity.

So, if you had reasons to avoid moving the IoT workloads until now or your migration failed and you are looking for a better technology option, read on.

What’s the plan?

After the anxiety the news from Google brought in last year, there were a lot of articles for CTOs, architects, and IoT engineers about possible further steps. While a lot of overviews suggested migrating the system to Azure, AWS, or another cloud platform (sometimes, completely), in reality many other options do exist.

Here’s why. Within particular deployments, the main functions of Cloud IoT Core are device management, data ingestion, and messaging. Depending on what of these you are using, in its documentation, Google recommends different migration options.

In brief (very simplified):

• If you rely on IoT Core for device management and data ingestion, you may need additional tools for these scenarios now (or a single platform combining the both requirements).
• For device communication, you can go with an MQTT broker.

The document notes that the hardest job will be to migrate the processing of devices that both produce and consume data for / from back-end workloads.

A standalone MQTT broker on GCP (image credit)

In addition, updates on the devices may also be needed on the edge. If not done before August 2023 over the air, this may require updating devices in the field, manually. If not updated, you may “consider them lost,” experts from Leverege write in their IoT Core migration guide.

Major alternative options and scenarios

So, when it comes to exact products and implementations, there are at least four possible groups of options for replacing IoT Core.

1. First of all, in the official announcements, Google noted that they see the partner ecosystem as the main driver for further development of this area. Therefore, the suggested option from Google is to choose among its partners. The product’s page features a list of preferred tools and platforms—including Aeris, EMQX, FogLAMP, KORE OmniCore, Leverege, Litmus, ThingsBoard, etc.

   A combination of these solutions is also possible (e.g., this tutorial explains how to integrate EMQX with ThingsBoard).

   Communication via an EMQX cluster (image credit)

   On top of that, new products from Google partners have appeared, such as ClearBlade IoT Core. (Here’s a technical overview of this automated offering and a migration tutorial.) SOTEC, in its turn, delivered a dedicated solution based on its contributions to open-source platform Eclipse Hono. SoftServe created IoT EnCore (utilizing VerneMQ), so the options exist.

   How ClearBlade IoT Core works (image credit)

2. You can also turn to platform providers outside the “featured” list, of course. Vendors from different verticals are competing for the privilege of acquiring IoT Core users. Many of them are Google partners, too. Some publish explanations why or how to migrate, others offer incentives.

   For instance, users migrating from Google IoT Core to the akenza platform can get a 10% discount for one year. Qubitro ensures six months of free credits for migrating to their platform.

   Other products that can be considered as alternatives to IoT Core—according to their teams—include Losant, Davra, Kaa, CLEA (SECO), Cloud Studio, LTIMindtree IoT Core+, Mapify IoT, Rayven Dynamix, etc. Large vendors such as Siemens and Software AG are also ready to host new customers on their Insights Hub and Cumulocity IoT. The choice depends on how much of their functionality you actually need, as well as the cost and other criteria essential for your project.

   (As a Google partner in cloud consulting, Altoros can also help.)

3. Another option, yes, is using similar IoT services from other major cloud platforms, such as Azure IoT Hub or Amazon IoT Core. However, you may have your own reasons to avoid the multicloud approach—whether it’s cost, compatibility, complexity, etc. Still, if you already have a muticloud deployment or have proper expertise / resources, this really is an alternative.

   Device management with Azure IoT (image credit)

   (Note: The funny thing is that a number of articles even suggested migrating to IBM Watson IoT, which will also be suspended on December 1, 2023. Previously, the product was competing with Azure and AWS against their IoT services. However, this is not an option anymore, of course.)

4. Finally, you can rely on messaging adapters / MQTT brokers. For instance, HiveMQ released the Google Pub/Sub Extension for this particular purpose. The company evaluated the performance of the extension at 50,000 MQTT messages per second (which means up to 4.32 billion messages a day).

   Soracom offers a similar approach, ensuring direct M2M communication of devices with a cloud platform through the Funnel adapter (see the docs). Open-source options for MQTT include Mochi, Mosquitto, etc. (See also the reasoning for the Mosquitto Pro version.) A broker from Google partner EMQ was mentioned earlier.

   HiveMQ Enterprise Extension for Google Cloud Pub/Sub (image credit)

   However, in this scenario, you may still need a separate device management solution in case your requirements include firmware updates, provisioning, monitoring, etc.

Hurry up, but do it wisely

There’s certain time pressure for this migration initiative, however it makes sense to take the most out of this unexpected situation.

First, there are chances that the requirements for the existing deployment have already evolved since the time your MVP/pilot started using Google Cloud IoT Core. Second, when choosing among IoT platforms or messaging brokers, you have both proprietary and open-source options. This means the variety of tools can help you adjust your architecture to your current needs and budgets. Especially in case they were affected by the ongoing crisis.

The choice of the technology depends on your implementation, but it is also a chance to review the environment architecture and optimize accordingly.

If you’re still coping with the migration (due to the size, complexity, or failures) or expect that some of the edge devices will be “bricked” after IoT Core’s EOL, I’d be glad to learn about your experience here, here, or in the comments below. I’m ready to add your story to this article.

Further reading

• Rule-Based Stream Data Processing at the Edge with eKuiper
• The Ins and Outs of Adopting the IoT for Transportation
• Scaling Industrial IoT in Manufacturing: Challenges and Guidelines