Arquitectura de productos de plataforma de IoT en Google Cloud

Los productos de la plataforma de IoT suelen proporcionar conectividad básica de datos MQTT y HTTPS. También te permiten aprovisionar dispositivos y proporcionan autenticación y administración, almacenamiento y visualización de telemetría, procesamiento de datos y alertas. Las organizaciones suelen usar plataformas de IoT cuando un agente de MQTT independiente no es suficiente para un caso práctico y se necesita un producto de plataforma de IoT más completo. Una plataforma de IoT proporciona una interfaz unificada para administrar una colección heterogénea de dispositivos. Esta interfaz es importante para muchas aplicaciones de dispositivos conectados y es una diferencia clave entre una plataforma de IoT y un agente de MQTT independiente. En este documento, se describen las consideraciones básicas de la arquitectura y las recomendaciones que debes realizar antes de implementar una arquitectura de productos de la plataforma de IoT en Google Cloud.

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:

En el siguiente diagrama, se muestra un ejemplo de la arquitectura con un producto genérico de plataforma de IoT que se ejecuta en Google Cloud.

Una arquitectura genérica de plataforma de IoT (flujo de eventos que se explica en el siguiente texto).

Como se muestra en el diagrama anterior, la plataforma de IoT implementa un agente o extremo de MQTT para la conectividad de dispositivos. La plataforma de IoT está conectada a un balanceador de cargas de red de proxy externo para distribuir el tráfico desde los dispositivos perimetrales. Las aplicaciones de IoT adicionales pueden conectarse a la plataforma de IoT a través de Pub/Sub o el conector de MQTT de Dataflow.

La plataforma IoT proporciona un conjunto de servicios de administración de dispositivos. Como se muestra en el diagrama, estos servicios son los siguientes:

  • Almacén de credenciales de dispositivos
  • Motor de reglas
  • Autenticación y autorización de dispositivos
  • Administración de configuración del dispositivo
  • Registro de dispositivos
  • Administración de actualización del dispositivo

Los productos de la plataforma de IoT también suelen incluir servicios como gemelos digitales, interfaces de desarrollo con bajo nivel de codificación, funciones de alertas y notificaciones y otras funcionalidades de estadísticas.

Consideraciones y elecciones de arquitectura

En las siguientes secciones, se describen las decisiones arquitectónicas que puedes tomar para una arquitectura de productos de la plataforma de IoT y el impacto de estas opciones.

Extremos de transferencia

La mayoría de las aplicaciones comerciales de la plataforma de IoT incluyen un extremo MQTT y, por lo general, un extremo HTTPS para la transferencia de datos desde dispositivos conectados.

MQTT

Una plataforma de IoT implementa un extremo de MQTT de una de las siguientes maneras:

  • Un conector entre MQTT y otro servicio de mensajes
  • Un agente de MQTT que implementa la especificación MQTT completa

Cuando evalúas plataformas de IoT comerciales, es importante saber cuál de los enfoques anteriores eligió el proveedor para el producto a fin de que puedas determinar las implicaciones para tu caso práctico.

En algunos casos, el extremo de MQTT solo conecta a los clientes de MQTT con un servicio de mensajería de backend, como Kafka o Pub/Sub. Por lo general, este tipo de extremo no implementa la especificación del protocolo MQTT completa y, a menudo, no incluye funciones como los niveles de QoS 1 y 2, o las suscripciones compartidas. La ventaja de este enfoque es que disminuye la complejidad en la plataforma de IoT, ya que no hay una aplicación del agente de MQTT separada. Los costos operativos son más bajos y el mantenimiento es más simple que si la plataforma usa un agente de MQTT separado. Sin embargo, debido a la menor compatibilidad con las funciones más avanzadas del protocolo MQTT, este enfoque significa que hay menos flexibilidad y funcionalidad para el transporte de mensajes MQTT que un agente de MQTT independiente que implemente la especificación MQTT completa.

Otras plataformas de IoT proporcionan un agente de MQTT completo como parte de la plataforma, como se muestra en la arquitectura de ejemplo de este documento. Este agente puede ser uno de los agentes de código abierto existentes o una implementación de agente propia. Un agente de MQTT completo proporciona la capacidad MQTT bidireccional completa antes, pero un agente completo puede agregar complejidad y costos operativos a la administración de la plataforma de IoT.

HTTPS y otros protocolos complementarios

Además de MQTT, muchas plataformas de IoT proporcionan más extremos de transferencia de datos que los que se muestran en la arquitectura principal que se describe en este documento.

HTTPS es un protocolo alternativo común a MQTT para casos prácticos de dispositivos conectados. Tiene una sobrecarga mayor que MQTT, pero es más compatible con dispositivos móviles, como teléfonos, y con navegadores web y otras aplicaciones. Se usa con frecuencia en ciertas aplicaciones de dispositivos conectados y es compatible con plataformas de código abierto, como Eclipse Hono y muchos productos comerciales.

Muchas aplicaciones de dispositivos limitadas usan (Protocolo de aplicación restringido [CoAP], definido en RFC 7252) como una alternativa MQTT. CoAP se orienta a los clientes de baja sobrecarga y de huella pequeña para los dispositivos y sensores incorporados. Muchas aplicaciones de plataforma de IoT comerciales también proporcionan un extremo de CoAP.

Balanceo de cargas

Si deseas obtener más información sobre cómo elegir el mejor balanceador de cargas para tu arquitectura, consulta la sección de balanceo de cargas de la arquitectura del agente de MQTT independiente en Google Cloud porque esas consideraciones también se aplican a este caso.

Autenticación del dispositivo y administración de credenciales

La administración de las credenciales del dispositivo y la autenticación son una parte clave de la operación de una plataforma de IoT. Los métodos de autenticación compatibles con los dispositivos conectados varían ampliamente en las aplicaciones y los factores de forma de los dispositivos. Es importante seleccionar el método de autenticación adecuado para el caso práctico de destino y, luego, implementar el esquema de autenticación elegido de manera correcta.

A diferencia de un agente de MQTT independiente, una plataforma de IoT proporciona servicios integrados para administrar las identidades y las credenciales de dispositivos. La mayoría de las plataformas de IoT usan la autenticación de certificados de cliente X.509 para la autenticación, la autenticación basada en token de JWT (a menudo combinada con OAuth 2.0) y la autenticación de nombre de usuario y contraseña. Algunas plataformas también admiten la integración con un proveedor de autenticación de LDAP externo.

Para algunos dispositivos restringidos, la autenticación con nombre de usuario y contraseña y autenticación con contraseña pueden ser más apropiadas, ya que estos esquemas requieren menos recursos en un dispositivo conectado. Cuando usas la autenticación con nombre de usuario o JWT y contraseña, es importante que encriptes la conexión de red por separado a la autenticación mTLS, porque ninguno de estos métodos de autenticación requiere una conexión encriptada. Por el contrario, la autenticación de certificados X.509 consume más recursos en el dispositivo conectado, pero, por lo general, se usa en una conexión encriptada mediante mTLS y, por lo tanto, proporciona un alto nivel de seguridad.

El aprovisionamiento de las credenciales de autenticación en el dispositivo perimetral durante la fabricación también es una parte importante del esquema de autenticación del dispositivo conectado, pero está fuera del alcance de este documento.

Si quieres obtener más información sobre la autenticación y la administración de credenciales, consulta Prácticas recomendadas para ejecutar un backend de IoT en Google Cloud.

Administrar dispositivos conectados

Por lo general, los dispositivos conectados publican información sobre el estado y los eventos de telemetría en la plataforma a través de uno de los extremos de transferencia, como MQTT. Si usas una plataforma de IoT de varios protocolos, los dispositivos pueden comunicarse mediante cualquiera de los protocolos compatibles.

Recomendamos que tu organización use una plataforma de IoT que tiene las siguientes capacidades:

  • Actualizaciones de software y sistema: la entrega y reversión de firmware, software y actualizaciones de aplicaciones a los dispositivos conectados. Por lo general, estas actualizaciones implican almacenamiento y administración de las actualizaciones.
  • Actualizaciones de configuración: La entrega, el almacenamiento y la reversión de actualizaciones a la configuración de las aplicaciones implementadas en los dispositivos conectados.
  • Creación y administración de credenciales: La creación de credenciales de dispositivos nuevas, la entrega de esas credenciales al dispositivo conectado, la auditoría de los intentos y la actividad de acceso al dispositivo y la revocación de compromisos o compromisos las credenciales vencidas en el momento adecuado.
  • Motor de reglas y procesamiento de datos: La definición y ejecución de reglas basadas en datos y otros pasos de procesamiento de datos. Esta función a menudo incluye algún tipo de interfaz de código bajo para definir reglas y canalizaciones de procesamiento de datos.

Cargas de trabajo del backend

La mayoría de las plataformas de IoT proporcionan sus propias capacidades de almacenamiento y transporte de datos internos que te permiten conectarte a tus cargas de trabajo y aplicaciones de backend. Se suelen usar AMQP, RabbitMQ y Kafka para proporcionar el transporte interno de datos. Todos se pueden conectar a Pub/Sub con el SDK de Pub/Sub. También puedes usar un sistema de base de datos integrado, como PostgreSQL, para almacenar datos en la plataforma. En muchos casos, la plataforma de IoT se puede configurar para usar uno de los productos de Cloud Storage directamente, como Cloud SQL, Firebase o BigQuery.

Si la plataforma de IoT tiene un agente de MQTT completo, las aplicaciones de backend también pueden comunicarse con dispositivos mediante la capacidad de MQTT de la plataforma. Si la aplicación es compatible con MQTT, la aplicación puede conectarse con el agente como suscriptor. Si no hay compatibilidad con MQTT, Apache Beam proporciona un controlador MQTT, que permite la integración bidireccional con Dataflow y otras implementaciones de Beam.

Casos de uso

En las siguientes secciones, se describen situaciones de ejemplo en las que una plataforma de IoT es una mejor opción de arquitectura que un agente de MQTT independiente o una conexión directa a Pub/Sub.

Administración de dispositivos inteligentes

Las aplicaciones que administran varios dispositivos inteligentes son adecuadas para una plataforma de IoT. Un ejemplo de esta aplicación es una plataforma para administrar dispositivos de cocina, como lavavajillas y cafeteras. Por lo general, estos dispositivos se conectan a una aplicación basada en la nube, ya sea directamente a través de Wi-Fi o a través de una puerta de enlace local que use un Bluetooth de bajo consumo (BLE) o algún otro protocolo local. Las capacidades de administración de una plataforma de IoT son importantes aquí, para supervisar el estado de cada dispositivo, administrar las actualizaciones de software y los parches de seguridad, y capturar la actividad del dispositivo a fin de proporcionar inteligencia crítica al fabricante y al cliente. Estas capacidades están fuera del alcance de un agente de MQTT básico. Como mínimo, un repositorio de información del dispositivo, una base de datos de estado del dispositivo, un almacén de datos de telemetría y una interfaz de estadísticas son fundamentales para compilar una plataforma de dispositivo inteligente exitosa.

Logística y seguimiento de recursos

En una aplicación de seguimiento de recursos y logística, un producto de la plataforma de IoT ofrece una funcionalidad más completa que un agente de MQTT básico, por lo que es una mejor opción para este caso de uso. La supervisión del estado actual y el anterior, y la ubicación de una gran flota de recursos dependen de una base de datos de estado del dispositivo sólida y de un sistema de administración de identidades. A medida que se implementan recursos nuevos, deben conectarse a la plataforma con la menor cantidad de inconvenientes posible y, luego, supervisarse durante todo el ciclo de vida de los recursos. En muchos casos, la aplicación también recopila otra información del sensor sobre los elementos, como la temperatura local, la humedad y la presión atmosférica, o los datos de posicionamiento y aceleración 3D para detectar movimientos inesperados o caídas. Todos estos datos deben transferirse y asociarse con el recurso correcto para su análisis en cualquier aplicación de backend, por lo que la administración de dispositivos con todas las funciones que proporciona la plataforma de IoT es una capacidad importante.

¿Qué sigue?