Migrate environments from IoT Core

Last reviewed 2023-02-01 UTC

Google has announced the deprecation of IoT Core. This document is intended to help you design and implement a migration plan from an IoT Core-based environment to a new environment that doesn't depend on IoT Core for any of the following:

  • Edge device authentication
  • Edge device management
  • Communication between your edge devices and Google Cloud

The document also provides guidance for if you're evaluating the opportunity to migrate following the deprecation of IoT Core and want to explore what a migration might look like.

This document is part of a series of documents that provide information about IoT architectures on Google Cloud and about migrating from IoT Core. The other documents in this series include the following:

The workload to migrate

This document assumes that the workloads that you want to migrate away from IoT Core have the following parts:

  • A part that runs on edge devices (deployed at the edges of your environment, and next to the data that you want to process)
  • A backend that runs on Google Cloud

The following diagram shows the architecture of a typical workload that uses IoT Core. In this architecture, Cloud IoT integrates edge devices that have a backend that runs on Google Cloud.

Flow of events from edge devices to Cloud IoT (summarized in following text).

The preceding diagram can be summarized as follows:

To effectively plan your migration, we recommend that you make an assessment to gain a full understanding of your source environment architecture. In this case, source environment refers to your current, IoT Core-based environment.

This document assumes that you can update the configuration of and the software components running on your edge devices for your migration. In some cases, this approach might be infeasible. For example, your edge devices or your deployment processes might not support this use case. In this case, we recommend that you plan to retire the edge devices that don't support updates. For more information about designing and implementing automated provisioning and configuration processes for edge devices, see Best practices for automatically provisioning and configuring edge and bare metal systems and servers.

Design the migration

To migrate your IoT Core-based environment, we recommend that you follow the migration framework described in Migration to Google Cloud.

The following diagram describes the path of your migration journey:

Migration path with four phases.

As shown in the preceding diagram, this journey has four phases:

  1. Assess: In this phase, you assess your source environment, assess the workloads and the edge devices that you want to migrate away from Cloud IoT Core.
  2. Plan: In this phase, you create the basic infrastructure on Google Cloud, such as provisioning the resource hierarchy and setting up network access.
  3. Deploy: In this phase, you deploy the new solution to use instead of IoT Core, and migrate your edge devices to the new solution.
  4. Optimize: In this phase, you optimize your target environment. In this case, target environment refers to the environment you're migrating to that is not based on IoT Core.

Assess the source environment and workloads

In the assessment phase, you gather information about your source environment, the edge devices, and the use of IoT Core in your organization. This information helps you to design a migration plan and to ensure that you have the resources that you need for the migration and for your target environment.

In the assessment phase, you do the following:

  1. Build an inventory of the edge devices that you registered to Cloud IoT Core.
  2. Build an inventory of the backend workloads that integrate with Cloud IoT Core.
  3. Categorize your edge devices and backend workloads.
  4. Experiment and design proofs of concept.
  5. Calculate total cost of ownership.
  6. Design the architecture of the target environment.
  7. Choose the edge devices and the backend workloads to migrate first.

At the end of the assessment phase, you have two inventories: an inventory for your edge devices and an inventory for your backend workloads.

To avoid inconsistencies, we recommend that you pause the deployment of new edge devices and backend workloads before you build these inventories. We also recommend that you don't deploy new edge devices and background workloads after you create the inventories.

Build an inventory of your edge devices

To scope your migration and to design your migration plan, you need to know how many edge devices exist in your source environment. You must also understand how the devices interact with IoT Core, and if you can categorize them by common characteristics, by behavior, by purpose, or by dependencies.

Each edge device that you register to IoT Core belongs to an IoT Core registry. The first step for building the inventory of your edge devices is to list the IoT Core registries you created. You then gather information about the edge devices registered in each registry.

To build the inventory of your edge devices, consider the following information for each edge device, and how the device integrates with IoT Core:

  • Identifiers: Gather the following information about the IoT Core identifiers of the edge device:

    • The user-defined identifier
    • The server-defined, non-editable ID that IoT Core automatically generates when you register an edge device to IoT Core
    • The resource name that uniquely identifies the edge device using the identifier of the IoT Core registry where you registered the edge device
  • Deployment state: Assess the current deployment state of the edge device. For example, the edge device might be in one of the following states:

    • Not yet manufactured, or currently being manufactured
    • Ready to be deployed, but not yet registered to IoT Core
    • Already deployed in its destination site, and registered to IoT Core
  • IoT Core device type: Assess the IoT Core device type. Each edge device that you register to IoT Core can act in one of two ways. It can be a client that connects directly to IoT Core. Or, it can be a gateway for the clients that you cannot or don't want to connect to IoT Core directly.

  • Communication protocol: IoT Core supports two protocols to communicate with edge devices: HTTP and MQTT. Assess which protocol your edge devices use to communicate with IoT Core. For the MQTT protocol, you must also determine the quality of service that your edge devices and backend workloads rely on.

  • Credentials: IoT Core authenticates edge devices using a key pair and short-lived tokens generated using that key pair. It can optionally verify the signature of the public part of the key pair using a certificate-based verification method. Assess how the authentication of the edge device is configured. Check if you're using the certificate-based verification mechanism for the IoT Core registry that the device belongs to.

  • Device metadata: In IoT Core, you can define metadata for each edge device, in the form of key-value pairs. For example, you can define a hardware thumbprint, a serial number, manufacturer information, or any other attribute that is relevant for an edge device. You can define metadata when you add an edge device to an IoT Core registry, or edit an edge device that is already in a registry. Metadata is never sent to or from an edge device through IoT Core. Gather information about the metadata you defined for the edge device.

  • Device state: In IoT Core, each edge device can report information about its state as arbitrary structured or unstructured data. For example, an edge device might report the version of the firmware that it's running. Or, it might report information about its health, according to specific metrics. IoT Core publishes the received information about the device state as messages in a Pub/Sub topic that you configure. Assess how your edge device reports information about its state, and to which Pub/Sub topics IoT Core publishes those messages to. Determine which components of your architecture rely on information about the edge device state.

  • Telemetry events: Each edge device that you add to an IoT Core registry can send telemetry events as arbitrary structured or unstructured data to IoT Core. IoT Core publishes the received telemetry events as messages in a Pub/Sub topic that you configure. Assess how your edge device reports telemetry events, and to which Pub/Sub topics IoT Core publishes those messages to. Determine which components of your architecture rely on telemetry events reported by the edge device.

  • Device configuration: In IoT Core, you can define the configuration of an edge device as arbitrary structured or unstructured data. IoT Core also lets you define updates to the configuration of a device as new versions of such configuration that will then push to the edge device. Assess if the edge device receives configuration from Cloud IoT Core, and gather information about all the configuration versions you defined.

  • Commands: In IoT Core, edge devices can receive commands from IoT Core and then react accordingly to those commands. Assess if your edge devices support reacting to commands coming from IoT Core.

  • Software and configuration updates: During the migration, you might need to update the software components running on the edge device, or the configuration of those components. Assess the update mechanisms that your edge device supports. Determine if the device also supports a rollback mechanism to get it back to a known working state if there are issues and problems during such updates.

  • Downtime: During the migration, backend workloads or other parts of the source environment might be unavailable. Assess if your edge device supports downtimes, its fallback mechanisms, and how it recovers after the downtime.

Build an inventory of your backend workloads that integrate with IoT Core

After building the inventory of your edge devices, you gather information about the backend workloads in your source environment that integrate with Cloud IoT Core. A backend workload can integrate with IoT Core in the following ways:

  • By sending commands to edge devices, and updating the configuration of your edge devices using IoT Core.
  • By subscribing to Pub/Sub topics to which IoT Core publishes messages about edge device telemetry events and device state.
  • By integrating with IoT Core APIs either directly, or using an infrastructure provisioning tool. For example, you might be using Terraform to provision IoT Core registries and devices.

To build the inventory of the backend workloads that integrate with Cloud IoT Core, consider the following for each backend workload:

  • Commands and device configuration: Assess if the backend workload sends commands to edge devices, and if it updates the device configuration. Both actions require an integration with IoT Core APIs.
  • Telemetry events and device state: Assess if the backend workload subscribes to the Pub/Sub topics where IoT Core publishes messages about telemetry events and device state.
  • Integration with other IoT Core APIs: Assess if the backend workload interacts with any other IoT Core APIs, besides the ones to send commands and update device configurations. For example, your backend workload might rely on IoT Core APIs to do the following:

    • Create IoT Core registries and update their configuration.
    • Create IoT Core devices and update their configuration.
    • Gather information about IoT Core registries and devices.
    • Use IoT Core logging metrics and device activity logs.

Categorize your edge devices and backend workloads

After you create the inventories of your edge devices and your backend workload, you categorize the items in each inventory based on their characteristics. This categorization helps you to draft your migration plan and choose which edge devices and backend workloads to migrate first.

To categorize your edge devices, we recommend a categorization based on the kinds of interactions that can happen between edge devices and backend workloads. Consider the following kinds of interactions:

  • When an edge device sends data to backend workloads using telemetry events or information about device state.
  • When backend workloads send directives to edge devices using commands or device configuration updates.

For each of the preceding kinds of interaction, the message types exchanged during interactions of that kind are different. However, the messages have similar purposes. Some devices send data from an edge device to backend workloads, such as telemetry events and information about device state. Some devices send directives from backend workloads to edge devices, such as commands and device configuration updates.

Based on the proposed kinds of interactions, we recommend the following categories for your edge devices:

  • Transmit-only: Edge devices that send telemetry events or information about device state, but don't receive commands or device configuration updates from backend workloads.
  • Receive-only: Edge devices that don't send telemetry events or information about device state, but receive commands or device configuration updates from backend workloads.
  • Receive and transmit: Edge devices that send telemetry events and information about device state, and receive commands or device configuration updates from backend workloads.

To categorize your backend workloads, you can follow an approach that is similar to the one you followed to categorize edge devices. Based on the proposed kinds of interactions, we recommend the following categories for your backend workloads:

  • Receive-only: Backend workloads that receive telemetry events or information about device state from edge devices, but don't send commands or device configuration updates.
  • Send-only: Backend workloads that don't receive telemetry events or information about device state, but send commands or device configuration updates.
  • Send and receive: Backend workloads that receive telemetry events or information about device state from edge devices, and send commands or device configuration updates.

Complete the assessment

After building the inventories, you must complete the following parts of the assessment phase:

After completing these activities, continue reading this document.

Design the architecture of the target environment

After completing the previous assessment activities, you design the architecture for the target environment.

This document focuses on migrating the source environment to the target environment. However, migrating your environment from IoT Core is also an opportunity for you to plan for new features and updates. When you design the architecture of the target environment, think about any limitations that you might have experienced in the source environment. Consider how you'd like to configure the target environment to avoid those limitations. You can also consider any potential new features that you might require in the target environment.

Based on how you categorized your edge devices and backend workloads, you might see the following complementary IoT Core use cases emerging from the assessment of the source environment:

  • Ingestion of data coming from edge devices into a backend running on Google Cloud.
  • Running edge device management backend workloads on Google Cloud.

To reduce the complexity of your migration, we recommend that you focus on the use cases that emerged from the assessment of your source environment. For example, if you're ingesting data coming from edge devices but you're not using any of the IoT Core device management features, we recommend that you focus on designing the target environment. This approach lets you support the data ingestion use case only, with no need to consider the device management use case.

The design of the target environment can vary depending on which of these Cloud IoT Core use cases you implemented in the source environment, and how you want to implement them in the target environment. You must consider the following factors:

  • If you implemented both use cases in the source environment, you can design the target environment to implement both use cases with a single solution. You can also implement the two use cases separately using distinct solutions.
  • If you implement only one of the two use cases in the source environment, you can design the target environment to implement that use case with a single solution.

The following diagram shows a series of example questions to consider when you decide how to design the architecture of the target environment.

Example questions, stated in following text.

The preceding diagram can be summarized as follows:

  • Do you need to both ingest data from edge devices, and manage edge devices?

    • If yes, continue to the next question.
    • If no, continue to the edge device management use case questions.
  • Do you need a single solution to implement both data ingestion and edge device management use cases?

    • If yes, deploy a solution for both data ingestion and edge device management on Google Cloud.
    • If no, deploy an edge device management solution on Google Cloud, and then continue to the data ingestion use case evaluation questions.
  • Do you need to manage edge devices?

    • If yes, deploy an edge device management solution on Google Cloud, and then continue to the data ingestion use case evaluation questions.
    • If no, continue to the data ingestion use case evaluation questions.
  • Do you need to ingest data coming from edge devices?

    • If yes, go to the next question.
    • If no, either you completed the migration, or you don't need to migrate your source environment. In both cases, you can decommission the source environment.
  • What is the preferred communication protocol?

    • If MQTT, deploy an MQTT broker on Google Cloud.
    • If HTTP or gRPC, ingest data coming from edge devices using Pub/Sub.
    • Otherwise, evaluate data ingestion solutions that are compatible with your preferred communication protocols.

When designing the architecture of the target environment, consider the following:

  • Managing any component of the architecture requires knowledge and effort. We recommend that you evaluate how many additional resources you need to account for the target environment.
  • Provisioning many edge devices poses security, scalability, and operational challenges. For more information about provisioning edge devices, refer to Best practices for automatically provisioning and configuring edge and bare metal systems and servers.
  • Using Pub/Sub to ingest data from your edge devices frees you from managing and scaling a distributed messaging platform. If you use Pub/Sub to ingest data coming from your edge devices, consider both Pub/Sub quotas and limits, especially if you need to ingest data from many devices.
  • To authenticate your edge devices against the target environment and manage their identities, we recommend that you assess which authentication methods and credential stores the target environment supports. Consider how they compare to the ones you're using with IoT Core in the source environment.

    After you gather this information, we recommend that you follow the guidance in the IoT backend security guide to design and implement an authentication and identity management mechanism for your edge devices.

Choose which edge devices and the backend workloads to migrate first

After designing the architecture of the target environment, you define the following:

  1. The categories of edge devices and backend workloads to migrate first.
  2. The migration batches (the groups of items to migrate from the source environment to the target environment).

Define the categories of edge devices to migrate first

The categories of edge devices and backend workloads might offer different challenges and difficulties to migrate. One example would be the migration of transmit-only edge devices, which might be easier than migrating receive and transmit edge devices.

To develop a deeper understanding of how to choose which categories of edge devices and backend workloads to migrate first, see Choosing the apps to migrate first.

This section summarizes the considerations that you must make for each edge device category when you decide which to migrate first.

Transmit-only edge devices

These edge devices send telemetry events and information about device state using either MQTT or HTTP.

If the devices use MQTT, you might only need to update their configuration to connect to and authenticate against the MQTT broker in your target environment. You can keep publishing telemetry events and information about device state through the MQTT broker in the target environment. In some cases, you might not have an MQTT broker in your target environment, and need to migrate to a different kind of target environment, such as a third-party solution. In this case, you need to assess the capabilities and the integration interfaces that the solution provides. You can then design and implement a suitable migration plan.

If the devices use HTTP, you might need to update their configuration to connect to and authenticate against the target environment. You might also need to refactor the semantics of how the devices communicate to account for the differences in your target environment when compared to using IoT Core APIs. For example, if you're using Pub/Sub in the target environment, you might migrate from using IoT Core APIs to publish messages to Pub/Sub topics to using Pub/Sub APIs for the same purpose. In some cases, you might not use Pub/Sub in your target environment, and therefore need to migrate to a different kind of target environment, such as a third-party solution. In this case, you must assess the capabilities and the integration interfaces that the third-party solution provides to design and implement a suitable migration plan.

Receive-only edge devices

These edge devices receive commands using MQTT and configuration updates using either MQTT or HTTP. IoT Core doesn't support the use of HTTP to send commands.

If the devices receive commands and configuration updates using MQTT, similar considerations as the previous edge device category apply. To migrate this category of edge devices, you update the configuration of the edge devices to connect to and authenticate against the MQTT broker in your target environment. You keep subscribing to MQTT topics where IoT Core publishes commands and device configuration updates. In some cases, you might not have an MQTT broker in your target environment, and need to migrate to a different kind of target environment, such as a third-party solution. In this case, you need to assess the capabilities and the integration interfaces that the solution provides to design and implement a suitable migration plan.

If the devices receive configuration updates using HTTP, similar