En la primera parte de esta serie de artículos sobre Cómo gestionar a tus clientes en un entorno multitenant en Azure revisamos las diferentes estrategias y niveles de aislamiento que podemos aplicar a la hora de aislar a nuestros Tenants:
Estas estrategias nos mostraban el camino entre los dos extremos, totalmente aislado Vs totalmente compartido, que podemos ver en esta figura:
La toma de una decisión regida por el nivel de aislamiento que requieren nuestros usuarios debe ir acompañada de otros aspectos que tienen más que ver con nuestro propio modelo de negocio. Por lo que deberemos plantearnos también aspectos como:
En esta segunda parte de la serie; recorreremos estos puntos para poder tener el máximo número de herramientas disponibles para poder seguir el camino hacia la toma de la mejor decisión final.
A la hora de pensar en cómo vamos a desplegar el nivel de aislamiento de cada tenant en Azure debemos tener en cuenta que Azure tiene sus propios límites. Por lo que deberemos comparar la decisión y la aproximación que diseñemos, con los límites de Azure, que podemos encontrar en Azure Limits.
Por ejemplo, imaginemos un escenario en que decidimos aplicar una estrategia de aislamiento total.
En este caso, la herramienta de Azure más apropiada es el uso de un Resource Group para cada uno de los tenants dentro de nuestra suscripción.
Es una decisión más que correcta, en la que debemos tener en cuenta los límites de Azure en que dentro de una suscripción como máximo podemos poner 980 resource groups (a fecha de redacción de este artículo).
De esta manera, a medida que el número de nuestros tenants crezca, nos podremos encontrar con la siguiente situación, en la que ya no podamos crear más Resource Groups en nuestra suscripción:
Por lo que, si queremos seguir creciendo en el número de clientes, deberemos ampliar a un número mayor de suscripciones:
Pero, como cabe suponer, situaciones como esta nos las podemos encontrar más allá del escenario de aislamiento total.
Pensemos, por ejemplo, en el caso de un recurso compartido, como puede ser un Storage Account de Azure. Podrán acceder a ella el máximo de usuarios que esté definido como límite en Azure:
En Azure cada recurso tiene sus propios límites. Los debemos tener en cuenta a la hora de planificar la estrategia de despliegue de nuestra solución.
A la hora de hablar de arquitectura y despliegue, también deberemos tener en cuenta las diferentes arquitecturas de despliegue para un entorno multitenant que podemos revisar en Architectural approaches for the deployment and configuration of multitenant solutions.
En este apartado, mi intención tan sólo es dar algunos matices a los que prestar atención dado que los detalles se abordarán en posteriores artículos. Manteneros al día de nuestro blog para poder leer todas las novedades.
Partiendo de esta premisa, es importante remarcar que a la hora de plantearnos la arquitectura de nuestro sistema y las opciones de despliegue que más encajan con todas las decisiones que hayamos tomado hasta el momento deberemos tener en cuenta puntos como:
Como hemos comentado, todos estos puntos están fuera del alcance de este artículo, aunque en definitiva lo que nos quieren indicar es que prestemos atención a cada uno de los puntos del ciclo de vida de un tenant:
En resumen, de momento en esta serie de artículos hemos aprendido la gestión de un entorno multitenant en Azure recorriendo:
Te esperamos en la parte III, en la que repasaremos aspectos como son: