Migra entornos desde IoT Core

Last reviewed 2023-02-01 UTC

Google anunció la baja de IoT Core. El objetivo de este documento es ayudarte a diseñar e implementar un plan de migración desde un entorno basado en IoT Core a un entorno nuevo que no depende de IoT Core para ninguno de los siguientes elementos:

  • Autenticación de dispositivos perimetrales
  • Administración de dispositivos perimetrales
  • Comunicación entre tus dispositivos perimetrales y Google Cloud

En el documento, también se proporciona orientación si estás evaluando la posibilidad de migrar después de la baja de IoT Core y deseas explorar cómo podría ser una migración.

Este documento es parte de una serie de documentos que proporcionan información sobre las arquitecturas de IoT en Google Cloud y la migración desde IoT Core. Los otros documentos de esta serie incluyen lo siguiente:

La carga de trabajo que se migrará

En este documento, se supone que las cargas de trabajo que deseas migrar de IoT Core tienen las siguientes partes:

  • Una parte que se ejecuta en dispositivos perimetrales (implementadas en los perímetros de tu entorno y junto a los datos que deseas procesar)
  • Un backend que se ejecuta en Google Cloud

En el siguiente diagrama, se muestra la arquitectura de una carga de trabajo típica que usa IoT Core. En esta arquitectura, Cloud IoT integra dispositivos perimetrales que tienen un backend que se ejecuta en Google Cloud.

Flujo de eventos de dispositivos perimetrales a Cloud IoT (se resume en el siguiente texto).

El diagrama anterior se puede resumir de la siguiente manera:

Para planificar tu migración de manera eficaz, te recomendamos que realices una evaluación a fin de comprender completamente la arquitectura de tu entorno de origen. En este caso, el entorno de origen hace referencia a tu entorno actual basado en IoT Core.

En este documento, se supone que puedes actualizar la configuración y los componentes de software que se ejecutan en tus dispositivos perimetrales para tu migración. En algunos casos, este enfoque puede ser inviable. Por ejemplo, es posible que tus dispositivos perimetrales o tus procesos de implementación no admitan este caso práctico. En este caso, te recomendamos que planees retirar los dispositivos perimetrales que no admiten actualizaciones. Si deseas obtener más información sobre el diseño y la implementación de procesos automatizados de aprovisionamiento y configuración de dispositivos perimetrales, consulta Prácticas recomendadas para aprovisionar y configurar de forma automática sistemas y servidores perimetrales y de equipos físicos.

Diseña la migración

Para migrar el entorno basado en IoT Core, te recomendamos que sigas el framework de migración descrito en Migración a Google Cloud.

En el siguiente diagrama, se describe la ruta del recorrido de tu migración.

Ruta de migración con cuatro fases

Como se muestra en el diagrama anterior, este recorrido tiene cuatro fases:

  1. Evaluar: En esta fase, evalúas tu entorno de origen, evalúas las cargas de trabajo y los dispositivos perimetrales que deseas migrar fuera de Cloud IoT Core.
  2. Planificar: En esta fase, debes crear la infraestructura básica en Google Cloud. Para ello, tienes que aprovisionar la jerarquía de recursos y configurar el acceso a la red.
  3. Implementar: En esta fase, debes implementar la solución nueva para usarla en lugar de IoT Core y migrar tus dispositivos perimetrales a la solución nueva.
  4. Optimizar: En esta fase, debes optimizar tu entorno de destino. En este caso, el entorno de destino hace referencia al entorno al que migras que no se basa en IoT Core.

Evalúa el entorno de origen y las cargas de trabajo

En la fase de evaluación, debes recopilar información sobre tu entorno de origen, los dispositivos perimetrales y el uso de IoT Core en tu organización. Esta información te ayuda a diseñar un plan de migración y a garantizar que tengas los recursos que necesitas para la migración y para tu entorno de destino.

En la fase de evaluación, debes realizar las siguientes tareas:

  1. Compila un inventario de los dispositivos perimetrales que registraste en Cloud IoT Core.
  2. Crea un inventario de las cargas de trabajo de backend que se integran a Cloud IoT Core.
  3. Categoriza los dispositivos perimetrales y las cargas de trabajo de backend.
  4. Experimenta y diseña pruebas de concepto
  5. Calcula el costo total de propiedad
  6. Diseña la arquitectura del entorno de destino.
  7. Elige qué dispositivos perimetrales y cargas de trabajo de backend se migrarán primero

Al final de la fase de evaluación, tienes dos inventarios: un inventario para los dispositivos perimetrales y otro para las cargas de trabajo de backend.

Para evitar incoherencias, recomendamos que detengas la implementación de dispositivos perimetrales y cargas de trabajo de backend nuevos antes de compilar estos inventarios. También te recomendamos que no implementes dispositivos perimetrales nuevos y cargas de trabajo en segundo plano después de crear los inventarios.

Crea un inventario de tus dispositivos perimetrales

Para determinar el alcance de la migración y diseñar tu plan de migración, debes saber cuántos dispositivos perimetrales existen en tu entorno de origen. También debes comprender cómo interactúan los dispositivos con IoT Core y si puedes clasificarlos por características comunes, comportamiento, propósito o dependencias.

Cada dispositivo perimetral que registras en IoT Core pertenece a un registro de IoT Core. El primer paso para compilar el inventario de tus dispositivos perimetrales es enumerar los registros de IoT Core que creaste. Luego, recopilas información sobre los dispositivos perimetrales registrados en cada registro.

A fin de compilar el inventario de tus dispositivos perimetrales, considera la siguiente información para cada dispositivo perimetral y cómo se integra el dispositivo en IoT Core:

  • Identificadores: Recopila la siguiente información sobre los identificadores de IoT Core del dispositivo perimetral:

    • El identificador definido por el usuario
    • El ID no editable definido por el servidor que IoT Core genera automáticamente cuando registras un dispositivo perimetral en IoT Core.
    • El nombre del recurso que identifica el dispositivo perimetral de manera inequívoca mediante el identificador del registro de IoT Core en el que registraste el dispositivo perimetral

  • Estado de la implementación: Evalúa el estado actual de la implementación del dispositivo perimetral. Por ejemplo, el dispositivo perimetral puede estar en uno de los siguientes estados:

    • Aún no se fabrica o se fabrica en este momento
    • Listo para implementarse, pero aún no registrado en IoT Core
    • Ya se implementó en su sitio de destino y está registrado en IoT Core

  • Tipo de dispositivo de IoT Core: Evalúa el tipo de dispositivo de IoT Core. Cada dispositivo perimetral que registras en IoT Core puede actuar de dos maneras. Puede ser un cliente que se conecta directamente a IoT Core. O bien, puede ser una puerta de enlace para los clientes que no puedes o no quieres conectarte directamente a IoT Core.

  • Protocolo de comunicación: IoT Core admite dos protocolos para comunicarse con dispositivos perimetrales: HTTP y MQTT. Evalúa qué protocolo usan tus dispositivos perimetrales para comunicarse con IoT Core. Para el protocolo MQTT, también debes determinar la calidad de servicio en la que se basan tus dispositivos perimetrales y las cargas de trabajo de backend.

  • Credenciales: IoT Core autentica dispositivos perimetrales mediante un par de claves y tokens de corta duración generados con ese par de claves. De forma opcional, puede verificar la firma de la parte pública del par de claves mediante un método de verificación basado en certificados. Evalúa cómo está configurada la autenticación del dispositivo perimetral. Comprueba si usas el mecanismo de verificación basado en certificados para el registro de IoT Core al que pertenece el dispositivo.

  • Metadatos del dispositivo: En IoT Core, puedes definir metadatos para cada dispositivo perimetral, en forma de pares clave-valor. Por ejemplo, puedes definir una huella digital del hardware, un número de serie, información del fabricante o cualquier otro atributo que sea relevante para un dispositivo perimetral. Puedes definir metadatos cuando agregas un dispositivo perimetral a un registro de IoT Core o edita un dispositivo perimetral que ya está en un registro. Los metadatos nunca se envían desde o hacia un dispositivo perimetral a través de IoT Core. Recopila información sobre los metadatos que definiste para el dispositivo perimetral.

  • Estado del dispositivo: En IoT Core, cada dispositivo perimetral puede notificar información sobre su estado como datos estructurados o no estructurados arbitrarios. Por ejemplo, un dispositivo perimetral puede informar la versión del firmware que se está ejecutando. O puede notifcar información sobre su estado, de acuerdo con métricas específicas. IoT Core publica la información recibida sobre el estado del dispositivo como mensajes en un tema de Pub/Sub que configuras. Evalúa cómo tu dispositivo perimetral notifica información sobre su estado y a qué temas de Pub/Sub publica IoT Core. Determina qué componentes de tu arquitectura dependen de la información sobre el estado del dispositivo perimetral.

  • Eventos de telemetría: Cada dispositivo perimetral que agregas a un registro de IoT Core puede enviar eventos de telemetría como datos estructurados o no estructurados arbitrarios a IoT Core. IoT Core publica los eventos de telemetría recibidos como mensajes en un tema de Pub/Sub que configuras. Evalúa cómo tu dispositivo perimetral informa los eventos de telemetría y a qué temas de Pub/Sub publica IoT Core. Determina qué componentes de tu arquitectura dependen de los eventos de telemetría que informa el dispositivo perimetral.

  • Configuración del dispositivo: En IoT Core, puedes definir la configuración de un dispositivo perimetral como datos estructurados o no estructurados arbitrarios. IoT Core también te permite definir actualizaciones de la configuración de un dispositivo como versiones nuevas de esa configuración que luego se enviarán al dispositivo perimetral. Evalúa si el dispositivo perimetral recibe la configuración de Cloud IoT Core y recopila información sobre todas las versiones de configuración que definiste.

  • Comandos: en IoT Core, los dispositivos perimetrales pueden recibir comandos de IoT Core y, luego, reaccionar según esos comandos. Evalúa si los dispositivos perimetrales admiten la reacción a comandos que provienen de IoT Core.

  • Actualizaciones de software y configuración: Durante la migración, es posible que debas actualizar los componentes de software que se ejecutan en el dispositivo perimetral o la configuración de esos componentes. Evalúa los mecanismos de actualización que admite tu dispositivo perimetral. Determina si el dispositivo también admite un mecanismo de reversión para volver a un estado de trabajo conocido si hay problemas durante estas actualizaciones.

  • Tiempo de inactividad: durante la migración, es posible que las cargas de trabajo de backend o cualquier otra parte del entorno de origen no estén disponibles. Evalúa si el dispositivo perimetral admite tiempos de inactividad, sus mecanismos de resguardo y cómo se recupera después del tiempo de inactividad.

Crea un inventario de tus cargas de trabajo de backend que se integran a IoT Core

Después de compilar el inventario de tus dispositivos perimetrales, recopila información sobre las cargas de trabajo de backend en tu entorno de origen que se integran a Cloud IoT Core. Una carga de trabajo de backend puede integrarse en IoT Core de las siguientes maneras:

  • Mediante el envío de comandos a dispositivos perimetrales y la actualización de la configuración de tus dispositivos perimetrales mediante IoT Core.
  • Cuando se suscribe a temas de Pub/Sub en los que IoT Core publica mensajes sobre eventos de telemetría de dispositivos perimetrales y estados de dispositivos.
  • Mediante la integración con las API de IoT Core directamente o con una herramienta de aprovisionamiento de infraestructura Por ejemplo, es posible que uses Terraform para aprovisionar registros y dispositivos de IoT Core.

A fin de compilar el inventario de las cargas de trabajo de backend que se integran a Cloud IoT Core, considera lo siguiente para cada carga de trabajo de backend:

  • Comandos y configuración del dispositivo: Evalúa si la carga de trabajo del backend envía comandos a dispositivos perimetrales y si actualiza la configuración del dispositivo. Ambas acciones requieren una integración con las APIs de IoT Core.
  • Eventos de telemetría y estado del dispositivo: Evalúa si la carga de trabajo del backend se suscribe a los temas de Pub/Sub en los que IoT Core publica mensajes sobre eventos de telemetría y estado del dispositivo.

  • Integración en otras APIs de IoT Core: Evalúa si la carga de trabajo de backend interactúa con cualquier otra API de IoT Core, además de las que envían comandos y actualizan configuraciones de dispositivos. Por ejemplo, tu carga de trabajo de backend podría depender de las APIs de IoT Core para hacer lo siguiente:

    • Crea registros de IoT Core y actualiza su configuración.
    • Crea dispositivos de IoT Core y actualiza su configuración.
    • Recopila información sobre los registros y dispositivos de IoT Core.
    • Usa las métricas de registro de IoT Core y los registros de actividad del dispositivo.

Categoriza tus dispositivos perimetrales y las cargas de trabajo de backend

Después de crear los inventarios de tus dispositivos perimetrales y tu carga de trabajo de backend, clasifica los elementos en cada inventario según sus características. Esta categorización te ayuda a redactar tu plan de migración y elegir qué dispositivos perimetrales y cargas de trabajo de backend se migrarán primero.

Para clasificar tus dispositivos perimetrales, recomendamos una categorización basada en los tipos de interacciones que pueden ocurrir entre dispositivos perimetrales y cargas de trabajo de backend. Considera los siguientes tipos de interacciones:

  • Cuando un dispositivo perimetral envía datos a cargas de trabajo de backend mediante eventos de telemetría o información sobre el estado del dispositivo.
  • Cuando las cargas de trabajo de backend envían directivas a dispositivos perimetrales mediante comandos o actualizaciones de configuración del dispositivo.

Para cada uno de los tipos de interacción anteriores, los tipos de mensajes intercambiados durante las interacciones de ese tipo son diferentes. Sin embargo, los mensajes tienen propósitos similares. Algunos dispositivos envían datos desde un dispositivo perimetral a cargas de trabajo de backend, como los eventos de telemetría y la información sobre el estado del dispositivo. Algunos dispositivos envían directivas desde cargas de trabajo de backend a dispositivos perimetrales, como comandos y actualizaciones de configuración de dispositivos.

Según los tipos de interacciones propuestos, recomendamos las siguientes categorías para tus dispositivos perimetrales:

  • Solo para transmisión: Dispositivos de Edge que envían eventos de telemetría o información sobre el estado del dispositivo, pero que no reciben comandos ni actualizaciones de configuración del dispositivo de las cargas de trabajo de backend.
  • Solo recepción: Dispositivos perimetrales que no envían eventos o telemetría sobre el estado del dispositivo, pero reciben comandos o actualizaciones de configuración del dispositivo a partir de cargas de trabajo de backend.
  • Recibe y transmite: Dispositivos perimetrales que envían información y eventos de telemetría sobre el estado del dispositivo y reciben comandos o actualizaciones de configuración del dispositivo desde cargas de trabajo de backend.

A fin de clasificar las cargas de trabajo de backend, puedes seguir un enfoque similar al que seguiste para clasificar los dispositivos perimetrales. Según los tipos de interacciones propuestos, recomendamos las siguientes categorías para tus cargas de trabajo de backend:

  • Solo recepción: Cargas de trabajo de backend que reciben eventos o telemetría de información sobre el estado del dispositivo desde dispositivos perimetrales, pero no envían comandos ni actualizaciones de configuración del dispositivo.
  • Solo envío: Cargas de trabajo de backend que no reciben eventos de telemetría ni información sobre el estado del dispositivo, pero envían comandos o actualizaciones de configuración del dispositivo.
  • Envío y recepción: Cargas de trabajo de backend que reciben eventos o información de telemetría sobre el estado del dispositivo desde dispositivos perimetrales y envían comandos o actualizaciones de configuración del dispositivo.

Completa la evaluación

Después de compilar los inventarios, debes completar las siguientes partes de la fase de evaluación:

Después de completar estas actividades, continúa leyendo este documento.

Diseña la arquitectura del entorno de destino

Después de completar las actividades de evaluación anteriores, diseña la arquitectura para el entorno de destino.

Este documento se centra en la migración del entorno de origen al entorno de destino. Sin embargo, migrar el entorno de IoT Core también es una oportunidad para que planifiques funciones y actualizaciones nuevas. Cuando diseñes la arquitectura del entorno de destino, piensa en las limitaciones que puedas haber experimentado en el entorno de origen. Considera cómo deseas configurar el entorno de destino para evitar esas limitaciones. También puedes considerar cualquier posible función nueva que puedas necesitar en el entorno de destino.

Según cómo categorizaste tus dispositivos perimetrales y las cargas de trabajo de backend, es posible que veas los siguientes casos de uso complementarios de IoT Core que surgen de la evaluación del entorno de origen:

  • Transferencia de datos que provienen de dispositivos perimetrales a un backend que se ejecuta en Google Cloud.
  • Ejecución de cargas de trabajo de backend de administración de dispositivos perimetrales en Google Cloud.

Para reducir la complejidad de la migración, te recomendamos que te enfoques en los casos de uso que surgieron de la evaluación del entorno de origen. Por ejemplo, si transfieres datos desde dispositivos perimetrales, pero no usas ninguna de las funciones de administración de dispositivos de IoT Core, te recomendamos que te enfoques en el diseño del entorno de destino. Este enfoque te permite admitir solo el caso práctico de transferencia de datos, sin necesidad de considerar el caso de uso de administración de dispositivos.

El diseño del entorno de destino puede variar según cuáles de estos casos prácticos de Cloud IoT Core se hayan implementado en el entorno de origen y cómo deseas implementarlos en el entorno de destino. Debes tener en cuenta los siguientes factores:

  • Si implementaste ambos casos prácticos en el entorno de origen, puedes diseñar el entorno de destino para implementar ambos casos prácticos con una sola solución. También puedes implementar los dos casos prácticos por separado mediante soluciones distintas.
  • Si implementas solo uno de los dos casos prácticos en el entorno de origen, puedes diseñar el entorno de destino para implementar ese caso práctico con una sola solución.

En el siguiente diagrama, se muestra una serie de preguntas de ejemplo para tener en cuenta cuando decidas cómo diseñar la arquitectura del entorno de destino.

Preguntas de ejemplo, que se indican en el siguiente texto.

El diagrama anterior se puede resumir de la siguiente manera:

  • ¿Necesitas transferir datos desde dispositivos perimetrales y administrarlos?

    • Si es así, continúa con la siguiente pregunta.
    • Si no es así, continúa con las preguntas sobre casos prácticos de administración de dispositivos perimetrales.

  • ¿Necesitas una sola solución para implementar la transferencia de datos y los casos prácticos de administración de dispositivos perimetrales?

    • Si es así, implementa una solución para la transferencia de datos y la administración de dispositivos perimetrales en Google Cloud.
    • Si no es así, implementa una solución de administración de dispositivos perimetrales en Google Cloud y, luego, continúa con las preguntas de evaluación de casos prácticos de transferencia de datos.

  • ¿Necesitas administrar dispositivos perimetrales?

    • Si es así, implementa una solución de administración de dispositivos perimetrales en Google Cloud y, luego, continúa con las preguntas de evaluación de casos prácticos de transferencia de datos.
    • Si no es así, continúa con las preguntas de evaluación de casos prácticos de transferencia de datos.

  • ¿Necesitas transferir datos provenientes de dispositivos perimetrales?

    • Si es así, pasa a la siguiente pregunta.
    • Si no es así, ya completaste la migración o no necesitas migrar tu entorno de origen. En ambos casos, puedes dar de baja el entorno de origen.

  • ¿Cuál es el protocolo de comunicación preferido?

    • Si es MQTT, implementa un agente de MQTT en Google Cloud.
    • Si es HTTP o gRPC, los datos de transferencia que provienen de dispositivos perimetrales usan Pub/Sub
    • De lo contrario, evalúa las soluciones de transferencia de datos que son compatibles con tus protocolos de comunicación preferidos.

Cuando diseñes la arquitectura del entorno de destino, ten en cuenta lo siguiente:

  • Administrar cualquier componente de la arquitectura requiere conocimiento y esfuerzo. Te recomendamos que evalúes cuántos recursos adicionales necesitas para dar cuenta del entorno de destino.
  • El aprovisionamiento de muchos dispositivos perimetrales representa desafíos de seguridad, escalabilidad y operación. Si deseas obtener más información sobre el aprovisionamiento de dispositivos perimetrales, consulta Prácticas recomendadas para aprovisionar y configurar de forma automática sistemas y servidores perimetrales y de equipos físicos.
  • El uso de Pub/Sub para transferir datos desde tus dispositivos perimetrales te libera de administrar y escalar una plataforma de mensajería distribuida. Si usas Pub/Sub para transferir datos provenientes de tus dispositivos perimetrales, ten en cuenta las cuotas y los límites de Pub/Sub, en especial, si necesitas transferir datos desde muchos dispositivos.

  • Para autenticar tus dispositivos perimetrales en el entorno de destino y administrar sus identidades, te recomendamos que evalúes qué métodos de autenticación y almacenes de credenciales admite el entorno de destino. Considera cómo se comparan con los que usas con IoT Core en el entorno de origen.

    Después de recopilar esta información, te recomendamos que sigas las instrucciones de la guía de seguridad de backend de IoT para diseñar e implementar un mecanismo de autenticación y administración de identidades en tus dispositivos perimetrales.

Elige qué dispositivos perimetrales y cargas de trabajo de backend se migrarán primero

Después de diseñar la arquitectura del entorno de destino, define lo siguiente:

  1. Las categorías de los dispositivos perimetrales y las cargas de trabajo de backend que se migrarán primero.
  2. Los lotes de migración (los grupos de elementos que se migrarán del entorno de origen al entorno de destino).

Define las categorías de los dispositivos perimetrales que migrarás primero

Las categorías de los dispositivos perimetrales y las cargas de trabajo de backend pueden ofrecer desafíos y dificultades diferentes para la migración. Un ejemplo sería la migración de dispositivos perimetrales de solo transmisión, que pueden ser más fáciles que migrar los dispositivos perimetrales de recepción y transmisión.

Para comprender mejor cómo elegir qué categorías de dispositivos perimetrales y cargas de trabajo de backend se migrarán primero, consulta Elige las apps que se migrarán primero.

En esta sección, se resumen las consideraciones que debes tener en cuenta para cada categoría de dispositivo perimetral cuando decidas cuál migrar primero.

Dispositivos perimetrales de solo transmisión

Estos dispositivos perimetrales envían eventos de telemetría e información sobre el estado del dispositivo mediante MQTT o HTTP.

Si los dispositivos usan MQTT, es posible que solo debas actualizar su configuración para conectarte y autenticarte en el agente de MQTT en tu entorno de destino. Puedes seguir publicando eventos y telemetría de telemetría sobre el estado del dispositivo a través del agente de MQTT en el entorno de destino. En algunos casos, es posible que no tengas un agente de MQTT en tu entorno de destino y necesites migrar a un tipo diferente de entorno de destino, como una solución de terceros. En este caso, debes evaluar las capacidades y las interfaces de integración que proporciona la solución. Luego, puedes diseñar y, luego, implementar un plan de migración adecuado.

Si los dispositivos usan HTTP, es posible que debas actualizar su configuración para conectarte al entorno de destino y autenticarse en él. Es posible que también debas refactorizar la semántica sobre cómo los dispositivos se comunican para dar cuenta de las diferencias en tu entorno de destino en comparación con el uso de las APIs de IoT Core. Por ejemplo, si usas Pub/Sub en el entorno de destino, puedes migrar de las API de IoT Core a fin de publicar mensajes en temas de Pub/Sub y usar las APIs de Pub/Sub para el mismo propósito. En algunos casos, es posible que no uses Pub/Sub en el entorno de destino y, por lo tanto, necesites migrar a un tipo diferente de entorno de destino, como una solución de terceros. En este caso, debes evaluar las capacidades y las interfaces de integración que proporciona la solución de terceros para diseñar e implementar un plan de migración adecuado.

Dispositivos perimetrales de solo recepción

Estos dispositivos perimetrales reciben comandos mediante MQTT y actualizaciones de configuración mediante MQTT o HTTP. IoT Core no admite el uso de HTTP para enviar comandos.

Si los dispositivos reciben comandos y actualizaciones de configuración mediante MQTT, se aplican consideraciones similares a las de la categoría de dispositivo perimetral anterior. Si quieres migrar esta categoría de dispositivos perimetrales, actualiza la configuración de los dispositivos perimetrales para conectarte y autenticarte en el agente de MQTT en tu entorno de destino. Continúas suscrito a los temas de MQTT en los que IoT Core publica comandos y actualizaciones de configuración de dispositivos. En algunos casos, es posible que no tengas un agente de MQTT en tu entorno de destino y necesites migrar a un tipo diferente de entorno de destino, como una solución de terceros. En este caso, debes evaluar las capacidades y las interfaces de integración que proporciona la solución para diseñar e implementar un plan de migración adecuado.

Si los dispositivos reciben actualizaciones de configuración mediante HTTP, se aplican consideraciones similares a las de la categoría de dispositivo perimetral anterior. A fin de migrar esta categoría de dispositivos perimetrales, es posible que debas actualizar la configuración para conectarse al entorno de destino y autenticarse. Para recibir actualizaciones de configuración, es posible que también debas refactorizar la semántica de la comunicación a fin de tener en cuenta las diferencias en tu entorno de destino, en comparación con el uso de las APIs de IoT Core. Por ejemplo, si migras a un tipo de entorno de destino diferente, como una solución de terceros, debes evaluar las capacidades y las interfaces de integración que proporciona la solución para diseñar e implementar un plan de migración adecuado.

Recibe y transmite dispositivos perimetrales

Estos dispositivos perimetrales pueden ser más difíciles de migrar porque son consumidores de datos que provienen de cargas de trabajo de backend y productores de datos que reciben los dispositivos perimetrales. En este caso, se aplican las consideraciones para migrar las categorías de dispositivos perimetrales analizadas antes, por lo que debes tener especial cuidado para manejar la migración de esta categoría de carga de trabajo de backend.

Después de elegir qué categorías de dispositivos perimetrales migrarás primero, debes elegir qué categorías de cargas de trabajo de backend migrar primero.

Cargas de trabajo de backend de solo recepción

Estas cargas de trabajo de backend están separadas de dispositivos perimetrales que producen eventos o telemetría sobre el estado del dispositivo, por lo que, por los siguientes motivos, puede ser relativamente simple migrar:

  • Las cargas de trabajo de backend se suscriben a temas de Pub/Sub. Por este motivo, los dispositivos no necesitan saber sobre los productores de esos datos para consumirlo. Es posible que no necesites actualizar la configuración del software que se ejecuta en tus dispositivos perimetrales o este.
  • Las cargas de trabajo de backend no envían comandos ni actualizaciones de configuración del dispositivo a los dispositivos perimetrales. Por lo tanto, no debes tener en cuenta este caso de uso durante la migración de estas cargas de trabajo de backend.
  • Puedes conservar los temas de Pub/Sub existentes para publicar o consumir mensajes. En ese caso, las cargas de trabajo de backend pueden permanecer suscritas a los temas de Pub/Sub existentes si tu entorno de destino continúa reenviando eventos de telemetría y la información sobre el estado del dispositivo a esos temas de Pub/Sub.

Cargas de trabajo de backend de solo envío

Estas cargas de trabajo de backend requieren una evaluación completa a fin de comprender cómo interactúan con los dispositivos perimetrales cuando se envían comandos y actualizaciones de configuración del dispositivo, y cómo migrarlos al entorno de destino. Por ejemplo, si migras a un entorno de destino con un agente de MQTT, esas cargas de trabajo de backend pueden migrar desde el uso de las APIs de IoT Core para enviar comandos o actualizaciones de configuración del dispositivo a fin de publicar mensajes a través de MQTT. Es posible que, en algunos casos, no debas realizar una actualización de software o configuración en los dispositivos perimetrales. Por ejemplo, si las cargas de trabajo de backend publican comandos y actualizaciones de configuración en el mismo formato y en los mismos temas de MQTT en los que IoT Core publica mensajes sobre comandos y actualizaciones de configuración de dispositivos en tu entorno de origen. Si migras a un tipo diferente de entorno de destino, como una solución de terceros, debes evaluar las capacidades y las interfaces de integración que proporciona la solución para diseñar e implementar una solución adecuada plan de migración.

Envía y recibe cargas de trabajo de backend

Estas cargas de trabajo de backend pueden ser las más difíciles de migrar porque son consumidores de datos provenientes de dispositivos perimetrales y productores de datos que reciben los dispositivos perimetrales. En este caso, se aplican las consideraciones para migrar las categorías de cargas de trabajo de backend que se analizaron antes, por lo que debes tener especial cuidado para manejar la migración de esta categoría de carga de trabajo de backend.

Define lotes de migración

Para reducir los riesgos y la complejidad de migrar una gran cantidad de elementos en un solo lote, divide los elementos que se migrarán en cada categoría en lotes de migración. Para planificar lotes de migración, debes hacer lo siguiente:

  1. Diseña lotes de migración mediante la agrupación de los elementos homogéneos: Para agrupar los elementos que se migrarán en lotes, te recomendamos que elijas un conjunto de criterios para que los elementos de un lote de migración compartan características comunes. Por ejemplo, puedes agrupar dispositivos perimetrales en lotes según lo siguiente:

    • La región de implementación
    • El registro de IoT Core en el que están registrados los dispositivos
    • Si hay un conjunto significativo de metadatos de dispositivos de IoT Core
    • El estado de implementación de los dispositivos

  2. Decide el tamaño de cada lote de migración: Para cada categoría de elementos que se migrará, te recomendamos que planifiques los primeros lotes de migración en esa categoría para que sean relativamente pequeños. Aumentas el tamaño de los lotes a medida que obtienes experiencia y un impulso durante la migración.

  3. Evalúa si los lotes de migración necesitan estrategias ad-hoc: Según cómo hayas agrupado los elementos que deseas migrar en lotes de migración, la estrategia de migración que se debe aplicar para un lote de migración determinado puede depender de las características de los elementos en ese lote. Por ejemplo, para migrar dispositivos perimetrales agrupados por estado de implementación, debes tener en cuenta las siguientes consideraciones:

    • Si tus dispositivos no están aún o se están fabricando, puedes indicarle al fabricante que actualice su configuración y el software para migrarlos al entorno de destino.
    • Si tus dispositivos están listos para implementarse, pero aún no se registraron en IoT Core, puedes indicarle al implementador que recupere esos dispositivos perimetrales. Luego, puedes actualizar su configuración y el software para migrarlos al entorno de destino.
    • Si tus dispositivos ya están implementados en su sitio de destino y están registrados en IoT Core, puedes actualizar su configuración y el software para migrarlos al entorno de destino, ya sea de forma remota o en las instalaciones.

Planifica y compila tu base

En la fase de planificación y compilación, aprovisionarás y configurarás la infraestructura de nube y los servicios compatibles con tus cargas de trabajo en Google Cloud como se indica a continuación:

  1. Compila una jerarquía de recursos.
  2. Configura la administración de identidades y accesos
  3. Configura la facturación.
  4. Configura la conectividad de red.
  5. Endurece tu seguridad.
  6. Configura la supervisión y las alertas.

Si deseas obtener orientación para compilar la infraestructura de nube y los servicios compatibles con tus cargas de trabajo y sus dependencias, consulta Migración a Google Cloud: construye tu base. Sigue estos lineamientos a fin de crear una base para tus entornos. Luego, continúa con las actividades descritas en las siguientes secciones de este documento.

Migra los dispositivos perimetrales y las cargas de trabajo de backend

Después de crear la base para tu entorno de destino, debes realizar las siguientes acciones a fin de migrar tus dispositivos perimetrales y cargas de trabajo de backend al entorno de destino.

  1. Aprovisiona y configura recursos para implementar la arquitectura del entorno de destino: Como primer paso del proceso de migración, debes crear y configurar la infraestructura de la plataforma nueva.
  2. Migra dispositivos perimetrales y cargas de trabajo de backend al entorno de destino: Después de verificar que el entorno de destino está listo, migra las cargas de trabajo de backend y los dispositivos perimetrales al entorno de destino. Según la arquitectura de tu entorno de destino y tus casos prácticos, puede haber diferentes enfoques para la migración. En este documento, se analiza una estrategia de migración de dos pasos que permite que los entornos de origen y destino coexistan durante un período. Este enfoque significa que, si hay fallas durante la migración, puedes revertir al entorno de origen.
  3. Retirar de servicio el entorno de origen: después de verificar que el entorno de destino está en funcionamiento, debes retirar el servicio de origen.

Aprovisiona y configura recursos para la arquitectura del entorno de destino

En esta fase, debes aprovisionar y configurar el entorno de destino. Como se describe en Diseña la arquitectura del entorno de destino, la arquitectura del entorno de destino se puede resumir de la siguiente manera:

  • Un agente de MQTT que se ejecuta en Google Cloud: ejecutas un agente de MQTT en Google Cloud y reenvías eventos de telemetría e información sobre el estado del dispositivo desde el agente de MQTT a las cargas de trabajo de backend. Tus cargas de trabajo de backend publican comandos y controles en el tema MQTT.
  • Pub/Sub: Tus dispositivos perimetrales publican información y eventos de telemetría sobre el estado del dispositivo en Pub/Sub y reciben comandos de Pub/Sub.
  • Una plataforma de administración de dispositivos y transferencia de datos de terceros: Configuras una solución de terceros para los eventos de telemetría y la información sobre la transferencia de estado de dispositivos y la administración de dispositivos.

Para obtener más información sobre cada arquitectura, consulta Arquitecturas de dispositivos conectados en Google Cloud.

Migra dispositivos perimetrales y cargas de trabajo de backend al entorno de destino

Después de aprovisionar y configurar los recursos en tu entorno de destino, migras los dispositivos perimetrales y las cargas de trabajo de backend al entorno de destino. En esta sección, migrarás los dispositivos perimetrales y las cargas de trabajo de backend del entorno de origen al entorno de destino. El entorno de origen y el de destino coexisten hasta que retiras el entorno de origen.

Para reducir los tiempos de inactividad, el proceso de migración tiene las siguientes fases:

  1. Supervisar los entornos de origen y de destino.
  2. Migrar la información de metadatos del dispositivo perimetral del entorno de origen al entorno de destino Esto incluye las credenciales del dispositivo, la configuración del dispositivo y el estado del dispositivo.
  3. Actualizar los dispositivos perimetrales para conectarse al entorno de origen y de destino.
  4. Migrar las cargas de trabajo de backend del entorno de origen al entorno de destino.
  5. Actualizar los dispositivos perimetrales para conectarse solo al entorno de origen.

Recomendamos que supervises el entorno de origen y el de destino durante cada fase de migración y que verifiques los resultados de cada fase antes de pasar a la siguiente fase.

Además de supervisar el entorno, es posible que desees ingresar pruebas en caja negra para verificar si el entorno funciona como se espera. Un ejemplo de esta prueba sería un caso práctico en el que tu carga de trabajo de backend envía una notificación por correo electrónico a los operadores cuando detecta un evento específico, como una temperatura de más de 50 grados Celsius. Puedes crear un caso de prueba que tenga datos de telemetría para una temperatura superior a 50 grados y probar si la carga de trabajo de backend envía un correo electrónico a los operadores.

Supervisa los entornos de origen y destino

Para supervisar los entornos de origen y destino, te recomendamos que consideres las siguientes métricas:

  • Recuento de dispositivos activos: La cantidad de dispositivos que enviaron datos a IoT Core recientemente.
  • Recuento de errores de comunicación del dispositivo: La cantidad de errores que encontraron las cargas de trabajo de backend cuando se comunican con dispositivos perimetrales, agrupados por tipo de error, en un período determinado. Esta métrica es útil para comprender si las cargas de trabajo de backend tienen problemas con la comunicación con dispositivos perimetrales.
  • Recuento de operaciones del dispositivo: La cantidad de operaciones realizadas por dispositivos perimetrales, como las solicitudes de conexión o desconexión, la publicación de mensajes, agrupadas por tipo de operación, en un período determinado. Esta métrica te ayuda a comprender si los dispositivos perimetrales se ejecutan como se espera. Por ejemplo, si aumentan los valores de recuento de errores del dispositivo y de recuento de operaciones del dispositivo, es posible que el entorno tenga problemas para enviar mensajes a los dispositivos perimetrales.
  • Recuento de bytes recibidos: La cantidad de bytes recibidos de dispositivos perimetrales en un período determinado. Esta métrica te ayuda a razonar sobre las estadísticas de tráfico de entrada de la red.
  • Recuento de bytes enviados: El recuento delta de la cantidad de bytes enviados a dispositivos perimetrales. Esta métrica te ayuda a entender las estadísticas del tráfico de salida de red.
  • Capacidad de procesamiento de mensajes: La cantidad de mensajes que las cargas de trabajo de backend procesaron en un período determinado. Esta métrica te ayuda a comprender si el entorno escala según el volumen de tráfico entre los dispositivos perimetrales y las cargas de trabajo de backend. Por ejemplo, si el recuento de dispositivos activos y el recuento de operaciones de dispositivos aumentan, pero la capacidad de procesamiento del mensaje no cambia demasiado, es posible que desees verificar si las cargas de trabajo de backend tienen recursos suficientes para manejar mensajes crecientes.
  • Latencia de entrega de mensajes: La cantidad de tiempo transcurrido después de que un dispositivo perimetral publica un mensaje y antes de que una carga de trabajo de backend lo reciba para su procesamiento. Por ejemplo, si el valor de latencia aumenta, es posible que desees verificar si hay problemas que ralentizan la entrega del mensaje.
  • Mensajes que no se pueden entregar: La cantidad de mensajes que no se pueden entregar a dispositivos perimetrales ni cargas de trabajo de backend. Si no se entregan mensajes a los consumidores, es posible que los dispositivos perimetrales o las cargas de trabajo de backend no respondan.
  • Uso de cuota de recursos de la nube: Supervisa el uso de cuota de recursos en la nube a fin de asegurarte de que el entorno tenga suficientes recursos para escalar.
Supervisa el entorno de origen

Cloud Monitoring recopila de forma automática las métricas de IoT Core y Pub/Sub. Por ejemplo, IoT Core expone las métricas device/active_devices, device/error_count y device/operation_count. Estos datos te ayudan a comprender cuántos dispositivos perimetrales están conectados al entorno de origen y cuántos dispositivos perimetrales enfrentan errores que se comunican con IoT Core. Las métricas device/received_bytes_count y device/sent_bytes_count te ayudan a supervisar el consumo de ancho de banda de red.

Para supervisar el estado y la condición de la entrega de mensajes, usa el lenguaje de consultas de Monitoring a fin de medir la puntuación de estado de la latencia de entrega de una suscripción. capacidad de procesamiento de mensajes y mensajes que no se pueden entregar.

Supervisa el entorno de destino

Supervisa el entorno de destino para comprender si la migración se realizó de forma correcta. Según la arquitectura del entorno de destino, el agente de MQTT o la plataforma de IoT de terceros puede proporcionar las siguientes métricas:

Migra la información de metadatos del dispositivo perimetral del entorno de origen al entorno de destino

Para migrar a la nueva plataforma de IoT, migra la información de metadatos de dispositivos perimetrales al entorno de destino. Para migrar los metadatos del dispositivo perimetral, considera las siguientes categorías de metadatos:

  • Credenciales de dispositivo: IoT Core autentica los dispositivos perimetrales mediante un par de claves y tokens de corta duración. Sigue los pasos necesarios del entorno de destino para registrar dispositivos en el entorno de destino y crear credenciales de dispositivo en el entorno de destino según su mecanismo de autenticación.

  • Configuración del dispositivo: Puede ser que tu entorno de destino sea una plataforma de IoT de terceros que proporciona servicio de configuración de dispositivos y tu caso práctico requiere que los dispositivos perimetrales se configuren con el último estado deseado. En este caso, debes migrar la configuración del dispositivo al entorno de destino. Durante la migración, asegúrate de que la configuración del dispositivo esté sincronizada entre el entorno de origen y el entorno de destino. Si tu entorno de destino se basa en un agente de MQTT o Pub/Sub y no proporciona una forma de administrar la configuración de dispositivos, es posible que desees almacenar las configuraciones de dispositivos en buckets de Cloud Storage, siempre y cuando archivo de términos.

  • Información sobre el estado del dispositivo: Asegúrate de que los dispositivos perimetrales actualicen su estado cuando se conecten al entorno de destino por primera vez para que el entorno de destino tenga la información más actualizada sobre lo siguiente: estado del dispositivo.

Después de completar este paso, verifica si la información y las credenciales del dispositivo necesarias están configuradas de forma correcta y que los dispositivos perimetrales pueden conectarse al entorno de destino y autenticarse.

Actualiza los dispositivos perimetrales para conectarte al entorno de origen y al entorno de destino

Cuando llegues a esta etapa, el entorno de destino estará listo para aceptar conexiones desde dispositivos perimetrales. Puedes actualizar los dispositivos perimetrales para conectarlos al entorno de origen y al de destino a fin de enviar eventos de telemetría y, también, información sobre el estado del dispositivo. Cuando actualizas los dispositivos perimetrales, el enfoque que debes tomar depende de la categoría de dispositivo perimetral.

En el caso de los dispositivos perimetrales que sí envían eventos de telemetría o información sobre el estado del dispositivo, pero no reciben comandos ni actualizaciones de configuración del dispositivo de las cargas de trabajo de backend, debes hacer lo siguiente:

  1. Actualiza los dispositivos perimetrales para que envíen eventos de telemetría e información sobre el estado del dispositivo al entorno de origen y de destino.
  2. Verifica que el entorno de destino reciba eventos y la información de telemetría sobre el estado del dispositivo de manera correcta

Por el contrario, en los dispositivos perimetrales que no envían eventos de telemetría ni información sobre el estado del dispositivo, pero sí reciben comandos o actualizaciones de configuración de las cargas de trabajo de backend, debes hacer lo siguiente:

  1. Actualiza los dispositivos perimetrales para recibir comandos y actualizaciones de configuración del entorno de destino.
  2. Asegúrate de que los dispositivos perimetrales informen el resultado de la ejecución del comando o las actualizaciones de configuración al entorno de destino.
  3. Envía un comando y una actualización de configuración del entorno de destino a los dispositivos perimetrales
  4. Verifica que la ejecución del comando y de la actualización de la configuración sea exitosa.

Para dispositivos perimetrales que envían eventos de telemetría e información sobre el estado del dispositivo y también reciben comandos o actualizaciones de configuración de las cargas de trabajo de backend, haz lo siguiente:

  1. Actualiza los dispositivos perimetrales para que envíen eventos de telemetría e información sobre el estado del dispositivo al entorno de origen y de destino.
  2. Verifica que el entorno de destino reciba eventos y la información de telemetría sobre el estado del dispositivo de manera correcta
  3. Actualiza los códigos de los dispositivos perimetrales para recibir comandos y actualizaciones de configuración del entorno de destino.
  4. Asegúrate de que los dispositivos perimetrales informen el resultado de la ejecución del comando o las actualizaciones de configuración al entorno de destino.
  5. Envía un comando y una actualización de configuración del entorno de destino a los dispositivos perimetrales
  6. Verifica que la ejecución del comando y de la actualización de la configuración sea exitosa.

Después de ejecutar estos pasos para tu caso de uso, todas las categorías de dispositivo perimetral hacen lo siguiente:

  • Se conéctan al entorno de origen y al entorno de destino.
  • Envían información y eventos de telemetría sobre el estado del dispositivo al origen y al entorno de destino.
  • Reciben comandos y actualizaciones de configuración del entorno de origen solo porque aún no migraste las cargas de trabajo de backend.

Es mejor evitar una situación en la que las cargas de trabajo de backend procesen el mismo mensaje que los dispositivos perimetrales envían al entorno de origen y al de destino. Te recomendamos que configures el período de retención de mensajes en el entorno de destino con el valor mínimo posible. Este enfoque te permite verificar que el entorno de destino funcione como se espera. También te permite verificar que los mensajes en el entorno de destino venzan antes de migrar las cargas de trabajo del backend. Puedes ajustar la configuración de retención de mensajes en el entorno de destino después del siguiente paso de migración.

Si tus dispositivos perimetrales no pueden conectarse al entorno de origen y al entorno de destino al mismo tiempo debido a motivos técnicos o reglamentarios, primero debes configurar el dispositivo perimetral para desconectarte del entorno de origen. Luego, solo puedes conectarte al entorno de destino. En este caso, las cargas de trabajo de backend que aún están conectadas al entorno de origen dejan de recibir eventos de telemetría y la información sobre el estado del dispositivo desde dispositivos perimetrales. Los dispositivos ya no pueden enviar comandos ni actualizaciones de configuración a dispositivos perimetrales.

También te recomendamos que aprovisiones y configures un mecanismo de almacenamiento de búferes. Este enfoque ayuda a evitar la pérdida de datos cuando el dispositivo envía eventos de telemetría y la información sobre el estado del dispositivo al entorno de destino cuando las cargas de trabajo de backend aún están conectadas al entorno de origen. Las cargas de trabajo de backend pueden consumir esta información cuando se conectan al entorno de destino. Por ejemplo, puedes configurar la retención de mensajes del entorno de destino, según un agente de MQTT, Pub/Sub o en una plataforma de IoT. Este enfoque te permite mantener los mensajes no confirmados disponibles durante el tiempo necesario para completar la siguiente fase de la migración, como se describe en la siguiente sección.

Migra las cargas de trabajo de backend del entorno de origen al entorno de destino

Debes migrar tus cargas de trabajo de backend al entorno de destino. Según la arquitectura del entorno de destino, debes adoptar diferentes enfoques para migrar la carga de trabajo.

MQTT Broker en Google Cloud: Si tu entorno de destino se basa en un agente de MQTT, los siguientes factores orientan tu enfoque de migración:

  • Para las cargas de trabajo de backend que sí reciben eventos de telemetría o información sobre el estado del dispositivo desde dispositivos perimetrales, pero no envían comandos ni actualizaciones de configuración del dispositivo: configura tus cargas de trabajo de backend para suscribirse a temas de MQTT para recibir eventos de telemetría e información sobre el estado del dispositivo que proviene de dispositivos perimetrales.
  • Por el contrario, para las cargas de trabajo de backend que no reciben eventos de telemetría ni información sobre el estado del dispositivo, pero sí envían comandos o actualizaciones de configuración del dispositivo: configura tus cargas de trabajo de backend para publicar mensajes y enviar comandos y actualizaciones de configuración a temas de MQTT para actualizaciones de comandos y configuración en el entorno de destino.
  • Para las cargas de trabajo de backend que reciben eventos de telemetría o información sobre el estado del dispositivo desde dispositivos perimetrales y envían comandos o actualizaciones de configuración del dispositivo: configura tus cargas de trabajo de backend para suscribirte a temas de MQTT a fin de recibir telemetría y, luego, configura tus cargas de trabajo de backend para publicar mensajes para enviar comandos y actualizaciones de configuración a los temas de MQTT.

Pub/Sub: Si tu entorno de destino se basa en Pub/Sub, los siguientes factores orientan tu enfoque de migración:

  • Para las cargas de trabajo de backend que sí reciben eventos de telemetría o información sobre el estado del dispositivo desde dispositivos perimetrales, pero no envían comandos ni actualizaciones de configuración del dispositivo: crea nuevas suscripciones de Pub/Sub en el entorno de destino y actualiza tus cargas de trabajo de backend para consumir las suscripciones recién creadas.
  • Por el contrario, para las cargas de trabajo de backend que no reciben eventos de telemetría ni información sobre el estado del dispositivo, pero sí envían comandos o actualizaciones de configuración del dispositivo: crea Pub/Subtemas y configura tus cargas de trabajo de backend para publicar mensajes a fin de enviar comandos y actualizaciones de configuración a temas de Pub/Sub.
  • Para las cargas de trabajo de backend que reciben eventos de telemetría o información sobre el estado del dispositivo desde dispositivos perimetrales y envían comandos o actualizaciones de configuración del dispositivo: configura tus cargas de trabajo de backend para suscribirse a temas de Pub/Sub a fin de para recibir eventos de telemetría e información sobre el estado del dispositivo. Luego, configura las cargas de trabajo de backend para publicar mensajes a fin de enviar comandos y actualizaciones de configuración a temas de Pub/Sub.

Plataforma de IoT de terceros: Si tu entorno de destino se basa en una plataforma de IoT de terceros, debes seguir las instrucciones de la plataforma de IoT de terceros para configurar integraciones entre cargas de trabajo de backend y la plataforma de IoT. Luego, verificas que las cargas de trabajo de backend puedan recibir información y eventos de telemetría sobre el estado del dispositivo que provienen de dispositivos perimetrales. También verificas que las cargas de trabajo de backend puedan publicar mensajes para enviar comandos o actualizaciones de configuración del dispositivo al dispositivo perimetral.

Para verificar que los dispositivos perimetrales y las cargas de trabajo de backend funcionen como se espera, te recomendamos que hagas lo siguiente:

  • Verifica que las cargas de trabajo de backend reciban información y eventos de telemetría sobre el estado del dispositivo y que reaccionen de forma correcta Por ejemplo, si tus cargas de trabajo de backend generan un panel casi en tiempo real para supervisar datos de telemetría específicos, verifica que el panel esté actualizado con el período de datos más reciente.
  • Verifica que las cargas de trabajo de backend envíen comandos y actualizaciones de configuración a los dispositivos perimetrales como se espera Verifica que los dispositivos perimetrales también reaccionen como esperas.
  • Verifica si el dispositivo perimetral informa eventos y telemetría de estado sobre el estado del dispositivo al entorno de destino.

En este punto, las cargas de trabajo de backend hacen lo siguiente:

  • Se conectan al entorno de destino.
  • Reciben información y eventos de telemetría sobre el estado del dispositivo desde dispositivos perimetrales desde el entorno de destino
  • Envían comandos y actualizaciones de configuración a dispositivos perimetrales desde el entorno de destino.

Ahora puedes actualizar la configuración de la retención de mensajes del entorno de destino que estableciste en un valor mínimo cuando conectas los dispositivos perimetrales al entorno de origen y al de destino, y configúrelo según tus requisitos.

Cuando actualizas la configuración de las cargas de trabajo de backend para recibir información y eventos de telemetría sobre el estado del dispositivo del entorno de destino, es posible que las cargas de trabajo de backend necesiten tiempo para aplicar esta configuración actualizada. Durante la fase transitoria, las cargas de trabajo de backend no pueden consumir información y eventos de telemetría sobre el estado del dispositivo que envían los dispositivos perimetrales. Si tus casos de uso requieren integridad de datos completa, es posible que debas configurar el período de retención de mensajes del entorno de destino antes de actualizar la configuración de las cargas de trabajo de backend. Este enfoque garantiza que los mensajes no caduquen antes de que las cargas de trabajo de backend puedan aplicar la configuración nueva y consumir los mensajes.

Actualiza los dispositivos perimetrales para conectarte solo al entorno de destino

En este punto, ya migraste de forma correcta tus dispositivos perimetrales al entorno de destino; sin embargo, también seguirán usando el entorno de origen. A fin de completar el paso de migración, actualiza tus dispositivos perimetrales para conectarte al entorno de destino solo mediante la eliminación de las conexiones a IoT Core y la integración con IoT Core. Una vez que se complete la actualización, tus dispositivos perimetrales solo se conectarán al entorno de destino.

Retirar el servicio el entorno de origen.

Después de migrar los dispositivos perimetrales y las cargas de trabajo de backend al entorno de destino y validar el entorno de destino, debes retirar el entorno de origen.

Para retirar el entorno de origen, haz lo siguiente:

  1. Borra las suscripciones a Pub/Sub que se suscriben a los temas de IoT Core.
  2. Borra los temas de Pub/Sub sin usar. Si vuelves a usar temas de Pub/Sub, asegúrate de no borrar los temas creados por IoT Core. Puedes encontrar los temas de Pub/Sub que usa IoT Core con la consola de IoT Core.
  3. Borra los dispositivos y registros de IoT Core.

Optimiza tu entorno después de la migración

La optimización es la última fase de la migración. En esta fase, harás que tu entorno sea más eficiente que antes. También, ejecutarás varias iteraciones de un ciclo repetible hasta que tu entorno cumpla con tus requisitos de optimización. Los siguientes son los pasos de este ciclo repetible:

  1. Evalúa tu entorno actual, los equipos y el ciclo de optimización.
  2. Establece tus requisitos y objetivos de optimización.
  3. Optimiza tu entorno y tus equipos.
  4. Ajusta el ciclo de optimización.

Las siguientes secciones se basan en Migración a Google Cloud: optimiza tu entorno.

Evalúa el entorno de destino, los equipos y el bucle de optimización

Si bien la primera evaluación que realizas se enfoca en el entorno de origen, esta fase de evaluación es para la fase de optimización. Para obtener más información sobre cómo evaluar el entorno de destino, los equipos y el bucle de optimización, consulta Mide el entorno, los equipos y el bucle de optimización.

Establece tus requisitos de optimización

Revisa los siguientes requisitos de optimización que podrías necesitar para el entorno de destino:

  • Configura el ajuste de escala automático: Usa los servicios de Google Cloud, como Grupo de instancias administrado o Google Kubernetes Engine para escalar de forma automática o vertical a tu solución de IoT y tus cargas de trabajo de backend cuando aumentan las cargas. Este enfoque ayuda a garantizar que el registro de tu dispositivo y el almacenamiento de datos de telemetría puedan manejar un mayor volumen de datos cuando implementas una flota de dispositivos grande. Debido a que Cloud Spanner es una base de datos transaccional distribuida, con alta disponibilidad y escalable, es una buena opción para almacenar tus datos de telemetría y la información de registro del dispositivo.
  • Mejora el mecanismo de registro y supervisión: Optimiza e integra tu mecanismo de registro y supervisión para formar una solución centralizada. También puedes mejorar ciertas métricas de supervisión para ayudarte a comprender cómo interactúan los dispositivos perimetrales con tu solución de IoT. También debes registrar y correlacionar actividades como eventos de conexión, desconexión y eventos de telemetría. También te recomendamos supervisar los errores del sistema y de la aplicación. Si es posible, configura una alerta cuando se produzcan ciertas fallas críticas a nivel del sistema.
  • Protege tus cargas de trabajo mediante los servicios de seguridad de Google Cloud: Security Command Center es un servicio centralizado de informes de vulnerabilidades y amenazas que puedes usar para ayudarte a fortalecer tu posición de seguridad mediante la evaluación de la superficie de ataque de datos y la seguridad. Proporciona inventario y descubrimiento de elementos, y puede ayudarte a identificar opciones de configuración incorrectas, vulnerabilidades y amenazas. Security Command Center también te ayuda a mitigar y solucionar los riesgos. Para obtener información sobre cómo proteger tus cargas de trabajo que se ejecutan en Google Kubernetes Engine (GKE), consulta Descripción general de seguridad de Google Kubernetes Engine para obtener información sobre cómo proteger tus cargas de trabajo de GKE.

Completa la optimización

Después de propagar la lista de requisitos de optimización, completa la fase de optimización. Para obtener información sobre cómo hacerlo, consulta Migración a Google Cloud: Optimiza tu entorno.

¿Qué sigue?