Com gestionar els teus clients en un entorn multitenant d’Azure | Part 1: Com aïllar cada Tenant?
Amb l’aparició del Cloud Computing, un dels usos més comuns que se li poden donar és desplegar les nostres aplicacions utilitzant el model SaaS (Software as a Service). Sense ser-ne conscients o sent-ho, utilitzem aquest model ja des de fa molts anys i, a més, ho fem cada dia: escoltem Podcasts amb una aplicació, el mateix amb la nostra música, pugem els nostres documents al núvol, enviem el correu, etc.
Hi ha moltes organitzacions que requereixen un model SaaS, i aquest pot ser accedit per diferents tipus d'”entitats”, poden ser altres organitzacions (com un SaaS de gestió de nòmines) – model Business to Business B2B -, poden ser persones individuals (com un SaaS de reproducció de podcasts) – model Business to Customer B2C -.
Siguin les “entitats” que siguin les que accedeixen al nostre SaaS al núvol; aquestes es denominen “Tenant” (que traduït literalment de l’anglès seria: inquilí).
La pregunta que m’agradaria poder ajudar a respondre a cadascun dels nostres clients a Itequia que requereixen un escenari semblant als descrits més amunt és:
- Com gestiono el meu entorn (ja no només SaaS), sinó tota la infraestructura associada, en un entorn multitenant?
- Com asseguro que cada tenant veurà les seves pròpies dades alhora que ofereixo la il·lusió que s’utilitza un sistema dedicat?
La resposta passa per cadascun dels punts que veurem en aquesta sèrie d’articles:
- Entendre els requeriments dels nostres tenants
- Entendre el nostre model de negoci i els requisits
- Cal considerar quin nivell d’aïllament (dades, recursos, etc) necessitem per a la nostra solució
Començarem aquest camí, revisant quins nivells d’aïllament entre cadascun dels nostres tenants ens podem plantejar oferir.
Nivells d´aïllament entre Tenants
Per començar, un dels punts a tenir en compte és saber diferenciar quin nivell d’aïllament aplicarem per a cada tenant al nostre sistema. Podem tenir en compte aquests elements en pensar què aïllem:
- Lògica de l’aplicació
- Dades
- Recursos d’Azure
I, com en tot, no és blanc o negre, sinó que hi ha diferents nivells d’aïllament que ens podem plantejar en funció dels requisits dels tenants (per exemple, el compliment de GDPR), requisits de disponibilitat del sistema, etc.
Així que podem veure diferents models d’aïllament juntament amb les consideracions que cal tenir en compte.
Totalment Aïllat
En aquest model res no està compartit. Cada recurs és un recurs dedicat a cada tenant:
És l’Individual Deployment o Stamp (segell) ja que cada cop que creem un nou tenant al nostre sistema apliquem (estampem) una plantilla de l’entorn.
En aquest escenari:
- Cada tenant té el seu propi entorn
- A nivell de càrrega de treball és l’òptim ja que tan sols hem d’aplicar el segell
- És el model que té més cost a nivell de recursos, atès que cap es pot compartir
Partició Vertical
En aquest cas, es tracta d’aplicar la plantilla compartida per diversos tenants alhora que també l’apliquem individualment a un o més.
L’aplicació d’aquesta aproximació se sol regir per requeriments dels usuaris i ens facilitarà alguns aspectes com:
- Desplegar la nostra solució a nivell global (diverses regions d’Azure), augmentant el rendiment del sistema en poder oferir-lo més a prop de cada tenant
- Oferir diverses modalitats de preu pel nostre sistema
- Oferir diferents SLAs
- Desplegar actualitzacions de la nostra aplicació de manera gradual
Partició Horitzontal
Aquest model respondria a:
En aquest exemple, estem compartint l’aplicació entre tots els nostres tenants, però mantenim aïllades les dades de cadascun en diferents bases de dades d’Azure.
En aquest cas cal tenir en compte que:
- Podem arribar al màxim de recursos en funció del “actius” que siguin els tenants
- Hem de saber determinar quin component serà dedicat i quin serà compartit i per què (per exemple, criteris de rendiment o de compliance)
Totalment Compartit
Com podeu intuir es representa així:
En aquest escenari tot és compartit per tots els tenants:
- Té un gran avantatge a nivell de costos ja que fem un ús més efectiu dels recursos
- Gestió més fàcil, tot és en un lloc, la complexitat del manteniment és menor
- Haurem de ser molt curosos ja que, en aquest cas ha de ser la lògica la que separi les dades dels tenants redirigint les peticions a les bases de dades dels tenants que estiguin fent la petició
- També cal parar atenció a l’ús de recursos per part de cadascun dels tenants
- Si tenim molts tenants no ens hauríem d’oblidar dels límits de recursos d’Azure
Però ara només hem vist alguns dels recursos (Web server i base de dades), però la nostra decisió pot variar quan més recursos entren en joc: analítiques, rendiment, Azure AD, Application Insights, Intel·ligència artificial, etc.
En aquest primer article de la sèrie, hem après les diferents opcions que tenim a l’hora d’aïllar els tenants de la nostra aplicació.
T’esperem a la part II, on revisarem: límits, escalat, gestió de la computació, costos i preus.