Broker MQTT como servicio: qué obtienes y qué no

Un broker MQTT como servicio te da un endpoint de broker funcional y protegido sin que tengas que instalar, parchear ni monitorizar un servidor. Este artículo explica exactamente qué responsabilidades pasan al proveedor, cuáles siguen siendo tuyas y cómo construir las piezas que un broker no incluye, para que tengas las expectativas correctas antes de registrarte.

Qué significa "broker MQTT como servicio"

Como servicio significa que consumes el broker como un endpoint, no como un software que ejecutas tú; en la práctica, es un broker MQTT gestionado. Recibes un nombre de host, puertos, credenciales y un portal de gestión. El proveedor se encarga de las máquinas, del software del broker, de los certificados TLS y de los procesos operativos que hay detrás. Conectas dispositivos y aplicaciones con MQTT estándar, exactamente igual que lo harías con un broker alojado por ti.

Este último punto es importante. Como MQTT es un estándar abierto, las mismas bibliotecas cliente, el mismo firmware y las mismas herramientas funcionan tanto si el broker corre en una Raspberry Pi de tu oficina como en la nube de un proveedor. Si eres nuevo en el protocolo, empieza por qué hace un broker MQTT.

El reparto de responsabilidades

La tabla siguiente muestra un reparto típico. La columna de la derecha usa ConnectMQ como referencia concreta.

Qué obtienes

Sin servidores que operar

Nunca instalas Mosquitto, ni configuras unidades de systemd, ni subes los límites de descriptores de archivo, ni programas parches del sistema operativo. En los planes Serverless tampoco tienes que pensar en el dimensionamiento de máquinas; eliges un plan con los límites que necesitas.

Valores de seguridad por defecto difíciles de configurar mal

TLS está listo desde el primer día con un certificado de confianza pública, las credenciales se generan en lugar de elegirse a mano y los client IDs quedan vinculados a las credenciales emitidas para ellos. Los intentos de inicio de sesión por fuerza bruta provocan el bloqueo de la IP. Los brokers autoalojados a menudo se lanzan sin algunas de estas protecciones y las añaden más tarde. Nuestro artículo sobre buenas prácticas de seguridad en MQTT cubre la parte del cliente de esta misma historia.

Límites predecibles

Los planes tienen límites publicados. En ConnectMQ, el plan Serverless (Free) permite hasta 25 conexiones, QoS hasta 1 y mensajes de 256 KB; el plan Serverless de pago permite hasta 1.000 conexiones, QoS 2, mensajes de 1 MB y suscripciones compartidas. Dedicated, BYOC y Self Managed Enterprise cubren despliegues aislados y controlados por el cliente.

Herramientas para ver lo que ocurre

Un broker en el que no puedes ver nada es difícil de depurar. Un buen servicio te permite publicar mensajes de prueba, observar topics en vivo, ver qué dispositivos están conectados y recibir avisos cuando los valores cruzan un umbral, todo desde un navegador.

Qué no obtienes

Tenerlo claro evita decepciones más adelante.

Un broker no es una base de datos. Enruta mensajes; no guarda histórico. Los retained messages solo almacenan el último valor de cada topic. Si necesitas gráficas a lo largo del tiempo, necesitas una base de datos de series temporales o un historiador.

Un broker no es una plataforma de integración. Algunas plataformas IoT incluyen motores de reglas, webhooks y conectores a bases de datos u otras nubes. Un broker como servicio puro, ConnectMQ incluido, no lo hace. Construyes las integraciones ejecutando un cliente que se suscribe y reenvía.

Un broker no hace fiables a los clientes. La lógica de reconexión, el buffering local, los comandos idempotentes y una elección sensata de QoS viven en tu código. Consulta alta disponibilidad del broker MQTT para ver patrones del lado del cliente.

Un broker no diseña tus topics. Un espacio de nombres claro es tarea tuya, y de él depende lo fácil que resulte todo lo demás.

El patrón de integración: suscribirse y reenviar

La forma honesta y portable de conectar un broker como servicio con el resto de tu stack es un pequeño proceso suscriptor. Funciona con cualquier broker y te deja libre para cambiar de base de datos o de proveedor más adelante. Aquí tienes un ejemplo completo en Python que guarda cada mensaje de telemetría en SQLite. Cambia SQLite por PostgreSQL, InfluxDB o un archivo según lo necesites.

# store_telemetry.py - suscribirse a la telemetría y guardarla en SQLite
import json
import sqlite3
import time

import paho.mqtt.client as mqtt

DB = sqlite3.connect("telemetry.db", check_same_thread=False)
DB.execute("""CREATE TABLE IF NOT EXISTS telemetry (
                ts REAL, topic TEXT, payload TEXT)""")
DB.commit()

def on_connect(client, userdata, flags, reason_code, properties):
    print("connected:", reason_code)
    client.subscribe("acme/+/+/+/+/telemetry", qos=1)

def on_message(client, userdata, msg):
    try:
        payload = json.dumps(json.loads(msg.payload))   # validar JSON
    except ValueError:
        print("skipping non-JSON message on", msg.topic)
        return
    DB.execute("INSERT INTO telemetry VALUES (?, ?, ?)",
               (time.time(), msg.topic, payload))
    DB.commit()

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id="YOUR_CLIENT_ID", protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

El mismo patrón se aplica a las herramientas low-code. Node-RED se conecta con un nodo de configuración mqtt-broker, Telegraf usa su entrada de consumidor MQTT y Home Assistant usa su integración MQTT. Cada una es simplemente otro cliente MQTT del broker.

Elegir el nivel de servicio adecuado

Si estás comparando un servicio con operar tu propio broker, lee broker MQTT autoalojado vs. gestionado y comparativa de opciones de hosting de brokers MQTT. La guía de broker MQTT en la nube es la visión general de todo este tema.

Preguntas que hacer antes de elegir un proveedor

1. ¿Qué versiones de MQTT y qué transportes se admiten?
2. ¿Cuáles son los límites exactos de conexiones, tamaño de mensaje y QoS en cada plan?
3. ¿Cómo se emiten, rotan y revocan las credenciales?
4. ¿Cómo notifica el servicio a los clientes las infracciones de cuota?
5. ¿Qué herramientas de visibilidad se incluyen?
6. ¿Qué no se incluye, como almacenamiento, motores de reglas o conectores?
7. ¿Qué opciones de aislamiento existen más allá de los planes compartidos?
8. ¿Cuáles son las condiciones del SLA, por escrito?
9. ¿Qué tan fácil es marcharse, dado que los dispositivos solo conocen un nombre de host y unas credenciales?

Prueba MQTT como servicio con ConnectMQ

ConnectMQ se encarga del broker, de TLS y de las cuotas para que tú te centres en los dispositivos y los datos. Regístrate en app.connectmq.com, crea un broker en el plan Serverless gratuito sin tarjeta de crédito y conecta tu primer cliente en minutos.

Preguntas frecuentes

¿Qué incluye un broker MQTT como servicio?

Normalmente, el software del broker, los servidores, el parcheo, los certificados TLS, los endpoints, las credenciales, las cuotas y un portal de gestión. Tú sigues siendo responsable de los dispositivos, los topics, los payloads y el almacenamiento de datos.

¿Un broker MQTT gestionado almacena mis datos?

Un broker enruta mensajes y solo conserva los últimos valores retenidos de cada topic. Para tener histórico, ejecuta un suscriptor que escriba los mensajes en una base de datos que controles.

¿Puedo conectar Node-RED o Telegraf a un broker como servicio?

Sí. Se conectan como clientes MQTT normales usando el nombre de host, el puerto y las credenciales del portal, y después reenvían los datos a donde los necesites.

¿Es difícil dejar un broker MQTT como servicio?

Como MQTT es un estándar, los dispositivos solo necesitan un nuevo nombre de host y nuevas credenciales. Evitar funciones propietarias mantiene bajo el coste de cambiar.