Modelos de inquilinato que se deben tener en cuenta para una solución multiinquilino

Hay muchas maneras diferentes de diseñar una solución para que sea de multiinquilino. Principalmente, esta decisión depende de si se comparten los recursos entre los inquilinos y cómo. 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 cada vez más inquilinos.

Resulta útil pensar en los distintos modelos de multiinquilinato, comprendiendo primero cómo se definen los inquilinos para su organización específica, qué controladores empresariales tiene y cómo planea escalar la solución.

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 considere que los inquilinos son esos clientes. Sin embargo, analice si los clientes tienen divisiones (equipos o departamentos) o si están presentes en varios países. Puede que deba considerar la posibilidad de tener un solo cliente asignado 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 tendrá varios usuarios. Por ejemplo, todos los empleados del cliente serán usuarios del mismo 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 ser su propio inquilino. 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 afectará 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 que debe tomar. Debe tener en cuenta preguntas como las siguientes:

• ¿Cuáles son sus objetivos empresariales?
• ¿Aceptarán los clientes todas las formas de multiinquilinato? ¿Cómo afectaría cada modelo de multiinquilinato a sus requisitos de cumplimiento o a los requisitos de cumplimiento del cliente?
• ¿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 vaya a escalar a un gran número de clientes, será muy importante implementar una infraestructura compartida. De lo contrario, tendrá que mantener un parque de instancias grande y en constante 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, por 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 costes operativos para implementar y volver a configurar estos recursos serán mayores, con cada nuevo cliente.

Por el contrario, si espera que su negocio solo vaya a tener 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 elevados, una infraestructura de un solo inquilino podría ser adecuada.

Inquilinos lógicos y físicos

A continuación, debe determinar lo que significa un inquilino para su solución en particular y si debe distinguir entre los inquilinos lógicos y los físicos.

Por ejemplo, considere un servicio de streaming de música. Inicialmente, podría crear una solución que pueda hacer frente fácilmente a miles (o incluso decenas de miles) de usuarios. Sin embargo, a medida que siga creciendo, 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 averiguar cómo asignar clientes específicos a instancias específicas de la solución. Puede hacerlo de forma aleatoria o geográfica, o puede rellenar una sola instancia y, a continuación, volcarla en otra. Sin embargo, probablemente deba 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 cada usuario como un inquilino lógico independiente y, a continuación, asignar los usuarios a inquilinos físicos que representan las distintas instancias que ha implementado. Tiene una asignación de uno a varios entre inquilinos lógicos y físicos, y puede mover inquilinos lógicos entre inquilinos físicos a su entera discreción.

En cambio, analice una empresa que compila software en la nube para despachos jurídicos. Es posible que los clientes insistan en 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, un inquilino lógico y físico es lo mismo.

Una diferencia clave entre los inquilinos lógicos y físicos es cómo se aplica el aislamiento. Cuando varios inquilinos lógicos comparten un único conjunto de infraestructura, se suele confiar en el código de la aplicación y en un identificador de inquilino de una base de datos, para mantener separados los datos de cada inquilino. Cuando hay inquilinos físicos, tienen su propia infraestructura, y puede ser menos importante que el código sea tenga en cuenta que opera en un entorno multiinquilino.

A veces, verá inquilinos físicos denominados implementaciones, superinquilinos o stamps. En el resto de este documento, usamos los términos implementaciones e implementaciones físicas para evitar confusiones entre los inquilinos lógicos y físicos.

Cuando reciba una solicitud para un inquilino lógico específico, debe asignarla a la implementación física que contenga los datos de ese inquilino, como se ilustra a continuación:

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 un único conjunto de 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, esto puede requerir recursos de Azure separados para cada inquilino, o incluso puede significar literalmente implementar una infraestructura física independiente, mediante el uso de hosts dedicados.

En lugar de pensar en el aislamiento como una propiedad diferenciada, debe considerar el aislamiento 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 dentro del proceso de autorización.
• Costo. Varios inquilinos pueden usar una infraestructura compartida, por lo que es 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.
• Confiabilidad. Si usa un único conjunto de infraestructura compartida, un problema con los componentes de un inquilino puede provocar una interrupción para todos los usuarios.
• Capacidad de respuesta a las necesidades de inquilinos individuales. Al implementar la infraestructura dedicada a un solo inquilino, puede ajustar la configuración de los recursos para los requisitos de ese inquilino específico. Incluso puede tenerlo en cuenta en el modelo de precios, donde puede hacer que los clientes paguen más por implementaciones aisladas.

La arquitectura de la solución puede influir en las opciones que tiene disponibles para el aislamiento. Por ejemplo, pensemos en un ejemplo de arquitectura de la solución de tres niveles:

• El nivel de interfaz de usuario puede ser una aplicación web multiinquilino compartida y 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 combinar y hacer coincidir distintos niveles de aislamiento en cada nivel. La decisión sobre lo que se comparte y lo que está aislado se basará en muchas cuestiones, como el coste, la complejidad, los requisitos de los clientes y el 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 sus requisitos, debe evaluarlo con algunos modelos y patrones de inquilinato comunes.

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 creadas con este modelo hacen un uso extensivo de la infraestructura como código (IaC) o de las API de Azure Resource Manager. Puede usar este enfoque cuando necesite aprovisionar infraestructuras completamente independientes para cada uno de los clientes. Examine el patrón de stamps de implementación al planear 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. Puede ser importante para algunos clientes con una alta sobrecarga de cumplimiento normativo. Además, es poco probable que los inquilinos afecten al rendimiento del sistema de los otros, lo 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: la rentabilidad es baja, ya que no se comparte la infraestructura entre los inquilinos. Si un solo inquilino requiere un gasto determinado en infraestructura, es probable que 100 inquilinos requieran 100 veces ese coste, en gastos. 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 el conjunto. 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 la usan, como se muestra en el diagrama siguiente:

Ventajas: este modelo es atractivo debido al menor coste de usar una solución con componentes compartidos. Incluso si necesita implementar niveles superiores o SKU de recursos, sigue siendo habitual que el coste general de la implementación sea menor que un conjunto de recursos de un solo inquilino. Además, si un usuario o inquilino necesita mover sus datos a otro inquilino lógico, no tiene que migrar datos entre dos implementaciones independientes.

Riesgos:

• Asegúrese de separar los datos de cada inquilino y de no filtrar datos entre inquilinos. Es posible que tenga que administrar el particionamiento de los datos usted mismo. 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 único inquilino grande intenta realizar una consulta o una operación grande, ¿afectará a otros inquilinos?

• Determine cómo realizar el seguimiento y asociar los costes de Azure a los inquilinos, si esto es importante para usted. 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 cualquier cambio puede afectar a toda la base de clientes.

• La escala también puede ser un factor a tener en cuenta. Es más probable que se alcancen los límites de escala 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 la escala, el número de solicitudes para esa cuenta de almacenamiento podría alcanzar el límite de lo que dicha cuenta puede administrar. Para evitar alcanzar un límite de cuota de recursos, puede considerar la posibilidad de implementar varias instancias de los recursos (por ejemplo, varios clústeres de AKS o cuentas de almacenamiento) o distribuir los inquilinos entre los recursos que ha implementado en varias suscripciones de Azure.

• Es probable que haya un límite en cuánto se puede escalar una única implementación, y los costes 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 situarse en los extremos de estas escalas. En su lugar, puede considerar la posibilidad de crear particiones verticales de los inquilinos siguiendo estos pasos:

• 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 ancle cada inquilino a una implementación específica. Esto 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 la infraestructura, puede obtener algunas de las ventajas en los costes por tener 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. Incluso puede facturar a los clientes con una tarifa más alta por estar en una implementación de un solo inquilino, con lo que se recuperan algunos de los costes.

Riesgos: es probable que el código base deba diseñarse para admitir implementaciones multiinquilino y de un solo inquilino. Si planea permitir la migración entre infraestructuras, 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 debe tener una clara comprensión de en qué conjuntos de la infraestructura física se encuentran los inquilinos lógicos, 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. Esto significa que tiene algunos componentes compartidos, mientras 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 esta ilustración:

Ventajas: las implementaciones con particiones horizontales pueden ayudarle a mitigar los problemas de vecino ruidoso, si ha identificado que la mayor parte de la carga del sistema se debe a componentes específicos que puede implementar por separado para 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.

Pasos siguientes

Examine el ciclo de vida de los inquilinos.