Plataforma IoT multi-tenant: guía para integradores

Una plataforma IoTITérminoIoT (Internet de las cosas)El IoT (Internet of Things) es la red de objetos físicos con sensores, software y conectividad que recogen e intercambian datos y actúan de forma autónoma.Ver perfil multi-tenant es la diferencia entre atender a doce clientes y atender a doce clientes sin doce sistemas que mantener.

El problema aparece en el cliente número tres. Con dos, se puede vivir con dos instalaciones separadas: dos servidores, dos copias de seguridad, dos versiones que actualizar. Con doce, cada corrección hay que aplicarla doce veces, y alguien acaba olvidándose de una. Esa es la cuenta que decide si un integrador crece o se queda donde está.

Esta guía explica qué significa multi-tenant en un contexto IoT, los tres modelos de aislamiento y cuándo tiene sentido cada uno, cómo se organiza la jerarquía cuando hay un integrador entre la plataforma y el cliente final, y las preguntas concretas que conviene hacer antes de firmar con un proveedor. Si todavía estás decidiendo el modelo de negocio, empieza por cómo pasar de proyectos a ingresos recurrentes.

Qué es una plataforma IoT multi-tenant

Un tenant es un cliente lógicamente separado dentro del mismo sistema. Ve sus dispositivos, sus usuarios, sus alarmas y sus informes, y no ve nada de los demás. Multi-tenant significa que ese sistema atiende a muchos a la vez sin duplicarse.

En IoT esto pesa más que en una aplicación de oficina corriente, por tres motivos:

• El volumen es desigual. Un cliente con 40 sensores y otro con 40.000 conviven en la misma plataforma. El diseño tiene que evitar que el grande deje sin servicio al pequeño.
• Los datos son continuos. No hay horas valle claras. La ingesta no para, así que las tareas pesadas de un cliente compiten con la operación de todos.
• La identidad del proveedor cambia. Cada cliente ve la plataforma con la marca de su proveedor, no con la del fabricante del software. Eso es lo que hace posible el modelo de plataforma IoT white-label.

Multi-tenant no es lo mismo que multiusuario. Una plataforma con roles y permisos permite que varias personas de la misma empresa trabajen con distintos niveles de acceso. Multi-tenant añade una frontera por encima: entre empresas distintas que no deben saber ni que la otra existe.

Los tres modelos de aislamiento

Casi todas las plataformas caen en uno de estos tres modelos, o en una mezcla. Los nombres varían, pero la decisión de fondo es siempre la misma: cuánto se comparte.

Base de datos compartida

Todas las lecturas viven en las mismas tablas, y cada fila lleva la marca del cliente al que pertenece. Es el modelo más barato de operar y el que mejor aprovecha el hardware. Su riesgo está concentrado en un punto: si una consulta olvida filtrar por cliente, se ven datos ajenos. Por eso ese filtro no puede depender de que cada desarrollador se acuerde, tiene que estar en una capa que no se pueda saltar.

Esquema o base por cliente

Cada cliente tiene su propio espacio de datos, y la aplicación es común. Cuesta algo más de operación, sobre todo al aplicar cambios de estructura, y resuelve dos conversaciones que se repiten en los contratos: "quiero mi copia de seguridad" y "quiero que mis datos se borren enteros cuando me vaya".

Instancia dedicada

Un despliegue entero para un solo cliente. Es lo que exigen algunos organismos públicos, y lo que se usa cuando el sistema vive dentro de la red del cliente. Cloud Studio IoT se instala también on-premise, además del servicio en AWS, con regiones en Fráncfort para clientes europeos y en Estados Unidos para el resto.

Lo habitual en un integrador con cartera es una mezcla: la mayoría de clientes en un modelo compartido, y uno o dos en instancia propia porque su pliego lo pide. Conviene que la plataforma permita las dos cosas sin cambiar de producto.

Marta monta soluciones de riego para cooperativas. Empezó con una instancia por cooperativa porque parecía lo más seguro, y a la quinta descubrió el coste real: cada actualización eran cinco ventanas de mantenimiento, cinco pruebas y cinco correos explicando lo mismo. Consolidó cuatro en un modelo compartido y dejó dedicada solo la que trabajaba para una administración. El tiempo de mantenimiento mensual pasó de dos días a media mañana.

La jerarquía cuando hay un integrador en medio

En un modelo B2B2B hay tres niveles, y confundirlos crea problemas que luego cuesta deshacer:

1. El proveedor de la plataforma, que mantiene el software y la infraestructura.
2. El integrador, que es dueño de la relación comercial y opera sobre todos sus clientes.
3. El cliente final, que usa su parte y no sabe quién está por encima.

Lo que el integrador necesita de la plataforma es poder trabajar transversalmente: ver el estado de todos sus clientes en una pantalla, aplicar una plantilla de alarmas a varios a la vez, y entrar en uno concreto cuando toca resolver una incidencia. Si para revisar diez clientes hay que iniciar sesión diez veces, el modelo no escala por mucho que la base de datos sea multi-tenant.

Dentro de cada cliente hace falta otra división: por emplazamiento, por planta o por zona. Un responsable de mantenimiento de la planta de Valencia no tiene por qué ver las alarmas de Sevilla. Esa segunda capa es la que convierte una plataforma en algo usable por el cliente final y no solo por el integrador.

En Cloud Studio IoT la separación se apoya en permisos granulares, con SSO, doble factor nativo y registro de auditoría de lo que hace cada usuario. La regla práctica: si alguien puede ver algo, queda constancia de quién es; si cambia algo, queda constancia de qué cambió.

Lo que de verdad se comparte, y lo que nunca

Multi-tenant no significa que todo esté separado. Hay cosas que conviene compartir, porque compartirlas es justo la ventaja del modelo.

Se comparte:

• El catálogo de tipos de dispositivo. Si defines una vez cómo se decodifica un sensor concreto, sirve para todos tus clientes que lo usen.
• Las plantillas de paneles y de alarmas. Un cuadro de mando de depósitos bien hecho se aplica a la cooperativa siguiente en minutos.
• Las integraciones de red. La conexión con un servidor de red LoRaWANProtocoloLoRaWANLPWAN abierta de largo alcance y bajo consumoVer perfil externo o el servidor MQTTProtocoloMQTTEl protocolo pub/sub estándar del IoTVer perfil de la instancia no se monta por cliente.
• El propio software. Una corrección llega a todos a la vez, que es la razón por la que existe el modelo.

No se comparte nunca:

• Los datos de telemetría y su histórico.
• Los usuarios, sus permisos y sus registros de acceso.
• Las alarmas, los destinatarios de notificación y los informes.
• La marca: dominio, colores, logotipo y el remitente de los avisos.

Un detalle que se olvida a menudo: los correos y los mensajes de alarma también llevan marca. Si un cliente de un integrador recibe un aviso firmado por el fabricante del software, el modelo white-label se rompe en la única pantalla que todo el mundo mira.

Un error caro: un tenant por proyecto

Hay una tentación al principio, cuando el primer cliente encarga dos instalaciones muy distintas: crear un tenant para cada proyecto. Parece limpio y evita decidir jerarquías.

El problema llega a los dos años. El cliente pide un informe que cruce sus dos instalaciones y no hay forma de sacarlo, porque para la plataforma son dos empresas sin relación. Los usuarios están duplicados, las alarmas se configuran dos veces, y cuando alguien cambia de puesto hay que tocarlo en dos sitios.

La regla que envejece bien: un tenant es una empresa con la que tienes un contrato, no un proyecto ni un emplazamiento. Todo lo que ocurra dentro de esa empresa se resuelve con la jerarquía interna, que para eso está. Deshacer esto después significa mover datos históricos entre tenants, que es exactamente la operación que ninguna plataforma hace bien.

Rendimiento y medición en una plataforma IoT multi-tenant

El vecino ruidoso

El fallo más común en una plataforma multi-tenant no es una fuga de datos, es que un cliente deja sin servicio a los demás sin pretenderlo. Un informe anual sobre millones de lecturas, una integración que pide datos cada segundo, o una campaña de reconfiguración lanzada a toda una flota.

Las defensas son conocidas y conviene preguntarlas una por una:

• Límites por cliente en llamadas a la API y en mensajes por minuto, para que un bucle en el código de un tercero no se lleve la plataforma por delante.
• Colas separadas entre lo que llega del campo y lo que pide una persona desde el panel. La ingesta no puede pararse porque alguien pidió un informe grande.
• Trabajo pesado fuera de hora, con los informes largos ejecutándose en segundo plano y avisando al terminar.
• Medición por cliente, porque sin saber quién consume qué, la conversación sobre rendimiento se convierte en una discusión de opiniones.

La guía de SaaS Lens de AWS Well-Architected y la documentación de arquitectura multi-tenant de Microsoft desarrollan estos patrones con detalle, y sirven igual aunque tu plataforma no corra en esas nubes.

Medir por cliente antes de facturar por cliente

Un integrador que cobra una cuota mensual necesita saber qué consume cada cliente, y no por curiosidad: es lo que decide si un contrato da dinero o lo pierde.

Las tres unidades que se usan en la práctica:

• Dispositivos activos. La más fácil de explicar en una factura y la que mejor entiende el cliente. Conviene definir qué cuenta como activo, porque un equipo dado de alta y nunca instalado no debería facturar.
• Volumen de mensajes. Refleja mejor el coste real de la plataforma, y penaliza al cliente que configura sus sensores para enviar cada diez segundos sin necesitarlo.
• Usuarios y funciones. Paneles avanzados, informes programados o acceso por API suelen ir por niveles de servicio, no por volumen.

Lo importante no es cuál eliges, sino que la plataforma sepa dar esos números por cliente y por mes sin que nadie los calcule a mano. Un integrador que exporta lecturas a una hoja para emitir doce facturas acaba renunciando a revisarlas, y ahí es donde se pierden los márgenes.

También conviene mirarlo al revés. Si un cliente consume tres veces lo que paga, hay dos caminos: revisar la configuración de sus equipos, que suele ser el origen, o revisar el contrato. Sin medición por cliente, ninguna de las dos conversaciones se puede tener con datos. El reparto completo de partidas está en el coste total de una plataforma IoT.

Esto se conecta con la gestión del parque: el inventario por cliente, las versiones de firmware y las sustituciones son los mismos datos que sostienen la factura. Cómo se mantiene ese inventario está en la guía de gestión de dispositivos IoT.

Cumplimiento, residencia de datos y salida

Tres preguntas que aparecen siempre en cuanto el cliente final es una empresa mediana o una administración.

Dónde están los datos. El Reglamento General de Protección de Datos (Reglamento UE 2016/679) no prohíbe sacar datos de la Unión Europea, pero sí obliga a saber dónde están y bajo qué garantías. Si tus clientes son europeos, la respuesta tiene que ser concreta, no "en la nube".

Quién puede ver qué. Una auditoría no pregunta si la plataforma es segura, pregunta quién accedió a un dato concreto el martes pasado. Eso se responde con un registro de auditoría, no con una declaración de intenciones.

Cómo se sale. Un cliente que se va tiene derecho a llevarse sus datos y a que se borren los suyos, no los de todos. Conviene probar esa exportación antes de firmar y no el día que hace falta. Los patrones de extracción están en la guía de integración por API, y el caso completo de un cambio de plataforma, en la guía de migración.

Carlos lleva la parte técnica de un operador de servicios de agua que trabaja para cuatro ayuntamientos. En el segundo concurso le pidieron por escrito dos cosas: que los datos de cada municipio se pudieran exportar por separado y que quedara traza de cada acceso. Ninguna de las dos era difícil, pero descubrirlas durante la licitación le costó dos semanas de comprobaciones que podría haber hecho un año antes.

Ocho preguntas antes de firmar

1. Aislamiento. ¿Qué modelo usa la plataforma, y puedo tener un cliente en instancia dedicada sin cambiar de producto?
2. Jerarquía. ¿Puedo operar sobre todos mis clientes desde una sola sesión, y dividir dentro de cada uno por emplazamiento?
3. Marca. ¿Se personalizan también los correos y los avisos, o solo la pantalla?
4. Permisos. ¿Hasta qué nivel llega el control de acceso, y hay registro de auditoría?
5. Límites. ¿Qué pasa si un cliente dispara su consumo de API? ¿Hay límites por cliente?
6. Plantillas. ¿Puedo definir un tipo de dispositivo o un panel una vez y reutilizarlo en toda mi cartera?
7. Residencia. ¿En qué región viven los datos, y puedo elegirla por cliente?
8. Salida. ¿Cómo exporto los datos de un cliente concreto, y cómo se borran solo los suyos?

Si alguna respuesta es "se puede desarrollar", conviene pedir el plazo y el precio por escrito. Esa frase, en una plataforma que ya atiende a varios clientes, suele significar que el modelo no lo contempla.

Conclusión

Una plataforma IoT multi-tenant bien planteada es lo que permite que un equipo pequeño atienda a una cartera grande. Lo esencial:

• Multi-tenant no es multiusuario. La frontera entre empresas es distinta de los roles dentro de una empresa.
• Hay tres modelos de aislamiento y ninguno es el correcto siempre. La mezcla es lo normal, y la plataforma debería permitirla.
• La jerarquía importa tanto como la base de datos: operar sobre toda la cartera desde una sesión es lo que hace viable el crecimiento.
• Se comparte el catálogo, las plantillas y el software. No se comparten nunca los datos, los usuarios ni la marca.
• El riesgo diario no es la fuga de datos, es el cliente que consume de más. Pregunta por los límites.
• Residencia, auditoría y salida son preguntas de contrato, y se comprueban antes de firmar.

Si estás valorando cómo encaja tu cartera en un modelo así, habla con el equipo o mira cómo trabajan otros integradores en el programa de partners. Los detalles de permisos y conexión están en la documentación técnica.

Preguntas frecuentes

¿Qué es una plataforma IoT multi-tenant?

Es un sistema que atiende a muchos clientes a la vez sin duplicarse. Cada tenant es un cliente lógicamente separado: ve sus dispositivos, sus usuarios, sus alarmas y sus informes, y nada de los demás.

¿Qué diferencia hay entre multi-tenant y multiusuario?

Multiusuario son roles y permisos para personas de la misma empresa. Multi-tenant añade una frontera por encima, entre empresas distintas que no deben saber ni que la otra existe.

¿Qué modelos de aislamiento existen?

Hay tres: base de datos compartida con un identificador de cliente en cada fila, esquema o base por cliente, e instancia dedicada. Lo habitual en un integrador es una mezcla, con uno o dos clientes en instancia propia.

¿Conviene crear un tenant por proyecto?

No. Un tenant es una empresa con la que tienes un contrato, no un proyecto ni un emplazamiento. Partir un cliente en varios tenants duplica usuarios y alarmas, impide los informes cruzados, y deshacerlo obliga a mover datos históricos.

¿Qué es el problema del vecino ruidoso?

Es un cliente que deja sin servicio a los demás sin pretenderlo, por ejemplo con un informe enorme o una integración que pide datos cada segundo. Las defensas son límites por cliente, colas separadas para la ingesta y para el panel, trabajo pesado en segundo plano y medición por cliente.

¿Qué se comparte entre tenants y qué no?

Se comparten el catálogo de tipos de dispositivo, las plantillas de paneles y alarmas, las integraciones de red y el propio software. No se comparten nunca la telemetría y su histórico, los usuarios y permisos, las alarmas e informes, ni la marca.