Modelos de arquitectura multi tenant para Azure (Parte 1)
Tags: architecture, azure, cloud, dotnet
Published: 2022-10-25 06:03:48

Continuando con los post sobre arquitectura de software, en especifico arquitectura multi tenant, ahora pasaremos a diseñar una solución, para esto debemos hacer algunas definiciones:

Inquilino (tenant):
Aquí debemos definir que es un inquilino en la organización, es decir a quien se le proporciona el servicio, y para esto tenemos 2 modelos comunes:

Negocio a negocio (B2B):
Cuando los clientes son otras organizaciones, es probable que a estos clientes se consideren como inquilinos, hay ocasiones en las cuales se debe considerar tener un cliente asignado a varios inquilinos y de igual manera un es posible que un cliente necesite varias instancias del servicio, en general un inquilino tendrá mas usuarios, por ejemplo los empleados del mismo cliente serán usuarios del mismo inquilino

Negocio a consumidor (B2C):
Cuando los clientes son consumidores, es un poco mas complejo relacionar clientes, inquilinos y usuarios, en algunos casos cada consumidor suele ser su propio inquilino pero habría que tomar en cuenta si la solución la utilizaran familias o grupos de personas relacionadas, por ejemplo algún streaming de música o contenido podría ser una solución B2C.

Al definir el inquilino hay que considerar los siguientes puntos para diseñar la solución:

si los inquilinos son personas o familias , hay que enfocarse en la forma en la cual administra los datos personales del usuario, cumpliendo las normativas y leyes vigentes.

si los inquilinos son empresas, hay que enfocarse en los requisitos de cumplimiento , aislamiento, y en este punto debemos considerar un SLO (objetivo de nivel de servicio)

Bien ya sabemos que considerar pero ahora como tomo la decisión de que modelo multi tenant utilizo?. para eso considera las siguientes preguntas:

1. ¿Cuáles son los objetivos empresariales?
2. ¿Aceptarán los clientes todas las formas de multi tennant?
3. ¿Cómo afectaría cada modelo de multi tenant los requisitos de cada cliente?
4. ¿Podrá escalar la solución de un solo inquilino?
5. ¿Qué tamaño tiene el equipo de operaciones y cuanta administración de la infraestructura puede automatizar?
6. ¿Esperan los clientes que se cumplan los SLA o SLO?

En caso de que se espere que el negocio valla a escalar a un gran numero de clientes, será de vital importancia implementar una infraestructura compartida , en caso contrario, se necesitara mantener un parque de instancias grande en constante crecimiento y es probable que la implementación de recursos individuales en Azure para cada cliente sea algo compleja de mantener.

Implementaciones para inquilinos

Cuando pensamos en una solución multi tennant debemos poder distinguir entre  inquilinos físicos y lógicos:
Una diferencia clave entre inquilinos e implementaciones es como se aplica el aislamiento. Cuando varios inquilinos comparten una única implementación, se suele confiar en el código de la aplicación y en un identificador de inquilino de una base de datos para mantener los datos separados de cada inquilino.
Cuando existen inquilinos con propias implementaciones dedicadas, por lo regular tienen su propia infraestructura, y puede ser menos importante que el código tenga en cuenta algunas operaciones multi tenant, por ejemplo cuando se recibe alguna solicitud para un inquilino especifico debe asignarla a la implementación que contenga los datos de ese inquilino

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/a2qtx6fqydl8bdu62udy.png)

Aislamiento de inquilinos

Otra consideración importante es el nivel de aislamiento que necesita cada inquilino, para esto es importante tomar en cuenta los siguientes puntos:

1) Tener un único conjunto de infraestructura, con instancias independientes de la aplicación y bases de datos separadas para cada inquilino
2) Compartir algunos recursos comunes y a la vez, se mantienen separados otros recursos para cada inquilino.
3) Conservar datos en una infraestructura física independiente y en la nube 

se recomienda pensar en el aislamiento como una continuidad y no una propiedad diferenciada, por ejemplo podemos implementar componentes que estén aislados de otros componentes dentro de la misma arquitectura, por ejemplo se muestra a continuación un diagrama para entender mejor el aislamiento:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/1ybt25aw1o1b4hytti01.png)

considerando el nivel de aislamiento afectan algunos aspectos de la solucion como:

Seguridad:
Al compartir la infraestructura se debe tener especial cuidado en no utilizar datos de otro cliente y tener una base solida en la estrategia de identidad

Costo:
Es mas económico tener varios inquilinos en la misma infraestructura compartida

Rendimiento:
Si se comparte la infraestructura el rendimiento puede verse afectado al incrementar el numero de usuarios en uso de la plataforma

Reliability: 
Un problema en un componente de un inquilino puede provocar una interrupción en todos los usuarios.

Se puede considerar la posibilidad de combinar los niveles de aislamiento y decidir sobre lo que se comparte y lo que estará aislado, todo depende directamente de la solución que se quiere realizar, como ya hemos comentado en artículos anteriores.

bien por hoy reflexiona, como es tu idea?, la solución se ajusta a lo que necesitas? déjame tus comentarios y debatamos acerca de esto, seria genial tu apoyo compartiendo este articulo y comentándome que te parece el inicio de esta serie de artículos y te espero en la [Parte 2](https://dev.to/ricardojosue04/modelos-de-arquitectura-multi-tenant-para-azure-parte-2-8ei).

Comparto mis redes para cualquier duda, y dirían por ahí ¡voy y vengo!

[Twitter](https://twitter.com/RicardoJosue04)
[YouTube](https://www.youtube.com/c/RicardoJosue)
[Facebook](https://www.facebook.com/RicardoJosue04/)
[Linkedin](https://www.linkedin.com/in/ricardojosue/)