Hay muchas maneras de considerar cómo trabajar con inquilinos en la solución. La elección del enfoque depende en gran medida de si comparte recursos entre los inquilinos y cómo los comparte. De forma intuitiva, es posible que no quiera compartir ningún recurso, pero esta opción se vuelve costosa rápidamente, a medida que el negocio se escala y se incorporan más inquilinos.
Cuando considere los distintos modelos de multiinquilinato, es útil tener en cuenta primero cómo se definen los inquilinos de su organización, cuáles son los motores de la empresa y cómo planea escalar la solución. En este artículo se proporcionan instrucciones para ayudar a los responsables técnicos a evaluar los modelos de inquilinato y sus inconvenientes.
Definición de un inquilino
En primer lugar, debe definir un inquilino para su organización. Tenga en cuenta quién es su cliente. Es decir, ¿a quién proporciona sus servicios? Hay dos modelos comunes:
- Negocio a negocio (B2B). Si los clientes son otras organizaciones, es probable que asigne los inquilinos a esos clientes. Pero plantéese si los clientes tienen divisiones (equipos o departamentos) o si están presentes en varios países o regiones. Puede que tenga que asignar un solo cliente a varios inquilinos si estos subgrupos tienen requisitos diferentes. De forma similar, es posible que un cliente quiera mantener dos instancias del servicio, para conservar los entornos de desarrollo y producción separados entre sí. Por lo general, un solo inquilino tiene varios usuarios. Por ejemplo, todos los empleados del cliente son usuarios de un solo inquilino.
- Negocio a consumidor (B2C). Si los clientes son consumidores, suele ser más complicado relacionar clientes, inquilinos y usuarios. En algunos escenarios, cada consumidor podría constituir un inquilino independiente. Sin embargo, analice si la solución la van a usar familias, grupos de amigos, clubs, asociaciones u otras agrupaciones que puede que deban acceder y administrar juntos los datos. Por ejemplo, un servicio de streaming de música podría admitir usuarios individuales y familias, y podría tratar cada uno de estos tipos de cuenta de forma diferente, en lo que se refiere a la separación en inquilinos.
La definición de inquilino afecta a algunos de los elementos que debe tener en cuenta o enfatizar al diseñar la solución. Por ejemplo, considere estos distintos tipos de inquilinos:
- Si los inquilinos son personas individuales o familias, es posible que deba preocuparse especialmente por la forma en que administra los datos personales y las leyes de soberanía de datos dentro de cada jurisdicción a la que atiende.
- Si los inquilinos son empresas, puede que deba ser consciente de los requisitos de cumplimiento normativo de los clientes, el aislamiento de sus datos y asegurarse de que cumple un objetivo de nivel de servicio (SLO) especificado, como el tiempo de actividad o la disponibilidad del servicio.
¿Cómo se decide qué modelo usar?
La selección de un modelo de inquilinato no es solo una decisión técnica. También es una decisión comercial. Debe tener en cuenta preguntas como estas:
- ¿Cuáles son sus objetivos empresariales?
- ¿Aceptarán los clientes todas las formas de multiinquilinato? ¿Cómo afecta cada modelo de multiinquilino a sus requisitos de cumplimiento o a los requisitos de cumplimiento de los clientes?
- ¿Podrá escalar una solución de un solo inquilino a sus futuras aspiraciones de crecimiento?
- ¿Qué tamaño tiene el equipo de operaciones y cuánta administración de la infraestructura puede automatizar?
- ¿Esperan los clientes que cumpla los contratos de nivel de servicio (SLA) o tiene los SLO a los que aspira?
Si espera que su negocio se escale para incorporar a un gran número de clientes, es muy importante implementar una infraestructura compartida. De lo contrario, tendrá que mantener un conjunto de instancias de recursos grande y en crecimiento. Es probable que la implementación de recursos individuales de Azure para cada cliente sea insostenible, a menos que aprovisione y use una suscripción dedicada para cada inquilino. Al compartir la misma suscripción de Azure entre varios inquilinos, puede que empiecen a aplicarse cuotas y límites de recursos de Azure, y los costos operativos de implementar y volver a configurar estos recursos aumentarán con cada nuevo cliente.
Por el contrario, si espera que su negocio solo tenga unos cuantos clientes, puede que valga la pena considerar la posibilidad de tener recursos de un solo inquilino dedicados a cada cliente. Asimismo, si los requisitos de aislamiento de los clientes son muy exigentes, un modelo de infraestructura de un solo inquilino podría ser adecuado, aunque mucho más costoso.
Inquilinos e implementaciones
A continuación, debe determinar lo que significa un inquilino para su solución en particular y si debe distinguir entre inquilinos lógicos e implementaciones.
Por ejemplo, considere un servicio de streaming de música. Inicialmente, podría crear una solución que pueda controlar fácilmente a miles (o incluso decenas de miles) de usuarios. Sin embargo, a medida que crece, es posible que tenga que duplicar la solución o algunos de sus componentes para escalar a la nueva demanda de clientes. Esto significa que tendrá que determinar cómo asignar clientes específicos a instancias específicas de la solución. Puede asignar clientes de forma aleatoria o geográfica o puede rellenar una sola instancia y luego iniciar otra (empaquetado en contenedores). Sin embargo, probablemente tenga que mantener un registro de los clientes que tiene y de la infraestructura en la que están disponibles sus datos y aplicaciones, para que pueda enrutar su tráfico a la infraestructura correcta. En este ejemplo, puede representar a cada cliente como un inquilino independiente y, después, asignar los usuarios a la implementación que contiene sus datos. Tiene una asignación de uno a varios entre inquilinos e implementaciones, y puede mover inquilinos entre implementaciones a su entera discreción.
En cambio, analice una empresa que crea software en la nube para despachos jurídicos. Es posible que los clientes insistan en tener su propia infraestructura dedicada para mantener sus estándares de cumplimiento. Por lo tanto, debe estar preparado para implementar y administrar muchas instancias diferentes de la solución desde el principio. En este ejemplo, una implementación siempre contiene un solo inquilino y un inquilino se asigna a su propia implementación dedicada.
Una diferencia clave entre inquilinos e implementaciones es cómo se aplica el aislamiento. Cuando varios inquilinos comparten una única implementación (conjunto de infraestructura), se suele confiar en el código de la aplicación y en un identificador de inquilino que está en una base de datos, para mantener separados los datos de cada inquilino. Cuando hay inquilinos con sus propias implementaciones dedicadas, tienen su propia infraestructura, y puede ser menos importante que el código tenga en cuenta que opera en un entorno multiinquilino.
A veces, se hace referencia a las implementaciones como superinquilinos o stamps.
Cuando reciba una solicitud para un inquilino específico, debe asignarla a la implementación que contenga los datos de ese inquilino, como se indica aquí:
Para obtener más información, consulte Asignar solicitudes a inquilinos.
Aislamiento de inquilinos
Una de las consideraciones más importantes al diseñar una arquitectura multiinquilino es el nivel de aislamiento que necesita cada inquilino. El aislamiento puede significar cosas diferentes:
- Tener una única infraestructura compartida, con instancias independientes de la aplicación y bases de datos separadas para cada inquilino.
- Compartir algunos recursos comunes, a la vez que se mantienen separados otros recursos para cada inquilino.
- Conservar los datos en una infraestructura física independiente. En la nube, esta configuración puede requerir recursos de Azure independientes para cada inquilino. En situaciones extremas, podría significar la implementación de una infraestructura física independiente mediante hosts dedicados.
En lugar de pensar en el aislamiento como una propiedad diferenciada, debe considerarlo como un continuo. Puede implementar componentes de la arquitectura que estén más o menos aislados que otros componentes de la misma arquitectura, en función de sus requisitos. En el diagrama siguiente se muestra un continuo de aislamiento:
El nivel de aislamiento afecta a muchos aspectos de la arquitectura, incluidos los siguientes:
- Seguridad. Si comparte la infraestructura entre varios inquilinos, debe tener especial cuidado de no acceder a los datos de un inquilino al devolver respuestas a otro. Necesita una base sólida para su estrategia de identidad y debe tener en cuenta la identidad de inquilino y de usuario en el proceso de autorización.
- El costo. Varios inquilinos pueden usar una infraestructura compartida, por lo que resulta más económico.
- Rendimiento. Si comparte la infraestructura, el rendimiento del sistema puede sufrir a medida que la usen más clientes, ya que los recursos se pueden consumir más rápido. Los problemas de rendimiento pueden verse agravados por los inquilinos con patrones de uso inusuales.
- Confiabilidad. Si usa un único conjunto de infraestructura compartida, un problema con un componente puede provocar una interrupción en todos los inquilinos.
- Capacidad de respuesta a las necesidades de inquilinos individuales. Al implementar la infraestructura dedicada a un solo inquilino, puede adaptar la configuración de los recursos para los requisitos de ese inquilino específico. Incluso puede tener esta funcionalidad en cuenta en el modelo de precios, permitiendo que los clientes paguen más por implementaciones aisladas.
La arquitectura de la solución puede influir en las opciones disponibles del aislamiento. Por ejemplo, considere una arquitectura de solución de tres niveles:
- El nivel de interfaz de usuario puede ser una aplicación web multiinquilino compartida en la que todos los inquilinos acceden a un nombre de host único.
- El nivel intermedio puede ser una capa de aplicación compartida, con colas de mensajes compartidos.
- La capa de datos podría ser bases de datos aisladas, tablas o contenedores de blobs.
Puede considerar la posibilidad de usar distintos niveles de aislamiento en cada nivel. La decisión sobre lo que se comparte y lo que está aislado debe estar basada en muchas cuestiones, como el costo, complejidad, requisitos de los clientes y número de recursos que puede implementar antes de alcanzar los límites y cuotas de Azure.
Modelos de inquilinato comunes
Una vez que haya establecido los requisitos, evalúelos en comparación con algunos modelos de inquilinato comunes y los patrones de implementación correspondientes.
Implementaciones automatizadas de inquilino único
En un modelo de implementación automatizada de un solo inquilino, se implementa un conjunto dedicado de infraestructura para cada inquilino, como se muestra en este ejemplo:
La aplicación es responsable de iniciar y coordinar la implementación de los recursos de cada inquilino. Normalmente, las soluciones que usa este modelo emplean de forma intensiva la infraestructura como código (IaC) o las API de Azure Resource Manager. Puede usar este enfoque cuando necesite aprovisionar infraestructuras completamente independientes para cada uno de los clientes. Piense en usar el patrón de stamps de implementación cuando tenga prevista la implementación.
Ventajas: una ventaja clave de este enfoque es que los datos de cada inquilino están aislados, lo que reduce el riesgo de pérdida accidental. Esta medida de seguridad puede ser importante para algunos clientes con una alta sobrecarga de cumplimiento normativo. Además, es poco probable que los inquilinos influyan en el rendimiento del sistema de los otros, un problema que a veces se denomina problema de vecino ruidoso. Las actualizaciones y los cambios se pueden implantar progresivamente en los inquilinos, lo que reduce la probabilidad de una interrupción en todo el sistema.
Riesgos: si usa este enfoque, la rentabilidad es baja, ya que no comparte la infraestructura entre los inquilinos. Si un solo inquilino requiere un costo de infraestructura determinado, es probable que 100 inquilinos requieran 100 veces ese costo. Además, es probable que el mantenimiento continuo (como la aplicación de nuevas actualizaciones de software o de configuración) lleve mucho tiempo. Considere la posibilidad de automatizar los procesos operativos y de aplicar cambios progresivamente en los entornos. También debe tener en cuenta otras operaciones entre implementaciones, como informes y análisis en todo la flota. Del mismo modo, asegúrese de planear cómo puede consultar y manipular datos en varias implementaciones.
Implementaciones totalmente multiinquilino
En el extremo opuesto, puede considerar una implementación totalmente multiinquilino, donde se comparten todos los componentes. Solo tiene un conjunto de infraestructura para implementar y mantener, y todos los inquilinos lo usan, como se muestra en el diagrama siguiente:
Ventajas: este modelo es atractivo porque el uso de una solución con componentes compartidos resulta menos costoso que usar recursos individuales para cada inquilino. Aunque necesite implementar niveles o SKU superiores de recursos para justificar la carga incrementada, lo normal es que el coste general de esta implementación sea menor que el de un conjunto de recursos de un solo inquilino. Además, si un usuario o inquilino necesita mover sus datos a otro inquilino, es posible que pueda actualizar los identificadores y claves del inquilino, y es posible que no tenga que migrar datos entre dos implementaciones independientes.
Riesgos:
Asegúrese de separar los datos de cada inquilino y evite la pérdida de datos entre los inquilinos. Es posible que tenga que administrar los datos de particionamiento. Además, es posible que tenga que preocuparse por los efectos que pueden tener los inquilinos individuales en el sistema general. Por ejemplo, si un inquilino grande intenta realizar una consulta o una operación grande, esto podría afectar a otros inquilinos.
Determine cómo realizar el seguimiento y asociar los costos de Azure a los inquilinos si lo considera conveniente.
El mantenimiento puede ser más sencillo con una sola implementación, ya que solo tiene que actualizar un conjunto de recursos. Sin embargo, también suele ser más arriesgado, ya que los cambios pueden afectar a toda la base de clientes.
También es posible que tenga que tener en cuenta el escalado. Es más probable que se alcancen los límites de escalado de los recursos de Azure cuando se tiene un conjunto compartido de infraestructura. Por ejemplo, si usa una cuenta de almacenamiento como parte de la solución, a medida que aumenta el escalado, el número de solicitudes para esa cuenta de almacenamiento podría alcanzar el límite de lo que esa cuenta puede administrar. Para evitar llegar al límite de cuota de recursos, puede considerar la posibilidad de desplegar un grupo de diferentes instancias de sus recursos (por ejemplo, varios clústeres de AKS o cuentas de almacenamiento). Incluso puede considerar la posibilidad de distribuir los inquilinos entre los recursos que va a implementar en varias suscripciones de Azure.
Es probable que haya un límite en cuánto se puede escalar una única implementación, y los costos de hacerlo pueden aumentar de forma no lineal. Por ejemplo, si tiene una base de datos única compartida, cuando se ejecuta a una escala muy alta puede agotar su rendimiento y tener que pagar cada vez más por un mayor rendimiento, para mantenerse al día con su demanda.
Implementaciones con particiones verticales
No tiene que elegir ninguno de los extremos de estas escalas. En su lugar, puede considerar la posibilidad de realizar un particionamiento vertical de los inquilinos mediante este enfoque:
- Use una combinación de implementaciones de inquilino único y multiinquilino. Por ejemplo, puede tener la mayoría de los niveles de aplicación y datos de los clientes en infraestructuras multiinquilino, pero puede implementar infraestructuras de inquilino único para los clientes que requieran un mayor rendimiento o aislamiento de datos.
- Implemente varias instancias de la solución geográficamente y asigne cada inquilino a una implementación específica. Este enfoque es especialmente eficaz cuando hay inquilinos en distintas zonas geográficas.
Este es un ejemplo que ilustra una implementación compartida para algunos inquilinos y una implementación de un solo inquilino para otro:
Ventajas: puesto que sigue compartiendo algo de su infraestructura, puede sacar ciertas ventajas en los costes por usar implementaciones multiinquilino compartidas. Puede implementar recursos compartidos más baratos para determinados clientes, como aquellos que están probando el servicio con una evaluación gratuita. Puede incluso facturar a los clientes con una tarifa más alta por estar en una implementación de un solo inquilino, lo que permite recuperarse de algunos de los costes.
Riesgos: es necesario diseñar el código base para admitir implementaciones multiinquilino y de un solo inquilino. Si tiene pensado habilitar la migración entre implementaciones, debe tener en cuenta cómo migrar los clientes de una implementación multiinquilino a su propia implementación de un solo inquilino. También tiene que saber qué inquilinos hay en cada implementación, de modo que pueda comunicar la información sobre los problemas del sistema o las actualizaciones a los clientes pertinentes.
Implementaciones con particiones horizontales
También puede considerar la posibilidad de crear particiones horizontales de las implementaciones. En una implementación horizontal, tiene algunos componentes compartidos, pero mantiene otros componentes con implementaciones de un solo inquilino. Por ejemplo, podría crear un único nivel de aplicación y, a continuación, implementar bases de datos individuales para cada inquilino, como se muestra en este diagrama:
Ventajas: las implementaciones con particiones horizontales pueden ayudarle a reducir los problemas de vecino ruidoso: si identifica que la mayor parte de la carga del sistema se debe a componentes específicos, puede implementar componentes por separado en cada inquilino. Por ejemplo, las bases de datos pueden absorber la mayor parte de la carga del sistema, porque la carga de consultas es alta. Si un único inquilino envía un gran número de solicitudes a la solución, el rendimiento de una base de datos puede verse afectado negativamente, pero las bases de datos de otros inquilinos (y los componentes compartidos, como el nivel de aplicación) no se ven afectadas.
Riesgos: con una implementación con particiones horizontales, debe seguir teniendo en cuenta la implementación y administración automatizadas de los componentes, especialmente los componentes que usa un solo inquilino.
Prueba del modelo de aislamiento
Sea cual sea el modelo de aislamiento que elija, asegúrese de probar su solución para verificar que los datos de un inquilino no se filtran accidentalmente a otro y que cualquier efecto de vecino ruidoso es aceptable. Considere la posibilidad de usar Azure Chaos Studio para introducir deliberadamente errores que simulan interrupciones del mundo real y comprobar la resistencia de la solución incluso cuando los componentes no funcionan correctamente.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- John Downs | Ingeniero principal de software
Otros colaboradores:
- Chad Kittel | Ingeniero principal de software
- Paolo Salvatori | Ingeniero de clientes principal, FastTrack for Azure
- Arsen Vladimirskiy | Principal Customer Engineer, FastTrack for Azure
Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.
Pasos siguientes
Examine el ciclo de vida de los inquilinos.