Alternativa a Google Cloud IoT Core: opciones y migración tras su cierre

Si buscas una alternativa a Google Cloud IoT Core, probablemente estás migrando una flota que quedó varada tras el cierre o diseñando un proyecto nuevo en Google Cloud sin una pasarela de dispositivos nativa. Esta guía explica qué hacía IoT Core, compara con imparcialidad las opciones de sustitución realistas, traduce los conceptos de IoT Core a MQTT estándar y recorre el traslado de los dispositivos a un broker MQTT gestionado mientras tus datos siguen llegando a los servicios de Google Cloud.

Qué pasó con Google Cloud IoT Core

Google anunció en 2022 que Cloud IoT Core dejaría de ofrecerse, y el servicio se retiró el 16 de agosto de 2023. A partir de esa fecha los dispositivos ya no pudieron conectarse a sus bridges MQTT y HTTP. Google no lanzó un sucesor directo; en su lugar, remitió a los clientes a soluciones de partners y a construir sobre servicios generales de Google Cloud. Otros productos de Google Cloud, como Pub/Sub, Dataflow y BigQuery, no se vieron afectados y siguen siendo destinos habituales para los datos IoT.

IoT Core combinaba tres funciones, y cada una necesita un sustituto:

1. Conectividad de dispositivos: un endpoint MQTT en mqtt.googleapis.com en el puerto 8883 (y 443).
2. Registro y autenticación de dispositivos: dispositivos identificados por client IDs largos con la forma projects/PROJECT/locations/REGION/registries/REGISTRY/devices/DEVICE, autenticados con un JWT firmado con una clave privada por dispositivo y enviado como contraseña MQTT.
3. Enrutamiento de datos: la telemetría publicada en /devices/DEVICE_ID/events se reenviaba a topics de Pub/Sub; la configuración y los comandos bajaban por /devices/DEVICE_ID/config y /devices/DEVICE_ID/commands/#, y el estado del dispositivo subía por /devices/DEVICE_ID/state.

Comparativa de alternativas a Google Cloud IoT Core

No hay una única respuesta correcta. El mejor sustituto depende de cuánto usaras las funciones de IoT Core y de dónde quieras que residan tus datos.

Todas las opciones son legítimas. Los servicios IoT de los hiperescaladores ofrecen motores de reglas e integraciones muy completos; las plataformas de partners pueden reducir los cambios de firmware; el autoalojamiento da el máximo control. Un broker MQTT gestionado queda en medio: protocolo estándar, dependencia mínima del proveedor y ningún servidor que mantener, a cambio de construir tu propio reenvío hacia Google Cloud. Para una comparativa más amplia de los servicios de los hiperescaladores, consulta nuestra guía de alternativa a AWS IoT Core.

Cómo traducir los conceptos de IoT Core a MQTT estándar

Pasar a un broker estándar es sobre todo un ejercicio de traducción:

Ahora el diseño de los topics es cosa tuya. Elimina la barra inicial que usaba IoT Core, ya que añade un primer nivel vacío, y plantéate una jerarquía de estilo ISA-95 si trabajas en fabricación.

Paso a paso: mover los dispositivos a un broker MQTT gestionado

1. Preparar el broker

Regístrate en app.connectmq.com, elige un plan dimensionado para tu pico de conexiones, crea un broker y emite credenciales. El plan Serverless gratuito (hasta 25 conexiones, QoS hasta 1) basta para validar el firmware y el servicio de reenvío; Serverless Paid admite hasta 1.000 conexiones y QoS 2.

2. Actualizar el firmware de los dispositivos

Sustituye la generación del JWT y el client ID de IoT Core por el usuario, la contraseña y el client ID emitidos, cambia el host y actualiza los nombres de los topics. Mantén TLS en el puerto 8883; ConnectMQ usa un certificado de Let's Encrypt, así que tu almacén de confianza debe incluir el certificado ISRG Root X1 en lugar de las raíces de Google. Elimina la lógica de renovación del JWT, que a menudo causaba errores de reconexión en los dispositivos de IoT Core. Si tus dispositivos se basan en ESP32, el tutorial de ESP32 con MQTT muestra un cliente TLS completo.

3. Reenviar la telemetría a Pub/Sub

ConnectMQ no incluye bridges de datos hacia la nube, así que los datos llegan a Pub/Sub mediante un pequeño servicio de reenvío que se conecta como un cliente MQTT normal. Ejecútalo en Cloud Run, GKE o una VM con una cuenta de servicio autorizada para publicar en el topic. Instálalo con pip install "paho-mqtt>=2.0" google-cloud-pubsub.

import os
import ssl

import paho.mqtt.client as mqtt
from google.cloud import pubsub_v1

PROJECT = os.environ["GCP_PROJECT"]
PUBSUB_TOPIC = os.environ.get("PUBSUB_TOPIC", "device-telemetry")
MQTT_FILTER = os.environ.get("MQTT_FILTER", "fleet/+/+/telemetry")

publisher = pubsub_v1.PublisherClient()
topic_path = publisher.topic_path(PROJECT, PUBSUB_TOPIC)


def on_connect(client, userdata, flags, reason_code, properties):
    print("Connected:", reason_code)
    client.subscribe(MQTT_FILTER, qos=1)


def on_message(client, userdata, msg):
    device_id = msg.topic.split("/")[2]
    future = publisher.publish(
        topic_path,
        msg.payload,
        mqtt_topic=msg.topic,
        device_id=device_id,
    )
    future.add_done_callback(
        lambda f: f.exception() and print("Pub/Sub publish failed:", f.exception())
    )


client = mqtt.Client(
    mqtt.CallbackAPIVersion.VERSION2,
    client_id=os.environ["MQTT_CLIENT_ID"],
    protocol=mqtt.MQTTv5,
)
client.username_pw_set(os.environ["MQTT_USERNAME"], os.environ["MQTT_PASSWORD"])
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

Asigna a MQTT_USERNAME, MQTT_PASSWORD y MQTT_CLIENT_ID los valores del portal (YOUR_USERNAME, YOUR_PASSWORD, YOUR_CLIENT_ID), idealmente desde Secret Manager. Atributos como device_id permiten a los suscriptores posteriores y a los jobs de Dataflow filtrar sin analizar los payloads, de forma parecida a como IoT Core añadía atributos del dispositivo. La documentación oficial de la librería cliente de Pub/Sub cubre el batching y el control de flujo para volúmenes altos. Para escalar horizontalmente, ejecuta varias instancias con una suscripción compartida de MQTT 5 como $share/forwarders/fleet/+/+/telemetry, disponible en Serverless Paid y superiores.

4. Sustituir la configuración y los comandos

Los mensajes de configuración de IoT Core se corresponden de forma natural con los retained messages de MQTT: publica la configuración de cada dispositivo como mensaje retenido en su topic de configuración y el dispositivo la recibirá cada vez que se conecte. Los comandos se corresponden con un topic de comandos con QoS 1. Haz los comandos idempotentes con un ID único y una caducidad, como se describe en nuestra guía para sobrevivir a una caída del broker MQTT.

5. Despliegue por oleadas

Mueve primero un grupo piloto, vigila el estado de conexión en $SYS/broker/connection/{clientId}/state y en el explorador de topics del portal, y después migra el resto por región o línea de producto. Si algunos dispositivos no se pueden actualizar rápido, una pasarela local puede traducir sus topics antiguos y republicar en la nueva jerarquía.

Checklist antes del cambio

1. Inventario de dispositivos, versiones de firmware y funciones de IoT Core en uso.
2. Nueva jerarquía de topics diseñada y documentada.
3. Plan del broker dimensionado para el pico de conexiones, el QoS y el tamaño de mensaje.
4. Credenciales emitidas por dispositivo y almacenadas de forma segura.
5. Firmware actualizado con el nuevo host, almacén de confianza, credenciales y topics.
6. Servicio de reenvío en marcha y verificado en Pub/Sub.
7. Flujos de configuración y comandos probados de extremo a extremo.
8. Plan de despliegue con grupo piloto y pasos de vuelta atrás.

Si parte de tu flota ya funciona sobre un broker local, la guía para migrar Mosquitto a MQTT en la nube cubre con más detalle el bridging y el cambio por oleadas.

Lleva tu flota a ConnectMQ

Crea un broker gratuito en app.connectmq.com con el plan Serverless, sin tarjeta de crédito, y valida tu firmware y tu servicio de reenvío antes de migrar la flota. ConnectMQ es un broker MQTT gestionado con MQTT 3.1.1 y 5.0 estándar, TLS, WebSockets y un portal con explorador de topics en vivo. Lee la guía del broker MQTT en la nube para conocer las opciones de despliegue o prueba el servidor MQTT público gratuito de broker.connectmq.com para un primer test; es solo para pruebas y prototipos, no para datos de producción.

Preguntas frecuentes

¿Cuándo cerró Google Cloud IoT Core?

Google retiró Cloud IoT Core el 16 de agosto de 2023, tras anunciar su discontinuación en 2022. Los dispositivos ya no pueden conectarse a sus endpoints.

¿Puedo seguir usando Pub/Sub y BigQuery después de pasar a otro broker?

Sí. Esos servicios no se vieron afectados. Un pequeño servicio suscriptor reenvía los mensajes MQTT del broker a Pub/Sub y los pipelines existentes continúan a partir de ahí.

¿Necesito autenticación JWT en un nuevo broker MQTT?

No necesariamente. La mayoría de los brokers MQTT gestionados, ConnectMQ incluido, usan usuario y contraseña por dispositivo sobre TLS, lo que elimina del firmware la lógica de renovación del JWT.

¿Cuál es el sustituto más parecido a la configuración de dispositivos de IoT Core?

Los retained messages de MQTT. Publica la configuración de cada dispositivo como mensaje retenido en su propio topic de configuración y el dispositivo recibirá la última versión cada vez que se conecte.