Un broker MQTT dedicado da a un único cliente un clúster de broker aislado en lugar de una porción de uno compartido, de modo que el rendimiento y la capacidad quedan reservados solo para tu flota. Esta guía explica qué te aporta el aislamiento, las señales de que un nivel serverless se te ha quedado pequeño, cómo planificar la capacidad antes del cambio y una checklist práctica para pasar de ConnectMQ Serverless a Dedicated.
Qué es un broker MQTT dedicado
En un nivel serverless, muchos clientes comparten un clúster y se separan lógicamente mediante credenciales, espacios de nombres de topics y cuotas. Un despliegue dedicado elimina esa compartición: el proveedor opera un clúster de broker que solo atiende a tu organización. Sigues sin gestionar servidores, sistemas operativos ni certificados, porque sigue siendo un broker MQTT gestionado, pero el cómputo, la memoria y la red detrás de tu endpoint no se comparten con nadie.
Esa distinción importa menos de lo que se suele pensar en flotas pequeñas y mucho más de lo esperado en flotas grandes o sensibles a la latencia. Si todavía estás decidiendo entre modelos de hosting a alto nivel, la guía principal de broker MQTT en la nube explica el panorama completo.
Qué te aporta el aislamiento
Rendimiento predecible
En un clúster compartido, las cuotas impiden que un solo cliente monopolice los recursos, pero tu tráfico sigue circulando junto al de todos los demás. Con un broker MQTT dedicado, un pico de otra empresa sencillamente no puede afectarte. La latencia y el rendimiento dependen de tu propia carga, lo que hace que el comportamiento sea más fácil de razonar y de probar.
Margen de capacidad que puedes planificar
Los niveles compartidos tienen cuotas fijas por plan. Un clúster dedicado se dimensiona para tu carga esperada, así que planificas el margen de forma deliberada en lugar de toparte con un techo pensado para el cliente medio.
Un argumento de seguridad y cumplimiento más limpio
Algunas revisiones de seguridad hacen una pregunta sencilla: ¿el tráfico de algún otro cliente pasa por el mismo proceso de broker? Con un hosting dedicado, la respuesta es no. Eso suele acortar las conversaciones de compras, aunque el nivel compartido estuviera técnicamente bien aislado.
Menos restricciones de diseño
Un fan-out amplio, muchos consumidores de backend en suscripciones compartidas, payloads más grandes y flujos con QoS 2 son más fáciles de acomodar cuando el clúster es tuyo.
Señales de que serverless se te ha quedado pequeño
Vigila estas señales. Una sola no es necesariamente motivo para cambiar; varias a la vez normalmente sí.
| Señal | Qué ves | Por qué importa |
|---|---|---|
| Techo de conexiones | Conexiones rechazadas, código de motivo 0x97 | Los dispositivos no pueden conectarse |
| Tasa de mensajes alta y constante | Rendimiento constante todo el día | Pagas por capacidad compartida que en la práctica usas siempre |
| Sensibilidad a la latencia | Bucles de control, alarmas, interfaces de operador | La variabilidad duele más que la media |
| Requisitos de compras | Preguntas sobre infraestructura compartida | El aislamiento simplifica la respuesta |
| Plan de crecimiento de la flota | Miles de dispositivos en la hoja de ruta | Mejor migrar antes de las prisas |
| Muchos consumidores de backend | Varios servicios suscritos a los mismos flujos | El fan-out multiplica la carga |
El plan Serverless (Paid) de ConnectMQ admite hasta 1.000 conexiones, QoS 2, mensajes de 1 MB y suscripciones compartidas, lo que es suficiente para muchos productos. Dedicated es para cuando quieres tu propio clúster aislado en lugar de cuotas más altas en uno compartido.
Planificación de capacidad para un despliegue dedicado
Una buena planificación de capacidad parte de tus dispositivos, no de benchmarks de brokers. Trabaja estas cifras y anótalas; son las que discutirás al dimensionar tu clúster.
- Pico de conexiones simultáneas. Cuentan los dispositivos, gateways, servicios de backend, paneles y herramientas de prueba. Añade el caso de tormenta de reconexiones: tras una caída de red, todos los dispositivos se reconectan en una ventana corta.
- Mensajes por segundo, de entrada. Multiplica los dispositivos por la frecuencia de publicación. 2.000 dispositivos con un mensaje cada 10 segundos son 200 mensajes por segundo de media, pero la alineación (dispositivos que reportan en el minuto exacto) genera picos.
- Fan-out, de salida. Cada mensaje publicado se entrega una vez por cada suscripción coincidente. Un mensaje que leen un panel, un historiador y un servicio de alertas son tres entregas.
- Tamaño del payload. Medio y máximo. Los payloads JSON compactos o binarios reducen el ancho de banda y la memoria del broker.
- Mezcla de QoS. QoS 1 y 2 añaden tráfico de confirmación y estado en vuelo frente a QoS 0. Consulta los niveles de QoS de MQTT explicados.
- Estado de sesión. Las sesiones persistentes con mensajes en cola para clientes desconectados consumen memoria. Configura la caducidad de sesión para que no se acumulen sesiones abandonadas.
- Retained messages. Un mensaje retenido por topic de estado es barato; millones de topics retenidos obsoletos no lo son.
- Crecimiento. Planifica para los próximos 12 a 18 meses de crecimiento de la flota, no para el recuento actual.
Una hoja de dimensionamiento sencilla en texto plano ayuda a alinear al equipo:
Peak devices online ............ 3,000
Backend/dashboard clients ...... 40
Reconnect storm window ......... 120 s
Avg publish interval ........... 15 s -> ~200 msg/s inbound
Avg subscribers per message .... 2 -> ~400 msg/s outbound
Avg payload .................... 350 bytes
QoS ............................ 1 (telemetry), 2 (commands)
Retained topics ................ ~3,000 (one status topic per device)
Session expiry ................. 1 hour
Growth target (18 months) ...... 3x
Mide antes de migrar
Antes de cambiar, recopila cifras reales de tu broker serverless. Un pequeño suscriptor en Python que cuente los mensajes por topic de primer nivel te da una línea base rápida.
import collections
import ssl
import time
import paho.mqtt.client as mqtt
counts = collections.Counter()
start = time.time()
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe("#", qos=0)
def on_message(client, userdata, msg):
counts[msg.topic.split("/")[0]] += 1
elapsed = time.time() - start
if elapsed >= 60:
for prefix, n in counts.most_common():
print(f"{prefix:20s} {n / elapsed:8.2f} msg/s")
counts.clear()
globals()["start"] = time.time()
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(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()
Combínalo con el panel del portal y con el topic $SYS/broker/connection/{clientId}/state, que indica si un cliente concreto está conectado, para entender tanto el tráfico como el comportamiento de las conexiones.
Checklist de migración: de Serverless a Dedicated
Como un broker MQTT dedicado habla el mismo protocolo MQTT 3.1.1 y 5.0 en los mismos puertos (1883, 8883, 8083 y 8084 con /mqtt), la migración es sobre todo un ejercicio de configuración.
- Haz configurable el endpoint. Si el nombre de host, el puerto, el usuario, la contraseña y el client ID están compilados en el firmware, arregla eso primero. Guárdalos en NVS, en un archivo de configuración o en los datos de aprovisionamiento.
- Solicita y aprovisiona el broker dedicado. Obtén nuevas credenciales en el portal para el entorno dedicado.
- Mueve primero los consumidores de backend. Apunta una copia de cada servicio de backend al nuevo broker y verifica que recibe tráfico de prueba.
- Haz de puente durante la transición con tu propia herramienta. Si los dispositivos van a migrar a lo largo de días o semanas, ejecuta un pequeño relé (Node-RED o un script corto en Python) que se suscriba en el broker antiguo y republique en el nuevo. ConnectMQ no ofrece bridges integrados, así que esto se hace con un cliente MQTT externo.
- Migra los dispositivos por oleadas. Actualiza un pequeño porcentaje, vigila el estado de las conexiones y los logs de errores, y continúa.
- Vuelve a publicar el estado retenido. Los retained messages no se trasladan automáticamente; haz que los dispositivos publiquen su estado actual al conectarse.
- Retira el broker antiguo. Cuando el antiguo ya no muestre conexiones de dispositivos, detén el relé y desmantélalo.
Errores habituales: olvidarse de paneles y scripts que siguen apuntando al nombre de host antiguo, client IDs codificados a mano que colisionan entre entornos y estado retenido que falta tras el cambio. Merece la pena leer a la vez nuestra guía de buenas prácticas de seguridad en MQTT, ya que las migraciones son un momento natural para rotar credenciales.
¿Dedicated, BYOC o Enterprise?
Dedicated no es la única opción aislada. Si tu organización necesita que el broker se ejecute en su propia cuenta en la nube, BYOC lo despliega allí mientras ConnectMQ lo gestiona. Si debes operarlo todo tú mismo, Self Managed Enterprise cubre ese caso. La guía de broker MQTT empresarial compara estos modelos con los requisitos empresariales típicos.
Pasa a un broker dedicado con ConnectMQ
La mayoría de los equipos empieza con el plan Serverless gratuito en app.connectmq.com (sin tarjeta de crédito), mide el tráfico real y pasa a un clúster Dedicated cuando el aislamiento y el margen se convierten en prioridades. ConnectMQ mantiene los mismos protocolos, puertos y herramientas del portal en todos los planes, así que tus dispositivos, el explorador de topics, los paneles y las reglas de alerta siguen funcionando igual después del cambio. Para pruebas rápidas de clientes sin cuenta, el servidor MQTT público gratuito en broker.connectmq.com sigue disponible, siempre solo con datos de prueba, nunca de producción.
Preguntas frecuentes
¿Es un broker MQTT dedicado más rápido que serverless?
No necesariamente en promedio, pero sí es más predecible porque ningún otro cliente comparte el clúster. La ventaja se nota sobre todo con carga sostenida y durante los picos.
¿Tengo que reescribir el firmware de los dispositivos para pasar a dedicado?
No, si los ajustes de conexión son configurables. El protocolo y los puertos son los mismos, así que solo cambian el nombre de host y las credenciales.
¿Puedo conservar un broker serverless después de pasar a dedicado?
Sí. Muchos equipos mantienen un broker serverless gratuito para desarrollo y pruebas y ejecutan la producción en el clúster dedicado.
¿Un broker dedicado incluye replicación entre regiones?
No lo des por hecho. Pregunta por el despliegue concreto y diseña los dispositivos para que se reconecten con backoff y vuelvan a publicar su estado, de modo que se recuperen limpiamente de cualquier reinicio del broker.
