MQTT gestionado en la nube

Alternativa a Mosquitto en la nube: de Mosquitto autoalojado a un broker MQTT gestionado

Mosquitto es un broker excelente, pero ejecutarlo en un servidor público implica encargarte de TLS, usuarios, parches y disponibilidad. Esto es lo que cambia al pasar a un broker MQTT gestionado y cómo migrar de forma gradual con un bridge.

Ilustración de una alternativa a Mosquitto en la nube, con un servidor Mosquitto local que reenvía sus topics mediante bridge a un broker MQTT gestionado en la nube
Pruébalo en tu propio broker MQTTConsigue un broker MQTT privado y gestionado con el plan Free y empieza con ejemplos de código listos para usar.
Pruébalo gratis Ejemplos de código Sin tarjeta

Una alternativa a Mosquitto en la nube es lo que muchos equipos empiezan a buscar cuando su primer servidor Mosquitto autoalojado se convierte en algo de lo que dependen los clientes. Este artículo explica qué conservas, qué ganas y qué pierdes al pasar de Mosquitto autoalojado a un broker MQTT 3.1.1/5.0 gestionado, y muestra una configuración de bridge que te permite migrar instalación por instalación.

Eclipse Mosquitto se ha ganado su lugar. Es open source, ligero, está bien documentado y funciona en casi cualquier cosa, desde una Raspberry Pi hasta una VM grande. Admite MQTT 3.1.1 y 5.0, TLS, WebSockets, archivos de contraseñas, archivos ACL y bridging. Sus herramientas de línea de comandos, mosquitto_pub y mosquitto_sub, son la forma habitual en que muchos ingenieros prueban cualquier broker.

Para un laboratorio, una única vivienda o una red de planta que nunca toca Internet, Mosquitto suele ser todo lo que necesitas. La cuestión de buscar una alternativa solo surge cuando la parte operativa empieza a pesar más que la comodidad. Para una visión más amplia del panorama open source, consulta la comparativa de brokers MQTT open source.

Dónde se complica Mosquitto autoalojado

El broker rara vez es el problema. Lo es el trabajo que lo rodea:

  • Exponerlo a Internet de forma segura. Necesitas una IP pública o un nombre DNS, reglas de firewall, certificados TLS y su renovación, y la seguridad de que no se ha quedado abierto ningún listener anónimo.
  • Gestionar usuarios. mosquitto_passwd y un archivo ACL de texto funcionan para diez dispositivos. Con cientos, necesitas scripts de aprovisionamiento y una forma de revocar credenciales con rapidez.
  • Monitorización. Debes recoger las estadísticas de $SYS o los logs, almacenarlos y avisar a alguien cuando caen las conexiones.
  • Actualizaciones. Las actualizaciones de versión mayor pueden cambiar los valores por defecto. Mosquitto 2.0, por ejemplo, cambió los valores por defecto de los listeners y del acceso anónimo, lo que sorprendió a muchas instalaciones existentes.
  • Diseño de un solo nodo. Mosquitto open source se ejecuta como un único proceso de broker. Si esa máquina falla, todos los clientes se desconectan hasta que vuelva.

Nada de esto es una crítica a Mosquitto. Es simplemente el coste de operar cualquier broker por tu cuenta, que se trata con más detalle en broker MQTT autoalojado vs gestionado.

Lo que conservas con un broker MQTT gestionado

Como un broker MQTT gestionado habla el mismo protocolo estándar, casi todo lo que has construido sigue sirviendo:

  • Código cliente. Paho, MQTT.js, PubSubClient, Node-RED y las herramientas CLI de Mosquitto funcionan sin cambios, salvo el host, el puerto y las credenciales.
  • Estructura de topics. Tu árbol de topics se traslada tal cual.
  • Funciones de MQTT 5. En ConnectMQ están disponibles las suscripciones compartidas (planes de pago), retained messages, caducidad de sesión, topic aliases, caducidad de mensajes, response topics y reason codes.
  • Tus hábitos con las herramientas. Puedes seguir usando mosquitto_sub para depurar.

Lo que ganas

  • Ningún servidor que mantener. TLS en el 8883 y Secure WebSocket en el 8084 con un certificado de Let's Encrypt están listos desde el primer día.
  • Credenciales desde un portal en lugar de archivos de contraseñas. Cada broker recibe un usuario, una contraseña y un client ID generados.
  • Visibilidad integrada. El portal de ConnectMQ incluye un cliente MQTT en el navegador, un explorador de topics en vivo, un dashboard y reglas de alerta por umbral, para que veas el tráfico sin instalar herramientas adicionales.
  • Protecciones que de otro modo tendrías que construir tú, como cuotas por plan, protección contra inundaciones y bloqueo de IP tras inicios de sesión fallidos repetidos.
  • Extras industriales si te interesan: detección de topics ISA-95 / Unified Namespace y decodificación de payloads Sparkplug B.

Lo que pierdes

Sé honesto con las contrapartidas antes de migrar:

Capacidad de Mosquitto Consideración con un broker MQTT gestionado
Plugins personalizados de autenticación o ACL Usas en su lugar el modelo de autenticación del proveedor
Archivos ACL detallados por topic Comprueba qué control de acceso ofrece el servicio; ConnectMQ aísla a los tenants y vincula los client IDs a las credenciales, pero no ofrece ACL por topic
Control total de cada opción de configuración Solo se pueden ajustar los parámetros que expone el servicio
Funcionar totalmente sin conexión Un broker en la nube necesita acceso a Internet; mantén un broker local para las instalaciones sin conexión
Tamaño de mensaje ilimitado a tu elección Se aplican los límites del plan, por ejemplo 256 KB en Serverless gratuito y 1 MB en Serverless de pago

Si las ACL por topic o los plugins personalizados son centrales en tu diseño, mantén Mosquitto en el edge y usa el broker en la nube para las partes que se benefician de él.

Preguntas que conviene plantear antes al equipo

Antes de comparar proveedores, poneos de acuerdo internamente en algunos puntos. ¿Qué dispositivos deben seguir funcionando cuando cae el enlace a Internet? ¿Quién se ocupa ahora del servidor Mosquitto y a qué preferiría dedicarse? ¿Qué topics transportan comandos que cambian equipos físicos y quién debería poder publicar en ellos? ¿Cuántas conexiones simultáneas esperas dentro de un año, no solo hoy? Las respuestas deciden si necesitas un broker puramente en la nube, uno híbrido con un broker local en el edge o un despliegue dedicado, y mantienen la evaluación centrada en tus requisitos y no en listas de funciones.

Cómo evaluar una alternativa a Mosquitto en la nube

Sea cual sea el proveedor que consideres, comprueba lo siguiente en su documentación actual:

  1. Versiones del protocolo. ¿Admite MQTT 3.1.1 y 5.0, incluidas las funciones de MQTT 5 que usas?
  2. Puertos y transportes. TLS en el 8883, WebSocket y Secure WebSocket para aplicaciones de navegador.
  3. Niveles de QoS y límites de tamaño de mensaje en el plan que realmente contratarías.
  4. Comportamiento de los retained messages y de la caducidad de sesión.
  5. Modelo de autenticación. Usuario y contraseña, certificados de cliente o ambos.
  6. Nivel gratuito. ¿Puedes probar con dispositivos reales antes de pagar?
  7. Modelos de despliegue. Compartido, dedicado, en tu propia nube o autogestionado.
  8. Vía de salida. ¿Puedes irte sin reescribir el firmware de los dispositivos? El artículo sobre vendor lock-in en MQTT explica qué vigilar.

Migrar de forma gradual con un bridge de Mosquitto

No tienes que cambiarlo todo de golpe. La función de bridge de Mosquitto puede reenviar topics seleccionados desde tu servidor actual a un broker gestionado. Añade esto a tu mosquitto.conf (Mosquitto 2.x):

# Bridge local Mosquitto to a ConnectMQ broker over TLS
connection connectmq-bridge
address broker.connectmq.com:8883
bridge_protocol_version mqttv50
bridge_capath /etc/ssl/certs
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
cleansession false
restart_timeout 10 60

# Forward plant telemetry to the cloud, receive commands back
topic plant1/+/+/telemetry out 1
topic plant1/+/+/cmd in 1

Reinicia Mosquitto y comprueba en el log que el bridge se ha conectado correctamente:

sudo systemctl restart mosquitto
sudo journalctl -u mosquitto -n 50 --no-pager

Después verifica que los datos llegan a la nube suscribiéndote con las credenciales del broker:

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID-debug \
  -t "plant1/#" -v

Ten en cuenta que el broker MQTT gestionado vincula los client IDs a las credenciales emitidas, así que para una segunda conexión simultánea como esta sesión de depuración usa un client ID que se te haya emitido para ello, o utiliza en su lugar el cliente del navegador del portal.

El patrón de bridge permite que los dashboards y los usuarios remotos pasen al broker en la nube mientras los dispositivos locales siguen hablando con la instancia de Mosquitto que ya conocen. Cuando tengas confianza, puedes apuntar los dispositivos directamente al broker MQTT gestionado. El proceso completo se describe en migrar Mosquitto a MQTT en la nube.

Solución de problemas del bridge

  • El bridge se conecta y se cae una y otra vez. Otro cliente está usando el mismo client ID. Cada conexión necesita su propio ID.
  • Errores en el handshake TLS. Confirma que bridge_capath apunta al almacén de CA del sistema, o usa bridge_cafile con un bundle que incluya la cadena de Let's Encrypt.
  • Los mensajes no se reenvían. Revisa el patrón del topic y la dirección (out envía de local a remoto, in recibe de remoto a local).
  • QoS 2 rechazado. Los planes Serverless gratuitos admiten QoS hasta 1, así que configura el bridge con QoS 1 o cambia de plan.

Prueba un broker MQTT gestionado junto a Mosquitto

Puedes probar la parte gestionada sin tocar producción. Crea un broker Serverless gratuito en ConnectMQ sin tarjeta de crédito, añade el bloque de bridge anterior a una instancia de Mosquitto de pruebas y observa cómo aparecen tus topics en el explorador de topics en vivo. Para entender las opciones con más detalle, lee la guía de brokers MQTT en la nube o descubre de qué te libera un broker MQTT gestionado. Si prefieres probar sin registro, el servidor MQTT público gratuito de broker.connectmq.com sirve para pruebas y prototipos, nunca para datos de producción. Tienes más información sobre la plataforma en connectmq.com.

Preguntas frecuentes

¿Existe una versión alojada de Mosquitto?

Algunos proveedores ofrecen Mosquitto alojado o con soporte comercial. Como alternativa, cualquier broker MQTT gestionado que cumpla el estándar funciona con clientes y bridges de Mosquitto, ya que el protocolo es el mismo.

¿Funcionarán mis clientes de Mosquitto con un broker MQTT gestionado?

Sí. Los clientes que hablan MQTT 3.1.1 o 5.0 solo necesitan un nuevo host, puerto, credenciales y client ID.

¿Puedo mantener Mosquitto en el edge y usar también la nube?

Sí. Un bridge reenvía topics seleccionados desde un Mosquitto local al broker en la nube, un patrón habitual en plantas e instalaciones con conectividad poco fiable.

¿Pierdo las ACL al dejar Mosquitto?

Depende del proveedor. ConnectMQ aísla a los tenants y vincula los client IDs a las credenciales, pero no ofrece ACL por topic, así que mantén Mosquitto en el edge si dependes de ellas.

Artículos relacionados

Broker MQTT BYOC: el modelo Bring Your Own Cloud explicado

Un broker MQTT BYOC se ejecuta en tu cuenta cloud, pero lo opera un proveedor. Descubre cómo funciona el modelo, cómo se reparten las responsabilidades y cómo preparar tu cuenta.

9 min de lectura

Alternativa a Google Cloud IoT Core: opciones y migración tras su cierre

Google retiró Cloud IoT Core en agosto de 2023. Esta guía compara las alternativas realistas, traduce los conceptos de IoT Core a MQTT estándar y muestra cómo mover los dispositivos a un broker MQTT gestionado sin dejar de enviar datos a Google Cloud.

9 min de lectura

Mensajes MQTT por segundo: cómo estimar y medir el rendimiento

Planificar el rendimiento de MQTT se reduce a unas pocas fórmulas y una medición honesta. Aprende a estimar los mensajes entrantes y salientes por segundo, a tener en cuenta los picos y a trasladar el resultado a un plan de broker.

8 min de lectura

Todos los artículos →

Tu broker MQTT privado, a unos pocos clics

Crea una cuenta, obtén las credenciales de tu broker y conecta tu primer dispositivo, sin servidores que instalar, parchear ni escalar.