A la primera part d’aquesta sèrie d’articles sobre Com gestionar els teus clients en un entorn multitenant a Azure revisem les diferents estratègies i nivells d’aïllament que podem aplicar a l’hora d’aïllar els nostres Tenants:
Aquestes estratègies ens mostraven el camí entre els dos extrems, totalment aïllat Vs totalment compartit, que podem veure en aquesta figura:
La presa d’una decisió regida pel nivell d’aïllament que requereixen els nostres usuaris ha d’anar acompanyada d’altres aspectes que tenen més a veure amb el nostre propi model de negoci. Per això haurem de plantejar-nos també aspectes com:
En aquesta segona part de la sèrie; recorrerem aquests punts per poder tenir el màxim nombre d’eines disponibles per poder seguir el camí cap a la presa de la millor decisió final.
A l’hora de pensar en com desplegarem el nivell d’aïllament de cada tenant a Azure hem de tenir en compte que Azure té els seus propis límits. Per això, hem de comparar la decisió i l’aproximació que dissenyem, amb els límits d’Azure, que podem trobar a Azure Limits.
Per exemple, imaginem un escenari on decidim aplicar una estratègia d’aïllament total.
En aquest cas, l’eina d’Azure més apropiada serà l’ús d’un Resource Group per a cada tenant dins de la nostra subscripció.
És una decisió més que correcta, on hem de tenir en compte els límits d’Azure en què dins d’una subscripció com a màxim podem posar 980 resource groups (a data de redacció d’aquest article).
D’aquesta manera, a mesura que el nombre dels nostres tenants creixi, ens podrem trobar amb la següent situació, en què ja no puguem crear més Resource Groups a la nostra subscripció:
Per tant, si volem continuar creixent en el nombre de clients, haurem d’ampliar un nombre més gran de subscripcions:
Però, com cal suposar, situacions com aquesta ens les podem trobar més enllà de l’escenari d’aïllament total.
Pensem, per exemple, en el cas d’un recurs compartit, com ara un Storage Account de Azure. Podran accedir-hi el màxim d’usuaris que estigui definit com a límit a Azure:
A Azure cada recurs té els seus propis límits. Cal tenir-los en compte a l’hora de planificar l’estratègia de desplegament de la nostra solució.
A l’hora de parlar d’arquitectura i desplegament, també haurem de tenir en compte les diferents arquitectures de desplegament per a un entorn multi tenant que podem revisar a Architectural approaches for the deployment and configuration of multitenant solutions.
En aquest apartat, la meva intenció només és donar alguns matisos als quals prestar atenció atès que els detalls s’abordaran en articles posteriors. Mantingueu-vos al dia del nostre bloc per poder llegir totes les novetats.
Partint d’aquesta premissa, és important remarcar que a l’hora de plantejar-nos l’arquitectura del nostre sistema i les opcions de desplegament que encaixen més amb totes les decisions que haguem pres fins ara haurem de tenir en compte punts com:
Com hem comentat, tots aquests punts estan fora de l’abast d’aquest article, encara que en definitiva el que ens volen indicar és que parem atenció a cadascun dels punts del cicle de vida d’un tenant:
En resum, de moment en aquesta sèrie d’articles hem après la gestió d’un entorn multitenant a Azure recorrent:
T’esperem a la part III, on repassarem aspectes com són: