Técnico

Desde retransmisores en la nube hasta orquestadores periféricos: cómo elegir su arquitectura de IoT

March 4th, 2026

Leonel Barragan

SSR. Ingeniero de DevOps

Introducción: El dilema de la arquitectura de nube de IoT

La implementación de dispositivos de IoT a escala plantea una serie de preguntas que son fáciles de responder durante la creación de prototipos, pero que se vuelven fundamentales en la producción:

¿Cómo se conectan los dispositivos a la nube?
¿Cómo publicamos las actualizaciones?
¿Cómo gestionamos una flota?

El panorama ofrece múltiples respuestas a cada pregunta y las opciones no siempre son independientes. Un cliente MQTT directo es sencillo, pero deja la gestión de las actualizaciones exclusivamente en sus manos. Un orquestador perimetral como Azure IoT Edge o AWS Greengrass gestiona la conectividad y el despliegue de los módulos, pero añade una sobrecarga de recursos. La administración de flotas puede delegarse en plataformas dedicadas, gestionarse a través del orquestador o implementarse como una solución de administración de flotas personalizada.

Esta publicación documenta diferentes enfoques para estos problemas, comenzando con un cliente MQTT/AMQP independiente de la nube, luego explorando los orquestadores periféricos y, finalmente, cubriendo las opciones de administración de flotas y las consideraciones prácticas que surgieron de las implementaciones reales.

Arquitectura independiente de la nube con MQTT/AMQP

El primer enfoque priorizó la flexibilidad sobre las funciones. El objetivo era crear un cliente independiente de la nube que pudiera conectarse a Azure IoT Hub o AWS IoT Core y cambiar entre ellos basándose únicamente en la configuración.

En la práctica, este cliente se ejecuta entre los sensores o aplicaciones locales y el servicio en la nube seleccionado. Su trabajo es simple: recopilar datos, formatearlos de acuerdo con lo que espera la nube y transmitirlos de forma segura.

Aspectos arquitectónicos destacados

Selección dinámica de nubes: Al utilizar un PROVEEDOR DE NUBE variable de entorno, el dispositivo puede cambiar su destino ascendente entre Azure y AWS en tiempo real sin necesidad de una actualización de firmware.
Identidad X.509 en la periferia: Priorizamos la seguridad mediante la implementación de la autenticación autofirmada X.509. Esto reemplaza las cadenas de conexión estáticas por identidades criptográficas únicas.
Huella mínima: Los puntos de referencia de rendimiento validaron la eficacia de este enfoque, ya que las métricas del sistema registraron un uso de la CPU de solo el 0,3% aproximadamente y un consumo de memoria del 13,4% aproximadamente en los entornos de prueba.

En la práctica, este enfoque funciona bien porque:

Depuration sencilla: cuando algo se rompe, la causa suele ser evidente.
Verdadera flexibilidad multinube: change of proveedor without code change.

Pero también tiene limitaciones:

Sin capacidades nativas fuera de línea: los mensajes se pierden si no hay conexión.
La actualización de la lógica requiere una nueva implementación all the container in an monolítica configuration. Con un diseño de varios contenedores, es posible realizar actualizaciones parciales (consulte la nota siguiente).
Sin procesamiento local antes de enviarlo a la nube.
Almacenar y reenviar se debe construir manualmente si es necesario.

Nota sobre la granularidad de las actualizaciones: Esta limitación depende de cómo esté diseñada la arquitectura. En una configuración monolítica, cualquier cambio de código obliga a una reconstrucción completa y a un reinicio del contenedor. Sin embargo, dividir estas responsabilidades en servicios independientes en un archivo docker-compose permite realizar actualizaciones parciales: cambiar el servicio X solo desencadena la reconstrucción y el reinicio de X, mientras que Y y Z permanecen intactos. Los orquestadores de Edge, como Greengrass, van más allá. Greengrass administra los componentes como un proceso independiente durante su ejecución y, cuando se activa una implementación desde la nube, solo se actualiza el componente objetivo sin reiniciar el propio contenedor de Greengrass.

En la práctica, esto significa ciclos de actualización más rápidos con menos interrupciones: la actualización de un componente tarda segundos sin interrumpir otros componentes en ejecución ni la conectividad a la nube del dispositivo, mientras que la actualización de un contenedor requiere extraer una nueva imagen, detener y reiniciar el servicio (lo que lo interrumpe temporalmente y consume más ancho de banda). En el caso de cambios pequeños y frecuentes en la lógica de las aplicaciones, las actualizaciones a nivel de proceso reducen tanto el tiempo de implementación como el riesgo.

Azure IoT Edge y comparación con AWS IoT Greengrass

Cuando las limitaciones del enfoque independiente de la nube se convierten en obstáculos, entran en escena los orquestadores de edge computing. Ambos Azure IoT Edge y AWS Greengrass V2 ofrecen tiempos de ejecución que se ejecuta en el dispositivo y permiten capacidades que son difíciles de crear desde cero.

Azure IoT Edge Architecture

Azure IoT Edge se extiende Azure IoT Center capacidades avanzadas a través de tres componentes principales:

IoT Perimetral Security Demon (aziot-edged): administra el ciclo de vida de los módulos, la comunicación segura y la identidad del dispositivo.
Agente perimetral ($EdgeAgent): recibe instrucciones de implementación de la nube y administra qué módulos deben ejecutarse en el dispositivo.
Borde del cubo ($EdgeHub): actúa como un proxy local para IoT Hub y gestiona el enrutamiento de mensajes entre los módulos y hacia la nube, incluido el «almacenamiento y reenvío» (almacenamiento en búfer sin conexión) cuando se pierde la conectividad.

La ejecución de IoT Edge dentro de un contenedor requiere habilitarse systemd y una gestión cuidadosa del config.toml generación a partir de variables de entorno. Esto añade complejidad, pero habilita todas las capacidades de orquestación.

Implementación de módulos desde la nube

Una de las ventajas más importantes de IoT Edge es la implementación de módulos sin tocar la imagen del dispositivo base. The work flow:

Cree el módulo como Contenedor Docker.
Empuja hasta un registro (Azure container registry, Docker Hub)
Configurar el manifiesto de despliegue in Azure Portal (o mediante la CLI de Azure).
El Agente perimetral extrae y ejecuta el módulo automáticamente.

AWS Greengrass: arquitectura y conceptos clave

AWS IoT Greengrass V2 ofrece capacidades similares con una arquitectura diferente. Mientras que Azure IoT Edge se basa en una arquitectura de microservicios con varios demonios administrados por systemd, Greengrass se basa en un único tiempo de ejecución (el Greengrass Core) que actúa como el motor principal del dispositivo.

The Core of Greengrass es un proceso de JVM que administra todo el ciclo de vida de los componentes: instalación, inicio, supervisión y actualizaciones. Se comunica con AWS IoT Core para recibir instrucciones de implementación e informar sobre el estado del dispositivo. IoT Core gestiona la comunicación de los dispositivos con la nube y Greengrass la extiende hasta el borde mediante la ejecución del software localmente en el dispositivo. Todos los dispositivos de Greengrass también son un núcleo de IoT cosa.

Components son la unidad de despliegue en Greengrass. Pueden ser:

Procesos nativos (script, archivos binarios) que se ejecuta directamente en el dispositivo.
Contenedores Docker gestionado por el componente de gestión de aplicaciones de Docker.
Lambda Functions desplegado en el borde.

Cada componente tiene un receta (YAML o JSON) que define su ciclo de vida, dependencias y configuración. Cuando un despliegue se crea desde la nube, Nucleus descarga solo los componentes actualizados y administra su ciclo de vida sin reiniciarse.

Greengrass tiende a ser más «amigable con los contenedores» porque no depende de systemd como proceso de inicio. El Nucleus es un proceso independiente de Java que puede ejecutarse directamente sin necesidad de un sistema de inicio completo, lo que simplifica la contenedorización.

Administración de flotas: opciones y consideraciones

Independientemente del enfoque de conectividad que se elija, administrar las actualizaciones del sistema operativo y los dispositivos a escala sigue siendo un desafío. Existen varias opciones, cada una con diferentes ventajas y desventajas.

El problema de la gestión de la flota

La administración de cientos de dispositivos periféricos distribuidos en diferentes ubicaciones presenta desafíos específicos:

Despliegue las actualizaciones de forma segura sin acceso físico.
Gestione las reversiones cuando se produzca un error en una actualización.
Configure los dispositivos de forma individual sin mantener imágenes separadas.
Monitorización del estado de la flota en tiempo real.

Enfoques disponibles

Plataformas de gestión de flotas dedicadas (por ejemplo, Balena): proporcione actualizaciones OTA atómicas tanto a nivel de sistema operativo como de aplicación, actualizaciones delta para minimizar el ancho de banda, configuración remota y capacidades de reversión. Abstraen gran parte de la complejidad, pero introducen la dependencia de la plataforma.
Orchestrator Nate Administration (por ejemplo, AWS Greengrass o Azure IoT Edge): utiliza las capacidades de implementación del orquestador de la nube para administrar el software del dispositivo. Si bien este enfoque reduce la cantidad de herramientas externas al permanecer en un único ecosistema, normalmente se limita a la capa de aplicación (contenedores o componentes). Esto deja las actualizaciones del sistema operativo anfitrión, el estado del kernel y la recuperación del sistema a bajo nivel como desafíos independientes que aún deben abordarse.
Soluciones personalizadas: Cree mecanismos de actualización adaptados a los requisitos específicos. Ofrece la máxima flexibilidad, pero requiere un importante esfuerzo de desarrollo y pruebas. Tiene sentido para despliegues altamente especializados o cuando las herramientas existentes no cumplen con las restricciones.

La elección depende del tamaño de la flota, la frecuencia de actualización, los patrones de conectividad y la complejidad operativa que el equipo pueda absorber.

Casos de uso: elegir el enfoque correcto

La elección de la arquitectura depende fundamentalmente del caso de uso. Estos son algunos escenarios y el enfoque recomendado para cada uno.

Caso 1: Monitorización ambiental

Escenario: Los sensores distribuidos informan sobre la temperatura, la humedad y la calidad del aire cada cinco minutos. Conectividad WiFi estable. No se requiere procesamiento local.

Enfoque recomendado: Cloud independient client (MQTT/AMQP direct)

¿Por qué?: La simplicidad es suficiente. No se necesitan capacidades avanzadas sin conexión con una conectividad estable. El bajo consumo de recursos permite utilizar hardware más económico. El intervalo significa que perder algunos mensajes durante las reconexiones no es fundamental.

Caso 2: Telemetría de equipos industriales

Escenario: Los dispositivos se instalan en obras de construcción o plantas de fabricación y dependen de la conectividad celular. Los datos de telemetría se utilizan para el mantenimiento predictivo, y no es aceptable perder datos durante las interrupciones.

Enfoque recomendado: Azure IoT Edge o AWS Greengrass (lo ideal es combinarlo con una plataforma de administración de flotas dedicada)

¿Por qué?: El almacenamiento y reenvío nativos garantiza que la telemetría recopilada durante las interrupciones se conserve y cargue una vez que se restablezca la conectividad. La capacidad de implementar actualizaciones lógicas de forma remota permite que los modelos de mantenimiento y las reglas de procesamiento de datos evolucionen sin reemplazar las imágenes de los dispositivos ni requerir la intervención in situ.

Consideraciones y lecciones aprendidas

La implementación de sistemas de IoT a escala plantea desafíos que no siempre son obvios durante la creación de prototipos. Las siguientes consideraciones surgieron de implementaciones reales y deberían servir de base para la toma de decisiones de arquitectura en las primeras etapas del proceso.

Planeación de recursos

Los presupuestos de memoria son limitaciones reales: Los orquestadores Edge consumen aproximadamente 500 MB cuando están inactivos. En los dispositivos con poca RAM, la capacidad para las cargas de trabajo de las aplicaciones es limitada.‍
Almacenamiento para almacenamiento en búfer sin conexión: Almacenar y reenviar requiere espacio en disco. Calcule el volumen de mensajes esperado durante la duración máxima esperada de la interrupción y añada un margen.

Estrategias de actualización e implementación

Los despliegues canarios son esenciales a gran escala: Nunca publiques actualizaciones en toda una flota de forma simultánea. Comience con un porcentaje pequeño (por ejemplo, un 10%), supervise si hay problemas y luego amplíe gradualmente.
La reversión debe ser automática y debe probarse: Defina comprobaciones de estado claras que activen la reversión automática. Pruebe el mecanismo de reversión con el mismo rigor que el mecanismo de actualización.
Las actualizaciones de Delta son importantes sobre las redes restringidas: Los planos de datos móviles suelen ser medios o tienen limitaciones de ancho de banda. Transferir imágenes completas para realizar cambios menores es lento y derrochador.‍
Versiones control y compatibilidad con versiones anteriores: Los formatos de carga útiles y los esquemas de comandos se deben versionar de forma expresa. El software de los dispositivos evoluciona más lentamente que los servicios en la nube, y la compatibilidad con versiones anteriores se vuelve fundamental una vez que se implementan las flotas.

Administración de seguridad y credenciales

El almacenamiento de certificados requiere un diseño cuidadoso: Los certificados X.509 para la autenticación en la nube deben almacenarse de forma segura en el dispositivo. Las opciones incluyen sistemas de archivos cifrados o variables de entorno que se inyectan en tiempo de ejecución. Cada una tiene diferentes ventajas y desventajas operativas y de seguridad.‍
Principio de mínimo privilegio: Cada dispositivo solo debe tener permisos para lo que necesite. Evite compartir las credenciales entre dispositivos (poner en peligro un dispositivo no debería comprometer la flota).

Conectividad y resiliencia

Suponga que la conectividad fallará: Diseñe para una conectividad intermitente desde el principio, incluso si la implementación actual cuenta con redes confiables.‍
Consideraciones sobre el proxy y el firewall: Los entornos empresariales suelen requerir que el tráfico pase a través de los proxies. Asegúrese de que la pila de conectividad permita la configuración del proxy y de que los puntos finales necesarios estén incluidos en la lista blanca.

Visibilidad operativa

Register and Metrics Collation: Decida con antelación cómo se recopilarán los registros y las métricas de los dispositivos. Almacenamiento local, carga por lotes, transmisión en tiempo real (cada uno tiene implicaciones de ancho de banda y almacenamiento).‍
Capacidades de depuración remota: Cuando algo falla en un sitio remoto, ¿cómo se diagnosticará? Planifique el acceso remoto al shell, la recuperación de registros y los comandos de diagnóstico.

Conclusión

Las tres preguntas planteadas al principio de este post (cómo conectarse, cómo actualizar y cómo administrar) no tienen una sola respuesta. Sin embargo, tienen un marco de decisión claro.

Para Conectividad en la nube, las opciones van desde clientes MQTT/AMQP directos hasta orquestadores de borde completo como Azure IoT Edge o AWS Greengrass. El enfoque independiente de la nube ofrece simplicidad, flexibilidad y un bajo consumo de recursos (ideal para prototipos, MVP y escenarios con conectividad estable). Los orquestadores perimetrales añaden complejidad y sobrecarga de recursos, pero proporcionan capacidades comprobadas: funcionamiento sin conexión, implementación remota de módulos y procesamiento local. El costo adicional se justifica cuando estos requisitos son críticos.

Para Gestión de flotas, las opciones incluyen plataformas dedicadas, herramientas de orquestación o soluciones personalizadas. Cada una conlleva diferentes ventajas y desventajas en cuanto a la complejidad operativa, la dependencia del proveedor y el esfuerzo de desarrollo. La elección debe evaluarse independientemente del enfoque de conectividad.

Más allá de la arquitectura, consideraciones prácticas en torno a la planificación de recursos, las estrategias de implementación, la seguridad y la visibilidad operativa, a menudo determinan el éxito o el fracaso a gran escala. Estas preocupaciones deben servir de base para la toma de decisiones desde el principio, no después de la implementación.

No existe una solución universal. La elección correcta depende de las condiciones de conectividad, las limitaciones de recursos, los requisitos de actualización, la postura de seguridad, la experiencia del equipo y las capacidades operativas. Comprender las opciones disponibles (y las consideraciones prácticas que conllevan la escalabilidad) es el primer paso para tomar una decisión informada.