Arquitectura multiinquilino: una guía práctica para arquitectos

La arquitectura multiinquilino es un enfoque de diseño de software en el que una única instancia de aplicación atiende a varios clientes —denominados inquilinos—, manteniendo aislados los datos y el comportamiento de cada inquilino. El veredicto práctico sobre la selección del modelo es tratar la inquilinidad como una decisión de producto escalonada. Empieza con un modelo Pool para clientes sensibles al coste y de menor riesgo; utiliza un modelo híbrido o Bridge cuando la combinación de clientes sea desigual; y aprovisiona una infraestructura Silo dedicada para clientes empresariales o regulados que necesiten aislamiento contractual.

Las tres principales compensaciones que todo equipo debe gestionar:

Aislamiento frente a coste: Un aislamiento más sólido implica recursos dedicados, lo que supone un gasto mayor por inquilino.
Complejidad frente a flexibilidad: Los modelos compartidos son más baratos de operar, pero requieren una aplicación rigurosamente controlada para evitar filtraciones de datos.
Velocidad frente a cumplimiento normativo: Las arquitecturas Pool incorporan inquilinos en segundos; los modelos Silo pueden tardar de minutos a horas, pero satisfacen a los auditores y a los equipos de compras empresariales.

Índice

¿Qué significa realmente «multiinquilino»?
¿Cuáles son los principales modelos de inquilinidad?
¿Cómo se elige el modelo de inquilinidad adecuado?
Lista de comprobación para implementar sistemas multiinquilino
Seguridad y cumplimiento normativo en entornos multiinquilino
¿Cómo se escala una plataforma multiinquilino sin perjudicar el rendimiento?
¿Cómo se gestiona el ciclo de vida completo de un inquilino?
¿Qué aspecto tienen las arquitecturas de referencia en la práctica?
Cómo Ridiculous Engineering aborda la arquitectura multiinquilino
Conclusiones clave
Fuentes útiles y lecturas adicionales
Trabajar con Ridiculous Engineering en tu plataforma multiinquilino
Preguntas frecuentes

¿Qué significa realmente «multiinquilino»?

Un inquilino es una organización, cuenta o unidad lógica de cliente distinta que comparte la plataforma. Una única empresa puede tener miles de usuarios, pero todos pertenecen a un mismo inquilino. El límite del inquilino es la línea lógica o física que separa los datos, la configuración y el comportamiento de un inquilino de los de otro.

En contraste, en una arquitectura de inquilino único, cada cliente obtiene una instancia de aplicación y una base de datos dedicadas. Las implementaciones de inquilino único son más fáciles de comprender, pero resultan costosas de operar a escala. La multiinquilinidad permite que una única instancia de aplicación atienda a muchos clientes, por lo que la mayoría de las plataformas SaaS la adoptan para crecer de decenas a miles de clientes sin rediseñar el sistema central.

Los objetivos empresariales que impulsan a los equipos hacia la multiinquilinidad son constantes: menor coste de infraestructura por cliente, una única superficie de despliegue para actualizaciones y parches, y una menor carga operativa. Los objetivos técnicos son igualmente constantes: aislamiento de datos entre inquilinos, enrutamiento de solicitudes consciente del inquilino, monitorización por inquilino y capacidad para aplicar distintas configuraciones o conjuntos de funcionalidades por cuenta.

¿Cuáles son los principales modelos de inquilinidad?

Orientación de AWS presenta el aislamiento como un continuo que va de Silo a Pool, con modelos Bridge intermedios. Este marco es el modelo mental más útil para tomar decisiones de arquitectura.

Three modular towers representing tenancy models

Silo (pila dedicada por inquilino)

Cada inquilino obtiene su propia pila de aplicaciones y base de datos. El aislamiento es máximo: un error, una brecha de seguridad o una carga ruidosa en un inquilino no puede afectar a otro. A los auditores de cumplimiento les encanta porque es sencillo demostrar la residencia de los datos y los controles de acceso. Sin embargo, el coste es real. La sobrecarga de infraestructura aumenta linealmente con el número de inquilinos y la complejidad operativa crece con cada nueva implementación. Restaurar por inquilino es sencillo porque cada base de datos ya está limitada a un solo cliente.

Esquema por inquilino (base de datos compartida, esquemas separados)

Todos los inquilinos comparten un motor de base de datos, pero cada uno obtiene su propio esquema. Este modelo se sitúa entre el modelo aislado y el completamente agrupado: ofrece una separación lógica significativa sin el coste de instancias de base de datos independientes. El modelo de esquema por inquilino funciona bien cuando el número de inquilinos se cuenta por cientos en lugar de miles, porque la proliferación de esquemas acaba generando problemas con las migraciones y la agrupación de conexiones. Las migraciones de esquemas en línea requieren un control de versiones cuidadoso para evitar bloquear varios inquilinos simultáneamente.

Esquema compartido (aislamiento a nivel de fila)

Una base de datos, un esquema y las filas de todos los inquilinos coexistiendo en las mismas tablas. Este es el modelo de menor coste y el que exige más disciplina. La seguridad a nivel de fila requiere un filtro tenant_id en cada lectura y escritura. Si se omite una consulta, se produce una filtración de datos. Las políticas de seguridad a nivel de fila (RLS) de PostgreSQL o el middleware de la capa de aplicación pueden imponerlo automáticamente, pero el riesgo de que falte un filtro es real y las consecuencias son graves.

Modelos puente e híbridos

Un modelo puente combina recursos de computación agrupados con distintos grados de aislamiento del almacenamiento. Un patrón habitual es disponer de una capa de aplicaciones compartida, pero bases de datos independientes por inquilino para el almacenamiento. El patrón Deployment Stamps de Azure lleva esto un paso más allá al implementar infraestructura dedicada para un inquilino o grupo de inquilinos y escalar después añadiendo sellos. Los sellos pueden ser para un solo inquilino o para varios, lo que proporciona a los equipos una ruta de actualización clara cuando un inquilino agrupado supera los recursos compartidos.

Comparación de modelos de tenencia

Dimensión	Aislado	Esquema por inquilino	Esquema compartido	Puente/Híbrido
Nivel de aislamiento	Fuerte (físico)	Moderado (lógico)	Débil (impuesto por la aplicación)	Configurable
Coste por inquilino	Alto	Medio	Bajo	Medio-alto
Complejidad de implementación	Alta (sobrecarga operativa)	Media	Baja-media	Alta
Escalabilidad	Crecimiento lineal de los costes	Cientos de inquilinos	Miles de inquilinos	Flexible
Adecuación para el cumplimiento	Excelente	Buena	Requiere evidencia	Bueno-Excelente
Capacidad de personalización	Completa	Alta	Limitada	Alta

The Best Cloud Native Embedded BI Tools: Find the Right Fit ...

Consejo profesional: No trates esta tabla como una respuesta definitiva. La mayoría de las plataformas de producción terminan utilizando al menos dos modelos simultáneamente: agrupado para los niveles estándar y aislado o por bloques para los contratos empresariales. Diseña tus abstracciones para admitir ambos desde el primer día.

¿Cómo elegir el modelo de tenencia adecuado?

La decisión no es puramente técnica. Tratar la tenencia como una funcionalidad del producto —algo que se fija en el precio y se empaqueta— es lo que diferencia a las plataformas que captan ingresos empresariales de aquellas que los dejan escapar.

Analiza estos criterios en orden:

Requisitos normativos y de cumplimiento. Si algún cliente estará sujeto a HIPAA, PCI DSS o auditorías SOC 2 Tipo II, empieza con un modelo aislado o con un esquema por cliente para esas cuentas. El aislamiento mediante un esquema compartido es difícil de auditar de forma convincente.
Residencia de datos contractual. Los clientes empresariales exigen cada vez más que los datos permanezcan dentro de límites geográficos específicos. Los modelos aislados o por bloques lo facilitan; los modelos con esquema compartido requieren controles cuidadosos a nivel de base de datos.
Compromisos de SLA empresariales. Si prometes una disponibilidad del 99,9 % o superior con ventanas de soporte dedicadas, un vecino ruidoso en un modelo agrupado supone un riesgo para el SLA.
Sensibilidad al precio de tu base de clientes. Las pymes y los clientes de autoservicio rara vez pagan lo suficiente como para justificar una infraestructura dedicada. Empieza con un modelo agrupado para estos segmentos.
Madurez del equipo y nivel de automatización. Los modelos aislados requieren una automatización madura de la infraestructura. Si tu equipo no puede aprovisionar la pila de un nuevo cliente en menos de cinco minutos y sin ningún paso manual, la sobrecarga operativa te perjudicará.
Variabilidad de la carga de trabajo. Las cargas muy variables o con picos se benefician de los recursos agrupados, porque las cargas no correlacionadas reducen la proporción entre los picos y el promedio. Los clientes predecibles y de gran volumen son mejores candidatos para recursos dedicados.

Flujo de decisión práctico: empieza con un modelo agrupado si no conoces el perfil de tus clientes o si predominan las pymes. Pasa a un modelo híbrido en cuanto firmes con tu primer cliente empresarial que tenga requisitos de aislamiento. Reserva el aislamiento completo para sectores regulados o clientes con obligaciones contractuales de residencia de datos.

Consejo profesional: Evita la trampa del todo o nada. Las plataformas que se comprometen con un único modelo de tenencia para todos los clientes terminan gastando demasiado en aislamiento para cuentas de poco valor o perdiendo contratos empresariales porque no pueden ofrecer infraestructura dedicada. Incorpora el nivel de tenencia a tu modelo de precios desde el principio, aunque hoy solo tengas un nivel.

Recommended Image

Los equipos que empiezan con un modelo totalmente agrupado para ahorrar costes suelen enfrentarse a problemas de vecinos ruidosos que después resultan caros de solucionar. Empezar con un modelo híbrido —agrupado para los niveles inferiores y aislado para el empresarial— evita ese coste de reestructuración. Alinear las decisiones de tenencia con los objetivos empresariales desde el principio es una de las decisiones de mayor impacto que puede tomar un equipo de arquitectura.

Lista de comprobación de implementación para sistemas multiinquilino

Acertar con el modelo de arquitectura es solo la mitad de la batalla. La otra mitad es la disciplina de ingeniería necesaria para implementarlo correctamente. Estos son los componentes básicos que más importan.

Identidad y enrutamiento del cliente

Asigna a cada cliente un tenant_id estable e inmutable en el momento de su creación y trátalo como un elemento fundamental en todas las capas de la pila.
Propaga el contexto del cliente durante todo el ciclo de vida de la solicitud: las cabeceras HTTP, el middleware, las conexiones de base de datos y las colas de trabajos asíncronos deben transportarlo.
Utiliza el enrutamiento mediante subdominios (tenant.app.com), el enrutamiento basado en rutas (/api/tenant/{id}/), o las notificaciones JWT para resolver la identidad del tenant en el perímetro antes de que la solicitud llegue a la lógica de la aplicación.

Particionado de datos y agrupación de conexiones

Para los modelos de esquema compartido, aplica automáticamente los filtros tenant_id en la capa de acceso a datos, no en el punto de llamada. Codificar de forma rígida la lógica del tenant en el punto de llamada crea fallos de seguridad sutiles y deuda de mantenimiento.
Usa PgBouncer u otro agrupador de conexiones similar para gestionar eficazmente las conexiones de base de datos en grandes grupos de tenants; los límites de conexiones por tenant evitan que uno agote el grupo.
Para los modelos con un esquema por tenant, automatiza la creación y eliminación de esquemas como parte del ciclo de aprovisionamiento y baja.

Autenticación y autorización

Admite proveedores de identidad por tenant: los clientes empresariales querrán aportar su propio proveedor SAML u OIDC.
Aplica roles y permisos limitados al tenant para que un usuario autenticado en el Tenant A no pueda acceder a los recursos del Tenant B, incluso con un token válido.
Usa herramientas como Auth0, Okta o AWS Cognito con notificaciones conscientes del tenant para evitar crear la infraestructura de identidad desde cero.

Aprovisionamiento y migraciones

Automatiza por completo el aprovisionamiento de tenants. Si el aprovisionamiento requiere escrituras manuales de esquemas o pasos humanos, el sistema es, en la práctica, multiinstancia y no multitenant.
Versiona todas las migraciones de esquema y aplícalas de forma compatible con versiones anteriores para poder desplegar cambios en miles de tenants sin tiempo de inactividad.
Mantén un registro de tenants (un almacén de metadatos) que realice el seguimiento del nivel, la configuración, el estado de aprovisionamiento y los recursos asignados de cada tenant.

Copias de seguridad, recuperación ante desastres y medición

Define SLA de recuperación por tenant y prueba los procedimientos de restauración para tenants individuales, no solo las restauraciones de la base de datos completa.
Recopila desde el primer día métricas de uso por tenant (llamadas a la API, almacenamiento y computación) e intégralas con tu sistema de facturación. Plataformas como Manaxo muestran cómo los productos SaaS relacionan en la práctica los datos de uso con los niveles de facturación.
Aplica cuotas y límites de frecuencia por tenant para proteger los recursos compartidos.

CI/CD y estrategia de lanzamientos

Usa indicadores de funcionalidades para desplegar cambios primero en un subconjunto de tenants antes del despliegue completo. Es la forma más segura de probar personalizaciones específicas de tenants sin poner en riesgo todo el conjunto.
Automatiza las canalizaciones de CI/CD para desplegar la configuración específica de cada tenant junto con el código de la aplicación.
Antipatrones que debes evitar: lógica de tenants codificada de forma rígida en el código de la aplicación, pasos manuales de aprovisionamiento y observabilidad insuficiente por tenant.

Consejo profesional: Instrumenta tu sistema para emitir métricas y registros etiquetados con el tenant desde el primer día de desarrollo. Incorporar observabilidad a posteriori en una plataforma multitenant en funcionamiento es difícil y costoso. El registro consciente del tenant no es opcional: es la única forma de depurar problemas de producción sin exponer los datos de un tenant mientras investigas los de otro.

Seguridad y cumplimiento en entornos multitenant

La seguridad multitenant no consiste en un único control. Es un conjunto de decisiones por capas que se acumulan en toda la arquitectura.

Cifrado en reposo y en tránsito: Cifra todos los datos de los tenants en reposo mediante AES-256 o un equivalente, y exige TLS 1.2 o superior para todos los datos en tránsito. Para tenants altamente regulados, considera el cifrado a nivel de campo para las columnas sensibles, de modo que ni siquiera los administradores de la base de datos puedan leer los valores sin procesar.
IAM limitado al tenant: Aplica controles de acceso con el mínimo privilegio en todas las capas. Las políticas de IAM en la nube, los roles de la base de datos y los permisos de la aplicación deben estar limitados al tenant. No debería ser posible acceder a otros tenants mediante las rutas normales de la aplicación.
Registro de auditoría: Etiqueta cada entrada del registro con tenant_id, almacena los registros en un sistema resistente a manipulaciones (AWS CloudTrail, Azure Monitor Logs) y consérvalos durante el periodo exigido por la normativa aplicable. Los auditores de SOC 2 te lo pedirán.
Residencia de datos: Para los requisitos de residencia de datos de EE. UU., utiliza el anclaje a una región de la nube y confirma que los servicios gestionados (copias de seguridad, réplicas y exportaciones de análisis) también permanezcan dentro de la región requerida. Los modelos de silo y de despliegue replicado facilitan demostrarlo.
PCI DSS: Los datos de titulares de tarjetas deben estar aislados. Un modelo con esquema compartido no es una opción viable para el alcance de PCI sin controles compensatorios importantes. El silo o un esquema por tenant son las opciones prácticas.
HIPAA: La información sanitaria protegida requiere un Acuerdo de Socio Comercial con tu proveedor de nube y controles de acceso demostrables. Las claves de cifrado y los registros de auditoría por tenant son requisitos básicos.
Contención de brechas: Diseña los límites entre tenants de modo que una credencial de aplicación comprometida no pueda atravesarlos. Las claves de cifrado por tenant implican que el compromiso de una clave afecte a un solo tenant, no a todos.
Respuesta ante incidentes: Mantén procedimientos operativos por tenant para que el equipo de guardia pueda aislar, investigar y restaurar un único tenant sin afectar a los demás. Resiliencia operativa La planificación debe incluir escenarios de incidentes específicos de cada tenant.

Este artículo ofrece orientación técnica general, no asesoramiento jurídico ni sobre cumplimiento normativo. Confirma tus obligaciones regulatorias específicas con un asesor jurídico cualificado y con tu equipo de cumplimiento.

¿Cómo se escala una plataforma multi-tenant sin perjudicar el rendimiento?

Escalar una plataforma multi-tenant consiste menos en disponer de capacidad bruta y más en proteger a los tenants entre sí, manteniendo previsibles los costes.

Agrupa cargas de trabajo no correlacionadas. Agrupar tenants con patrones de uso no relacionados aplana las proporciones entre carga máxima y carga media en los recursos compartidos. Un tenant cuyo pico se produce el lunes por la mañana combinado con otro cuyo pico se produce el viernes por la tarde forma un grupo mejor que dos tenants con picos idénticos el lunes por la mañana. Esta es una de las decisiones de planificación de capacidad con mayor impacto al alcance de los equipos de plataforma.
Cuotas y limitación de velocidad por tenant. Aplica límites de velocidad de API, límites de tiempo de consulta y cuotas de almacenamiento por tenant. Cuando un tenant alcance un límite, ralentiza o pon en cola sus solicitudes en lugar de permitir que degraden el grupo. Esta es la principal medida para mitigar el efecto del vecino ruidoso.
Escalado de topología. Cuando la carga de trabajo de un tenant supere de forma constante lo que la limitación puede contener, muévelo a un nivel de recursos dedicado. Esto no es un fallo de la arquitectura; es la ruta de actualización funcionando según lo previsto.
Escalado automático y serverless. La computación serverless (AWS Lambda, Azure Functions) gestiona bien las cargas variables en los niveles agrupados porque pagas por invocación en lugar de por instancia aprovisionada. En los despliegues replicados, los grupos de escalado automático con capacidad precalentada gestionan el crecimiento predecible. Consulta patrones de escalado de infraestructurapara obtener orientación práctica sobre la preparación para un tráfico elevado.
Escalado de bases de datos. La agrupación de conexiones es fundamental a escala. En los modelos con esquema compartido, una única instancia de PgBouncer puede gestionar miles de conexiones de tenants contra un número reducido de conexiones de base de datos reales. En el modelo de un esquema por tenant, Aurora Serverless u otras bases de datos gestionadas similares reducen el coste de los esquemas inactivos.
Métricas y atribución de costes por tenant. Instrumenta la plataforma para atribuir los costes de computación, almacenamiento y red a cada tenant. Estos datos impulsan las decisiones de precios e identifican a los tenants cuyo uso no cubre el coste de su infraestructura.

¿Cómo se gestiona todo el ciclo de vida de un tenant?

La tenencia es una funcionalidad del producto, no solo una cuestión técnica. El ciclo de vida, desde la incorporación hasta la baja, debe abordarse con el mismo cuidado que cualquier otra capacidad del producto.

Aprovisionamiento sin intervención: Los tenants agrupados deben aprovisionarse completamente en segundos mediante una canalización automatizada: crear el registro del tenant, asignar tenant_id, aplicar la configuración predeterminada y enviar las credenciales de bienvenida. Sin pasos manuales. Automatizar la incorporación es lo que diferencia una plataforma de una colección de instancias gestionadas manualmente.
Artefactos de aprovisionamiento: Cada evento de aprovisionamiento de un tenant debe generar un conjunto completo de artefactos: creación del esquema o la base de datos, blobs de configuración, secretos almacenados en un gestor de secretos (AWS Secrets Manager, HashiCorp Vault), claves de API y una entrada en el registro de metadatos de tenants.
Actualizaciones y migraciones de nivel:Define una ruta de actualización clara para trasladar un tenant de un modelo agrupado a uno de esquema por tenant, después a una base de datos dedicada y, finalmente, a un silo completo. Cada paso debe estar automatizado y probado. La guía sobre modelos de tenancy de Azure describe cómo las plataformas exitosas utilizan niveles agrupados para usuarios estándar y stamps aislados para clientes empresariales, y ese patrón requiere una ruta de migración probada entre niveles.
Gestión de la personalización:Utiliza indicadores de funcionalidad (LaunchDarkly, Unleash o un sistema de indicadores propio) para gestionar la disponibilidad de funcionalidades específicas por tenant. Almacena la configuración del tenant en un almacén de configuración dedicado, no en el código de la aplicación. Los puntos de extensión deben estar bien definidos y aislados.
Facturación y medición:Recopila continuamente métricas de uso y asígnalas a niveles de facturación. En productos SaaS regulados, plataformas como Intelligent Assessmentsdemuestran cómo los precios escalonados se adaptan a segmentos de clientes sensibles al cumplimiento normativo. Aplica límites estrictos antes del cierre de los ciclos de facturación para evitar excesos inesperados.
Desactivación:Define un proceso de eliminación de tenants que borre o archive todos sus datos, revoque las credenciales, libere los recursos y genere un registro de auditoría de la eliminación. El RGPD y la CCPA exigen que pueda demostrarse la eliminación de datos cuando se solicite.

¿Cómo son las arquitecturas de referencia en la práctica?

Guía de AWS sobre arquitecturas multi-tenant

La guía de AWS para arquitecturas multi-tenant organiza el espacio de diseño en torno al continuo Silo/Bridge/Pool. En una arquitectura agrupada de AWS, los tenants comparten recursos de cómputo de ECS o Lambda, un único clúster de RDS o Aurora y una API Gateway compartida con autorizadores conscientes del tenant. En una arquitectura de silo, cada tenant obtiene su propia VPC, instancia de RDS y límite de roles de IAM. El modelo Bridge normalmente comparte el cómputo (tareas de ECS o Lambda) mientras aísla el almacenamiento (instancias de RDS por tenant o prefijos de S3 con políticas de bucket).

AWS recomienda utilizar Amazon Cognito con atributos personalizados para una identidad consciente del tenant, AWS IAM para el aislamiento a nivel de recurso en los modelos de silo y Amazon CloudWatch con métricas etiquetadas por tenant para la observabilidad en todos los modelos.

Stamps de despliegue de Azure

El Azure Architecture Center de Microsoft describe el patrón Deployment Stamps como una forma de escalar plataformas multi-tenant mediante el despliegue de unidades de infraestructura autocontenidas. Un stamp puede atender a un tenant empresarial (stamp de tenant único) o a un grupo de tenants agrupados (stamp multi-tenant). Añadir capacidad significa añadir stamps, no escalar un clúster monolítico compartido. Este enfoque proporciona a los equipos sólidas garantías de aislamiento, al tiempo que conserva la posibilidad de agrupar tenants pequeños dentro de un stamp.

Salesforce como ejemplo canónico

Salesforce es el ejemplo más citado de multitenancy a gran escala en el SaaS empresarial. La plataforma presta servicio a cientos de miles de organizaciones sobre una infraestructura compartida mediante una combinación de aislamiento a nivel de aplicación, metadatos por tenant y un motor de consultas propietario que aplica los límites entre tenants en la capa de acceso a datos. La lección clave de la arquitectura de Salesforce no es la tecnología específica, sino el principio: el aislamiento de tenants debe aplicarse en la capa de datos y no dejarse a la memoria de cada desarrollador en el punto de llamada.

SAP BTP y las plataformas empresariales

La arquitectura de referencia de SAP para SaaS multi-tenant en BTPsigue principios similares: aislamiento de tenants, incorporación y desactivación automatizadas, uso compartido de recursos con controles de gobernanza y configuración a nivel de tenant para extensiones empresariales. Las plataformas empresariales convergen sistemáticamente en los mismos patrones, independientemente de la pila tecnológica subyacente.

Cómo Ridiculous Engineering aborda la arquitectura multi-tenant

Ridiculous Engineering es una consultora de ingeniería de software con sede en Colorado que ha diseñado y desarrollado plataformas multi-tenant en producción para clientes de sectores regulados, startups SaaS y equipos de software empresarial. Nuestro proceso es deliberado y comienza con el descubrimiento antes de elegir cualquier modelo.

Nuestro trabajo habitual sigue esta secuencia:

Descubrimiento y definición de restricciones:Documentamos los objetivos de SLA, los requisitos de cumplimiento (HIPAA, PCI, SOC 2), la escala prevista de tenants a 12 y 36 meses, los requisitos de personalización y el nivel de madurez de automatización del equipo. Estos datos determinan el modelo de tenancy inicial.
Decisión sobre tenancy y diseño de la arquitectura:Recomendamos un modelo inicial y definimos la ruta de actualización. Para la mayoría de los clientes, esto significa comenzar con un modelo agrupado y una ruta de migración definida hacia un esquema por tenant o un silo para las cuentas empresariales.
Automatización y aprovisionamiento:Desarrollamos canalizaciones de aprovisionamiento de tenants sin intervención antes de escribir las funcionalidades de la aplicación. El aprovisionamiento es un entregable de ingeniería de primera clase, no algo secundario.
Implementación por etapas:Implementamos los controles de tenancy en la capa de acceso a datos, no en el punto de llamada, y los validamos con pruebas automatizadas que simulan intentos de acceso entre tenants.
Manual operativo y transferencia a operaciones:Entregamos manuales operativos documentados para la incorporación de tenants, las actualizaciones de nivel, la respuesta ante incidentes y la desactivación, de modo que vuestro equipo pueda operar la plataforma de forma independiente.

Nuestro trabajo en la plataforma CMS de Consusilustra cómo una visión de la separación de tenants centrada en la plataforma y la arquitectura en la nubese traducen en sistemas de producción que escalan sin necesidad de rediseñar la arquitectura. Evaluamos las mismas restricciones en cada proyecto: controles de cumplimiento, escala prevista de tenants, profundidad de la personalización y capacidad del equipo para operar lo que desarrollamos.

Conclusiones clave

Considera la tenancy como una decisión de producto escalonada: comienza con un modelo agrupado para lograr eficiencia de costes, añade niveles de aislamiento a medida que lo exijan el cumplimiento y los requisitos empresariales, y automatiza cada etapa del ciclo de vida del tenant desde el primer día.

Punto	Detalles
Empieza con un modelo compartido y planifica el aislamiento	Comienza con un modelo de esquema compartido o agrupado para clientes pymes y define la ruta de actualización a un modelo aislado antes de necesitarla.
Aplica tenant_id en la capa de datos	Aplica automáticamente los filtros de tenant en la capa de acceso a datos, no en puntos de llamada individuales, para evitar filtraciones de datos.
Automatiza completamente el aprovisionamiento	Los pasos manuales de aprovisionamiento significan que tienes varias instancias, no un sistema multiinquilino; la incorporación con un solo clic es un requisito básico innegociable.
Instrumenta pronto las métricas por tenant	Etiqueta los registros y las métricas con tenant_id desde el primer día; adaptar la observabilidad a una plataforma activa es caro y propenso a errores.
Ridiculous Engineering diseña esto	Ridiculous Engineering crea plataformas multiinquilino listas para producción, con aprovisionamiento automatizado, aislamiento por niveles y una arquitectura preparada para el cumplimiento normativo.

Fuentes útiles y lecturas adicionales

Los arquitectos que quieran profundizar en los detalles de implementación tienen varias referencias autorizadas que merece la pena guardar:

Guía de AWS para arquitecturas multiinquilino: La referencia principal de AWS para el continuo Silo/Bridge/Pool, con arquitecturas de ejemplo, constructos de CDK y orientación sobre identidades conscientes del tenant mediante Amazon Cognito.
Centro de arquitectura de Azure: soluciones multiinquilino: Serie completa de Microsoft que abarca consideraciones arquitectónicas, sellos de implementación, orientación específica para servicios y una lista de comprobación práctica para plataformas multiinquilino alojadas en Azure.
Modelos de tenencia de Azure: Orientación centrada en elegir entre modelos de tenencia, con análisis de ventajas y desventajas y recomendaciones sobre rutas de actualización.
Shopify: prácticas recomendadas para arquitecturas multiinquilino: Una visión general orientada a profesionales sobre cómo los desarrolladores de aplicaciones escalan de decenas a miles de comerciantes, con patrones de implementación concretos.
Centro de arquitectura de SAP: SaaS multiinquilino en BTP: Arquitectura de referencia centrada en empresas que cubre el aislamiento de tenants, la incorporación, la gobernanza de recursos y la gestión de configuraciones para extensiones de SAP BTP.
Recursos de Ridiculous Engineering: Para obtener ayuda con la implementación, estudios de caso y servicios de arquitectura, consulta ridiculousengineering.com.

Trabajar con Ridiculous Engineering en tu plataforma multiinquilino

Crear correctamente una plataforma multiinquilino desde el principio cuesta menos que arreglar una que se construyó mal. La decisión arquitectónica más costosa que toman muchos equipos es comprometerse con un único modelo de tenencia sin una ruta de migración y descubrir, dos años después, que su cartera empresarial requiere un aislamiento dedicado que no pueden ofrecer.

Ridiculous Engineering’s desarrollo de software a medidala práctica se centra exactamente en este tipo de trabajo de arquitectura: basado en el descubrimiento, guiado por las restricciones y entregado con la automatización y la documentación que su equipo necesita para operarlo a largo plazo. Trabajamos con startups de SaaS, plataformas en crecimiento y empresas consolidadas en Colorado y más allá. Si está diseñando un nuevo sistema multiinquilino o modernizando uno existente, el momento adecuado para hacer bien la arquitectura es antes de que el primer cliente empresarial solicite un aislamiento dedicado. Póngase en contacto con nosotros para iniciar una conversación sobre los requisitos de tenencia de su plataforma.

Preguntas frecuentes

¿Cuál es un ejemplo de aplicación multiinquilino?

Salesforce es el ejemplo más citado: cientos de miles de organizaciones comparten la misma infraestructura de aplicación, con el aislamiento de tenants aplicado en la capa de acceso a datos. Shopify sigue el mismo patrón para los comerciantes de comercio electrónico.

¿Cuáles son las principales desventajas de una arquitectura multiinquilino?

Las principales desventajas son el riesgo de vecinos ruidosos (la carga de trabajo de un tenant degrada la de otros), una mayor complejidad de la aplicación debido al filtrado y enrutamiento conscientes del tenant, y la dificultad de demostrar el aislamiento ante auditores de cumplimiento en modelos de esquema compartido.

¿Cuál es la diferencia entre una arquitectura de tenant único y una multiinquilino?

En una arquitectura de tenant único, cada cliente obtiene una instancia de aplicación y una base de datos dedicadas. En una arquitectura multiinquilino, una instancia de aplicación sirve a varios clientes, con el aislamiento aplicado mediante la lógica de la aplicación, la separación de esquemas o límites físicos de recursos, según el modelo elegido.

¿Qué significa la arquitectura multiinquilino en Salesforce?

Salesforce utiliza un modelo de infraestructura compartida en el que todas las organizaciones de clientes se ejecutan en la misma plataforma de aplicaciones. El aislamiento entre inquilinos se aplica mediante un motor de consultas propietario impulsado por metadatos que delimita automáticamente cada operación de datos a la organización solicitante, lo que hace imposible el acceso a datos de otros inquilinos a través de las rutas normales de la aplicación.

¿Cuándo debe utilizar un modelo aislado en lugar de un modelo agrupado?

Utilice un modelo aislado cuando un inquilino tenga requisitos normativos (HIPAA, PCI DSS), obligaciones contractuales de residencia de datos o compromisos de SLA empresariales que la infraestructura compartida no pueda satisfacer de forma fiable. Para la mayoría de los clientes de pequeñas y medianas empresas o de autoservicio, un modelo agrupado es la opción predeterminada más rentable.

Arquitectura multiinquilino: una guía práctica para arquitectos