Un broker MQTT BYOC se ejecuta dentro de tu propia cuenta cloud mientras un proveedor especializado se encarga del trabajo operativo. Este artículo explica cómo funciona el modelo bring your own cloud, dónde recae cada responsabilidad, cuándo es la opción adecuada frente al alojamiento compartido o dedicado y cómo preparar tu cuenta antes del despliegue.
¿Qué es un broker MQTT BYOC?
"Bring your own cloud" describe un modelo de despliegue en el que el software se ejecuta en infraestructura que posees y pagas tú, normalmente en una cuenta o suscripción cloud bajo el control de tu organización, mientras el proveedor la gestiona. Las máquinas virtuales o contenedores del broker, la red, los discos y los balanceadores de carga viven en tu cuenta. Los ingenieros o la automatización del proveedor despliegan, configuran, actualizan y monitorizan el broker mediante el acceso que tú concedes.
Compáralo con las dos opciones de alojamiento más conocidas:
- Alojamiento compartido (serverless). Muchos clientes comparten un clúster que se ejecuta en la cuenta del proveedor. Obtienes endpoints y credenciales en minutos y no pagas por capacidad ociosa, pero no eliges la infraestructura subyacente.
- Alojamiento dedicado. Tienes tu propio clúster aislado, todavía en la cuenta del proveedor. El rendimiento no se comparte con nadie, pero la infraestructura sigue siendo del proveedor.
- BYOC. Tu propio broker aislado, en tu propia cuenta. El tráfico de mensajes pasa por infraestructura que controlas tú, bajo tus políticas de seguridad cloud y tu facturación.
Si eres nuevo en cómo encajan los brokers en un sistema IoT, qué hace un broker MQTT cubre los conceptos básicos.
Por qué los equipos eligen bring your own cloud
Control de los datos y cumplimiento normativo
El motivo más habitual es el control de los datos. Algunas organizaciones tienen una política según la cual los datos de producción, incluida la telemetría de los dispositivos, deben permanecer en cuentas que les pertenecen, donde se aplican sus propios logs, claves de cifrado, controles de red y auditorías. Un despliegue BYOC permite que la capa MQTT cumpla esa política sin que el equipo tenga que convertirse en operador de brokers. Nuestra guía sobre la residencia de datos en MQTT profundiza en las cuestiones de ubicación y normativa.
Proximidad de red
Cuando tus consumidores, como procesadores de streams, bases de datos y servicios de analítica, ya se ejecutan en una cuenta y región cloud concretas, colocar el broker junto a ellos mantiene el tráfico en la red privada. Los suscriptores dentro de tu red virtual pueden conectarse sin pasar por la Internet pública, mientras que los dispositivos siguen llegando a un endpoint público.
Aprovechar los compromisos cloud existentes
Muchas empresas tienen compromisos de gasto negociados con un proveedor cloud. Ejecutar la infraestructura del broker en tu cuenta hace que ese gasto en cómputo y red cuente para esos compromisos y aparezca en tus informes de costes actuales.
La revisión de seguridad es más sencilla
A los equipos de seguridad a menudo les resulta más fácil aprobar infraestructura que está en una cuenta que ya monitorizan, bajo políticas que ya aplican, que evaluar desde cero un entorno nuevo de un tercero.
De qué se ocupa cada parte en un despliegue BYOC
El reparto exacto lo fija tu acuerdo con el proveedor, pero el patrón típico es este:
| Área | Tú (propietario de la cuenta) | Proveedor (operador) |
|---|---|---|
| Cuenta cloud, facturación, políticas de la organización | Sí | No |
| Diseño de red, rangos IP, peering, política de firewall | Aprueba y es responsable | Propone e implementa las partes específicas del broker |
| Instalación y configuración del broker | Revisa | Sí |
| Actualizaciones y parches de seguridad del broker | Aprueba las ventanas de mantenimiento | Sí |
| Certificados TLS de los endpoints del broker | Decisiones sobre dominios | Emisión y renovación |
| Monitorización del estado del broker y respuesta a incidentes | Contacto de escalado | Sí |
| Firmware de los dispositivos y aplicaciones cliente | Sí | No |
| Consumidores de datos e integraciones posteriores | Sí | No |
La idea clave: tú conservas la propiedad y la visibilidad de la infraestructura, y el proveedor asume la carga operativa. Conviene acordar por escrito el alcance del acceso, las ventanas de mantenimiento, las vías de escalado y cómo se revoca el acceso.
BYOC frente a compartido, dedicado y autoalojado
| Criterio | Serverless compartido | Dedicado | BYOC | Autoalojado |
|---|---|---|---|---|
| Dónde se ejecuta la infraestructura | Cuenta del proveedor | Cuenta del proveedor | Tu cuenta | Tu cuenta o tu centro de datos |
| Quién opera el broker | Proveedor | Proveedor | Proveedor | Tu equipo |
| Aislamiento respecto a otros clientes | Lógico | Clúster físico | Físico, en tu cuenta | Total |
| Tiempo hasta la primera conexión | Minutos | Corto | Mayor (configuración de la cuenta) | Depende de tu equipo |
| Factura de infraestructura | Incluida en el plan | Incluida en el plan | Tu factura cloud más el servicio | Tu factura cloud o de hardware |
| Tu esfuerzo operativo | Muy bajo | Muy bajo | Bajo | Alto |
BYOC se sitúa entre el alojamiento dedicado y el autoalojamiento. Si no tienes claro que lo necesites, un broker MQTT dedicado suele ofrecer aislamiento suficiente con menos configuración. Si quieres control total y tienes personas para operarlo, compara el esfuerzo en broker MQTT autoalojado vs gestionado.
Cómo funciona BYOC en ConnectMQ
ConnectMQ ofrece BYOC como uno de sus planes: el broker se ejecuta en tu cuenta cloud y se gestiona por ti. Se comporta igual que en los demás planes. Los clientes se conectan con MQTT 3.1.1 o MQTT 5.0 en los puertos estándar, TCP 1883, TLS 8883, WebSocket 8083 y Secure WebSocket 8084 con la ruta /mqtt, de modo que el firmware de los dispositivos y las aplicaciones escritos para un broker Serverless o Dedicated no necesitan cambios de código, solo nuevos datos de conexión.
Las funciones de la plataforma siguen disponibles: credenciales generadas con client IDs vinculados a ellas, aislamiento multi-tenant y cuotas por plan, protección contra inundaciones, bloqueo de IP tras inicios de sesión fallidos repetidos, funciones de MQTT 5 como suscripciones compartidas, caducidad de sesión y caducidad de mensajes, y decodificación de Sparkplug B con republicación en topics ISA-95 para proyectos industriales.
Como BYOC depende de tu entorno cloud, confirma directamente con el equipo los proveedores cloud admitidos, las regiones y el modelo de acceso antes de planificar el despliegue.
Preparar tu cuenta cloud
Sea cual sea el proveedor, la misma preparación acorta la incorporación a BYOC:
- Crea una cuenta o suscripción dedicada para el broker, para que sus permisos, su facturación y sus logs de auditoría queden separados de otras cargas de trabajo.
- Elige la región en función de desde dónde se conectan los dispositivos, dónde se ejecutan los consumidores y de cualquier requisito de residencia.
- Reserva rangos de red que no colisionen con tus VPC existentes ni con tus redes on-premises si piensas usar peering o conectividad VPN.
- Comprueba las cuotas de servicio de instancias de cómputo, balanceadores de carga y direcciones IP públicas en esa región.
- Define el modelo de acceso: un rol con alcance limitado que el proveedor pueda asumir, con los logs activados, y una forma documentada de revocarlo.
- Decide el DNS de los endpoints del broker y quién gestiona los registros.
- Acuerda las ventanas de mantenimiento y cómo se te notificará antes de las actualizaciones.
- Configura etiquetas de costes para que la infraestructura del broker sea visible en tus informes.
Valida tus clientes antes de la migración
Mientras se prepara el entorno BYOC, puedes probar el comportamiento de los clientes contra el servidor MQTT público gratuito (solo con datos de prueba, nunca de producción) y después contra un broker privado gratuito. Este ejemplo en Python usa paho-mqtt 2.x y se conecta por TLS. Más adelante sustituye el host y las credenciales por tu endpoint BYOC; no cambia nada más.
import ssl
import paho.mqtt.client as mqtt
HOST = "broker.connectmq.com" # replace with your BYOC endpoint
PORT = 8883
CLIENT_ID = "YOUR_CLIENT_ID"
def on_connect(client, userdata, flags, reason_code, properties):
print("Connected:", reason_code)
client.subscribe("connectmq/demo/byoc-7c21/#", qos=1)
client.publish("connectmq/demo/byoc-7c21/status", "online", qos=1, retain=True)
def on_message(client, userdata, msg):
print(msg.topic, msg.payload.decode())
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID,
protocol=mqtt.MQTTv5)
# For a private broker, uncomment:
# 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(HOST, PORT, keepalive=60)
client.loop_forever()
Ejecuta el mismo script contra cada entorno y mantén idéntica la estructura de topics. Cuando el broker BYOC esté operativo, el cambio será solo de configuración.
Errores habituales
- Acceso demasiado amplio para el operador. Concede solo lo que necesita el broker y registra cada acción.
- Olvidar los costes de salida de datos. Si los dispositivos o los consumidores están en otras regiones o nubes, las tarifas de transferencia de datos aparecen en tu factura.
- Bloquear las actualizaciones. Las políticas que impiden al operador aplicar parches crean el mismo riesgo que un broker autoalojado sin mantenimiento.
- No tener entorno de staging. Mantén un pequeño broker que no sea de producción, por ejemplo en el plan Serverless gratuito, para pruebas de firmware e integración.
Empieza con ConnectMQ
Puedes explorar la plataforma hoy mismo con el plan Serverless gratuito, sin tarjeta de crédito, en app.connectmq.com. Construye y prueba allí tus dispositivos y después habla con el equipo sobre pasar a BYOC cuando tus requisitos de control de datos lo exijan. Para una visión más amplia de las opciones de alojamiento, lee la guía de brokers MQTT en la nube o compara los planes en la guía del broker MQTT gestionado.
Preguntas frecuentes
¿Un broker MQTT BYOC es lo mismo que autoalojarlo?
No. La infraestructura está en tu cuenta, pero el proveedor instala, actualiza y monitoriza el broker. Con el autoalojamiento, todo eso lo hace tu propio equipo.
¿Necesitan mis dispositivos un firmware distinto para BYOC?
No, si el broker habla MQTT estándar. En ConnectMQ, BYOC usa los mismos protocolos y puertos que los demás planes, así que solo cambias el hostname y las credenciales.
¿Quién paga la infraestructura cloud en BYOC?
La infraestructura aparece en tu propia factura cloud, y el proveedor factura el servicio de gestión por separado. Confirma el acuerdo exacto con tu proveedor.
¿Cuándo es BYOC excesivo?
Si no tienes ninguna política que exija que los datos permanezcan en tu propia cuenta, un broker MQTT gestionado compartido o dedicado es más rápido de poner en marcha y más sencillo de operar.
