Cómo definir arquitectura, seguridad y despliegue para ThingsBoard

Lo que una notebook no demuestra

Durante la prueba, diez dispositivos publican datos en una instancia única. El dashboard responde rápido y una alarma llega por correo. Cuando el sistema pasa a producción aparecen otras preguntas: quién actualiza la plataforma, dónde se guardan los respaldos, cómo se renuevan certificados, cuánto tráfico llega por minuto y qué ocurre si se reinicia el servidor.

El éxito funcional del piloto no valida la arquitectura productiva.

Modalidad de despliegue

La documentación oficial describe ThingsBoard autogestionado en arquitectura monolítica o de microservicios. Una instancia monolítica concentra servicios y puede ser adecuada para desarrollo y cargas pequeñas o medianas. Microservicios separan componentes y permiten escalar horizontalmente, pero incorporan colas, balanceo, bases de datos y operación distribuida.

ThingsBoard Cloud ejecuta la plataforma como servicio administrado y asume infraestructura, actualizaciones, respaldos y monitoreo según el plan vigente. Un despliegue propio conserva mayor control sobre ubicación, red y operación, pero traslada esas responsabilidades al equipo que lo administra.

La decisión no debe basarse sólo en cantidad de dispositivos. La propia documentación señala que la tasa de puntos por segundo depende de frecuencia y cantidad de variables. También importan retención, consultas históricas, complejidad de reglas, usuarios concurrentes y exigencias de disponibilidad.

El relevamiento de esos parámetros sostiene la arquitectura que prepara Nodira. La selección comercial de edición, licencia y servicio debe confirmarse con documentación vigente antes de contratar o publicar una comparación, especialmente porque ThingsBoard anunció cambios de edición desde la versión 4.4.

Frontera con OT

Una práctica razonable es evitar conexiones entrantes innecesarias hacia la red de control. Un gateway local puede leer protocolos OT y abrir una conexión saliente cifrada hacia la plataforma. Esta topología no es universal: debe revisarse con el responsable de ciberseguridad, las zonas y conductos existentes y la criticidad de cualquier canal de escritura.

Si se habilitan comandos desde ThingsBoard, hay que separar visualización de control. La documentación distingue comandos RPC persistentes y no persistentes; incluso cuando un comando se entrega, el significado de la respuesta del equipo debe definirse. Para una función crítica, el control y los enclavamientos deben permanecer donde la evaluación de riesgo lo determine.

Dispositivos, usuarios y secretos

ThingsBoard utiliza mecanismos distintos para dispositivos y usuarios. La documentación oficial enumera tokens, credenciales MQTT y certificados X.509 según protocolo; para usuarios utiliza autenticación y sesiones basadas en JWT, además de opciones como OAuth 2.0 y segundo factor según configuración y edición.

En producción conviene definir:

• credencial única por dispositivo o grupo justificado;
• proceso de alta, rotación y revocación;
• TLS o DTLS según transporte;
• protección de claves privadas y secretos de integraciones;
• roles de administración, ingeniería, operación y consulta;
• auditoría de cambios y accesos;
• revisión periódica de usuarios y permisos.

Un token pegado en firmware y repetido en toda una flota simplifica el alta, pero amplía el impacto de una exposición. Un dashboard público elimina la autenticación del visitante y no debe utilizarse para datos operativos por comodidad.

La documentación diferencia el modelo fijo de roles de Community Edition y el RBAC más granular asociado históricamente a Professional Edition. Desde ThingsBoard 4.4 se anunció una unificación de plataforma; la disponibilidad exacta y la licencia deben verificarse en la versión elegida. La arquitectura debe expresar el requisito de acceso, no asumir una función por su nombre comercial.

Continuidad y observabilidad

Un sistema productivo necesita respaldo de base de datos y configuración, monitoreo de disco, memoria, colas, certificados, gateway y conectividad. ThingsBoard ofrece estadísticas del Rule Engine; el Gateway reporta estado y puede persistir eventos localmente. Eso no reemplaza un procedimiento de restauración probado.

En una arquitectura con instrumentación de campo, tablero local, enlace celular y plataforma cloud, la continuidad tiene más de un dueño. Deben acordarse propiedad de los datos, perfiles de acceso, mantenimiento del tablero y la conectividad, respaldo de la configuración y revisión de las calibraciones. Una conexión disponible no demuestra que la medición conserve validez.

Nodira e infraestructura deben acordar:

• objetivos de recuperación y retención;
• responsables de parches y actualizaciones;
• monitoreo de capacidad y fallas;
• respaldo de dashboards, reglas y configuraciones;
• prueba de restauración;
• ventana de mantenimiento y reversión;
• inventario de dependencias externas.

La documentación y la capacitación cierran esa asignación: cada equipo debe saber qué componente mantiene, cómo reconoce una falla de comunicación y dónde escalarla.

Producción significa asumir la operación

ThingsBoard proporciona plataforma, autenticación y alternativas de despliegue. Nodira diseña la topología, integra fuentes y documenta controles y operación. Infraestructura y ciberseguridad aprueban exposición, identidad, continuidad y mantenimiento. El paso a producción ocurre cuando esas responsabilidades tienen dueño, no cuando el piloto permanece encendido.