Cuando un producto conectado se vende a más de un cliente, aparecen problemas que no tienen nada que ver con los sensores: cuentas separadas, usuarios separados, marca separada y un límite entre ellos que tiene que sostenerse siempre. OmniCloud se construyó multicliente desde la base, así que incorporar al siguiente cliente es un paso de aprovisionamiento y no otro despliegue que mantener.
Tres puntos de partida distintos, un mismo requisito. Un producto que atiende a más de una organización necesita el límite incorporado desde el principio, no agregado en la versión siguiente a que alguien lo note.
Cada cliente necesita su propia cuenta, sus propios dispositivos y sus propios usuarios, y ninguno debería poder ver a los demás. Ese requisito llega con el segundo cliente, no con el quincuagésimo, y sale caro añadirlo a un panel que asumió uno solo.
Atienden a muchos clientes finales y necesitan moverse entre ellos sin mezclar nunca sus datos. El hardware que instalan es del cliente, la visibilidad es suya, y las dos cosas tienen que ser verdad a la vez.
Los equipos regionales, las marcas adquiridas y las divisiones que atienden clientes necesitan cada uno una vista delimitada de la misma plataforma. Mantener diez despliegues separados para lograrlo es un costo operativo que nadie acepta dos veces.
El modelo multicliente no es una función. Alcanza el acceso a los datos, los permisos, la marca, la API y la facturación, y estas son las partes que ya están en producción.
Las cuentas se anidan. Una cuenta de distribuidor está por encima de sus clientes, una cuenta de operador está por encima de sus sitios, y cada consulta, informe y exportación queda delimitada al contexto de la cuenta y no a un filtro que la aplicación tenga que recordar.
Propietario, administrador, operador y observador dentro de una cuenta, donde una cuenta superior no puede otorgar más de lo que ella misma tiene. Un permiso no se puede escalar moviendo a un usuario entre cuentas, que es la falla que de verdad ocurre en producción.
Un dispositivo pertenece a una cuenta y se puede compartir con otra. El operador es dueño del hardware, su proveedor de servicio ve las unidades que mantiene, y ninguna de las dos partes tiene que comprar el dispositivo dos veces ni entregar un acceso.
La misma compilación atiende varias marcas, resueltas según el nombre de host por el que se llega, cada una con su nombre, su logo y su paleta. Así funciona hoy una segunda marca de producto sobre la misma plataforma que la primera.
La misma plataforma se publica como aplicación iOS y Android bajo su propia cuenta de desarrollador, con su nombre y su icono en la ficha de la tienda, y con mantenimiento durante toda la vida del producto.
Los tokens de servicio están delimitados a una cuenta y a un conjunto de permisos, así que una integración no puede alcanzar más allá de la cuenta para la que se emitió. La API cubre lo que cubre el panel, incluidos los comandos de control.
Los umbrales, el enrutamiento de alertas, las definiciones de informes, las unidades y el idioma se definen por cuenta. La compilación es compartida y el comportamiento no, así que un cliente que pide algo distinto no se convierte en una rama que hay que mantener para siempre.
Los productos, las suscripciones, los planes de tarifa y los registros de consumo se modelan por cuenta, así que a qué tiene derecho un cliente y qué ha consumido se responden desde la plataforma y no reconstruyendo una hoja de cálculo al cierre del trimestre.
Elegir entre los dos es una decisión con la que se convive durante toda la vida del producto, y cuesta mucho menos tomarla ahora que revisarla después. Puestas una al lado de la otra.
| Multicliente (OmnIoT) | Cliente único | |
|---|---|---|
| Aislamiento de datos | El límite entre clientes lo impone el framework. Es imposible consultar entre clientes por accidente. | Una sola base de datos compartida. El aislamiento es un filtro que el código tiene que recordar. |
| Incorporar un cliente nuevo | Se aprovisiona en segundos, configurado desde una plantilla. | Un despliegue nuevo, un entorno nuevo, una carga operativa nueva. |
| Marca | Logo, colores, dominio e identidad de correo por cliente. | Una sola marca. Los clientes ven su nombre, no el de ellos. |
| Permisos | Los roles están delimitados a un cliente. Los operadores tienen una vista de superadministrador. | Modelo de permisos plano. Los asuntos de varios clientes se mezclan en el código. |
| Facturación | Medición, facturación y niveles de precio por cliente. | Un cliente. Una factura. Ninguna base para el segundo. |
| Cuándo es la opción correcta | Está construyendo un producto que se vende a muchos clientes finales. | Está construyendo un producto para uso propio o un único despliegue interno. |
El modelo multicliente parece un filtro en una consulta hasta que alguien intenta incorporarlo después. Estas son las partes que lo convierten en un problema de plataforma y no en una función.
Cada consulta, cada búsqueda, cada informe, cada unión y cada agregación tiene que incluir el contexto del cliente. Un filtro que falta es una fuga de datos. Incorporar esto después a una base de código de cliente único es doloroso; construirlo en la capa del framework desde el primer día es el único camino confiable.
Los clientes quieren "solo esta cosa distinta". Sin una plataforma guiada por configuración, cada ajuste se vuelve una rama; seis meses después hay diez despliegues y ninguna actualización compartida. Una plataforma multicliente real convierte la personalización en un asunto de configuración y no de código.
Dar de alta a un cliente nuevo tiene que ser una sola acción del operador. Darlo de baja tiene que conservar los registros de auditoría, resolver el cierre de facturación y eliminar los datos según la política de retención. Automatizar ambas cosas es un subsistema de meses si se construye en casa.
Cuando un cliente reporta un error, los registros tienen que permitir reproducir su estado exacto. El contexto del cliente tiene que viajar por cada traza, cada línea de registro y cada métrica. Esa instrumentación cuesta trabajo real de ingeniería.
Significa que un solo despliegue atiende a muchas organizaciones separadas, cada una con sus propios datos, usuarios, dispositivos, marca y configuración, y con un límite firme entre ellas. Una plataforma de cliente único atiende a una sola organización. Cualquier producto conectado que se venda a más de un cliente necesita la primera forma, y el requisito llega con el cliente número dos.
El aislamiento es lógico y no físico: una base de datos, con cada consulta delimitada al contexto de la cuenta en la capa del framework y no por un filtro que cada parte del código tenga que recordar. Cuesta menos operarla, es más rápido para incorporar clientes y es el límite que impone la plataforma. Si sus clientes llegan con un requisito de aislamiento específico por escrito, envíelo y le decimos cómo se corresponde.
Sí. La misma compilación resuelve su marca según el nombre de host por el que se sirve, incluidos nombre, logo y sistema de color, y eso ya funciona en producción para más de una marca. Las aplicaciones móviles se publican bajo su propia identidad de desarrollador, con su nombre en la ficha.
Los productos, las suscripciones, los planes de tarifa y los registros de consumo se modelan por cuenta, así que a qué tiene derecho un cliente y qué ha consumido se responden desde la plataforma, y la facturación se emite a partir de esos datos. Díganos qué sistema de facturación ya usan y le decimos cómo se conecta.
Sí. Los umbrales, el enrutamiento de alertas, los informes, las unidades, el idioma y las funciones habilitadas son por cuenta. La compilación es compartida y el comportamiento no, que es lo que evita que un pedido de un cliente se convierta en una rama que hay que mantener durante años.
Lo bastante difícil como para que valga la pena evitarlo. El contexto de la cuenta tiene que atravesar cada consulta, cada verificación de permisos y cada exportación, y uno solo que se pase por alto es una fuga de datos y no un error. El trabajo se mide en meses de ingeniería, y es la razón por la que esto se construyó desde el principio en lugar de agregarse cuando llegó el segundo cliente.
Sí. La aplicación resuelve la cuenta y la marca a partir del inicio de sesión, así que un usuario de una cuenta nunca ve otra. Para lo que implica el lado móvil, vea nuestra página sobre aplicaciones móviles con marca propia.
Cuántos son, qué necesita ver cada uno y en qué no se ponen de acuerdo sobre cómo debería comportarse el producto. Volvemos con cómo eso se corresponde con cuentas, roles y configuración por cuenta, y con dónde no.
Hablemos →