La pregunta plataforma IoT vs broker MQTT confunde a muchos equipos porque ambos se solapan y los proveedores usan los términos con poca precisión. Este artículo separa claramente las capas, explica qué añade una plataforma IoT completa sobre un broker y te da una forma práctica de decidir si necesitas una plataforma o si un broker MQTT gestionado ligero con unas pocas herramientas abiertas cubre tu proyecto.
Dos capas distintas
Un broker MQTT es un enrutador de mensajes. Los clientes se conectan, publican mensajes en topics y se suscriben a topics; el broker entrega cada mensaje a todos los suscriptores que coinciden, con el QoS solicitado. Gestiona sesiones, retained messages, mensajes de última voluntad (will) y, con MQTT 5, funciones como las suscripciones compartidas y la caducidad de mensajes. Si necesitas un repaso, lee qué hace un broker MQTT.
Una plataforma IoT es un conjunto de servicios construidos alrededor de un núcleo de mensajería. Según el producto, añade algunos o todos estos elementos:
- Registro, aprovisionamiento y gestión de identidades de dispositivos.
- Servicios de estado de dispositivos, como shadows o twins.
- Orquestación de actualizaciones de firmware OTA.
- Rules engines que filtran, transforman y enrutan datos.
- Almacenamiento de series temporales y consultas históricas.
- Dashboards, alarmas y notificaciones.
- Gestión de usuarios, multi-tenancy para tus propios clientes y API de aplicación.
Muchas plataformas incluyen un endpoint MQTT, a veces un broker completo y a veces un gateway de dispositivo a nube con topics fijos. El valor de la plataforma está en la integración de todas esas piezas.
Plataforma IoT vs broker MQTT: comparación
| Capacidad | Solo broker MQTT | Plataforma IoT completa | Broker ligero más herramientas abiertas |
|---|---|---|---|
| Pub/sub en tiempo real | Sí | Normalmente, a veces solo de dispositivo a nube | Sí |
| Identidad de dispositivos | Credenciales por cliente | Registro con ciclo de vida | Credenciales más tu propio inventario |
| Estado de dispositivos | Retained messages | Servicio de shadow o twin | Topics de estado retenidos |
| Procesamiento de datos | No | Reglas integradas | Node-RED, pequeños servicios |
| Almacenamiento e histórico | No | Integrado | InfluxDB, TimescaleDB, PostgreSQL |
| Dashboards | Solo la consola del broker | Integrados | Grafana, Node-RED Dashboard |
| Alertas | Depende del broker | Integradas | Alertas del broker o alertas de Grafana |
| Actualizaciones de firmware | No | A menudo integradas | Herramientas OTA aparte |
| Portabilidad | Alta | A menudo menor | Alta |
| Esfuerzo para empezar | Bajo | De bajo a medio | Medio |
La columna central es cómoda y viene con opiniones propias. La de la derecha requiere algo más de montaje, pero deja cada pieza sustituible.
Cuándo una plataforma IoT completa es la opción adecuada
Una plataforma justifica su coste y sus restricciones cuando:
- Necesitas gestionar el ciclo de vida de los dispositivos a gran escala, con aprovisionamiento masivo, rotación de certificados y actualizaciones OTA escalonadas para muchos tipos de dispositivos.
- Te faltan personas para integrar componentes y quieres que un único proveedor sea responsable de todo el stack.
- Tu back end ya vive en la nube de esa plataforma y quieres que los datos lleguen allí con el mínimo código intermedio.
- Estás construyendo un producto para múltiples clientes y el modelo de tenants, usuarios y API de la plataforma coincide con el tuyo.
En estos casos, elige la plataforma de forma deliberada y lee vendor lock-in en MQTT para mantener el firmware de los dispositivos tan portable como sea posible.
Cuándo basta un broker ligero
Un broker MQTT gestionado con unas pocas herramientas abiertas suele ser la mejor opción cuando:
- Tu necesidad principal es mover datos en vivo entre máquinas, gateways, aplicaciones y dashboards.
- Ya utilizas herramientas como Node-RED, Grafana, Telegraf o una base de datos de series temporales.
- Estás construyendo un Unified Namespace y quieres controlar por completo la jerarquía de topics.
- Valoras la portabilidad entre nubes y sistemas on-premises.
- Tu flota es modesta y la gestión de dispositivos puede resolverse con un inventario sencillo.
ConnectMQ está diseñado para este patrón. Es un broker MQTT gestionado con MQTT 3.1.1 y 5.0, TLS y Secure WebSocket, y un portal que cubre varios aspectos básicos "de plataforma" sin llegar a ser una plataforma: un cliente MQTT en el navegador, explorador de topics en vivo, dashboard, vista de dispositivos por niveles ISA-95, reglas de alerta por umbral con registro de alertas, y decodificación de Sparkplug B con republicación en topics ISA-95. Deliberadamente no incluye rule engine, webhooks ni bridges a bases de datos; esas tareas se dejan a herramientas externas.
Una arquitectura de referencia ligera
Un stack habitual y totalmente abierto alrededor de un broker MQTT gestionado tiene este aspecto:
Devices / PLC gateways --MQTT/TLS--> Managed MQTT broker (ConnectMQ)
|
+-------------------------------+-----------------------------+
| | |
Telegraf (mqtt_consumer) Node-RED flows Browser apps (WSS 8084)
| (logic, alerts, APIs)
InfluxDB (time series)
|
Grafana (dashboards, alerting)
Cada componente se conecta al broker como un cliente MQTT normal. Puedes sustituir cualquiera de ellos sin tocar los dispositivos. Lo mismo ocurre si más adelante añades un gemelo digital 3D en el navegador: se suscribe por Secure WebSocket como cualquier otra app.
Ejemplo: almacenar telemetría con Telegraf
El input de consumidor MQTT de Telegraf puede suscribirse a tu broker y escribir en InfluxDB solo con configuración:
# telegraf.conf
[[inputs.mqtt_consumer]]
servers = ["ssl://broker.connectmq.com:8883"]
topics = ["acme/plant1/+/+/telemetry"]
qos = 1
client_id = "YOUR_CLIENT_ID"
username = "YOUR_USERNAME"
password = "YOUR_PASSWORD"
data_format = "json"
topic_tag = "topic"
[[outputs.influxdb_v2]]
urls = ["http://localhost:8086"]
token = "${INFLUX_TOKEN}"
organization = "acme"
bucket = "telemetry"
Arráncalo y comprueba que llegan los puntos:
export INFLUX_TOKEN=your-influx-token
telegraf --config telegraf.conf --test # one-shot parse check
telegraf --config telegraf.conf # run continuously
Con payloads JSON como {"temp": 72.4, "rpm": 1450}, los campos numéricos se convierten en campos de InfluxDB y el topic en un tag por el que puedes filtrar en Grafana. Recuerda que cada conexión simultánea necesita sus propias credenciales y su propio client ID; en ConnectMQ, los client IDs están vinculados a las credenciales emitidas.
Costes ocultos en ambos lados
Ningún camino está libre de contrapartidas, y conviene ponerles nombre antes de decidir.
Con una plataforma completa, los costes ocultos suelen ser conceptuales y contractuales. Tu equipo aprende el modelo de dispositivos, reglas y estado de la plataforma, y ese conocimiento no se traslada a otro sitio. Los precios suelen crecer en varias dimensiones a la vez, como conexiones, mensajes, ejecuciones de reglas y almacenamiento, lo que dificulta las previsiones. Y las funciones que no usas siguen condicionando cómo diseñas las que sí usas.
Con un broker ligero más herramientas, los costes ocultos son operativos. Alguien tiene que ejecutar Node-RED, la base de datos de series temporales y Grafana, mantenerlos actualizados y hacer copias de seguridad. Las decisiones de integración, como la nomenclatura de topics y los formatos de payload, te corresponde documentarlas y hacerlas cumplir. Para un equipo pequeño es manejable; para una organización grande sin equipo de plataforma puede acabar dispersándose.
La prueba práctica es esbozar los próximos dos años: cuántos dispositivos, qué destinos de datos y quién mantiene cada pieza. La opción cuya carga de mantenimiento encaja con tu equipo suele ser la correcta.
Lista de decisión
Responde a cada pregunta con sí o no:
- ¿Necesitas orquestar actualizaciones de firmware OTA en una flota grande desde una única consola?
- ¿Necesitas un registro de dispositivos con estados de ciclo de vida, más allá de una lista de credenciales?
- ¿Deben llegar los datos automáticamente a los servicios de una nube concreta?
- ¿Te falta alguien que se maneje con soltura con Node-RED, Grafana o un pequeño servicio?
- ¿Necesitas una capa de aplicación multi-tenant ya hecha para tus propios clientes?
Mayoría de síes: evalúa plataformas IoT completas. Mayoría de noes: empieza con un broker MQTT gestionado ligero y añade herramientas a medida que surjan las necesidades. Muchos equipos combinan ambas cosas: usan un broker como columna vertebral neutral en tiempo real y una plataforma para una tarea concreta, como las actualizaciones OTA.
Para comparaciones más detalladas, consulta alternativa a AWS IoT Core y alternativa a Azure IoT Hub, que analizan dos plataformas conocidas desde esta perspectiva.
Empieza con un broker MQTT gestionado ligero
Puedes validar el enfoque ligero en una tarde. Crea un broker Serverless gratuito sin tarjeta de crédito, conecta un dispositivo y apunta Telegraf o Node-RED hacia él. La guía de brokers MQTT en la nube explica las opciones de despliegue a medida que tu proyecto crece, y en connectmq.com tienes la visión completa de los planes, desde Serverless hasta Dedicated, BYOC y Self Managed Enterprise.
Preguntas frecuentes
¿Es un broker MQTT una plataforma IoT?
No. Un broker enruta mensajes entre clientes. Una plataforma IoT combina una capa de mensajería con gestión de dispositivos, almacenamiento, reglas y dashboards.
¿Puedo construir una solución IoT solo con un broker MQTT?
Sí, con unas pocas herramientas externas. Un broker más Node-RED, una base de datos de series temporales y Grafana cubren muchos proyectos de monitorización y control.
¿Incluye ConnectMQ un rule engine o integraciones con bases de datos?
No. Las integraciones se ejecutan como clientes MQTT externos, como Node-RED, Telegraf o tus propios servicios, lo que las mantiene portables.
¿Puedo usar a la vez una plataforma IoT y un broker MQTT independiente?
Sí. Muchos equipos usan un broker neutral como columna vertebral en tiempo real y una plataforma para tareas concretas, como las actualizaciones de firmware o el aprovisionamiento de dispositivos.
