Cómo gestionar a tus clientes en un entorno Multi-Tenant de Azure | Parte 1: ¿Cómo aislar cada Tenant?
Con la aparición del Cloud Computing, uno de los usos más comunes que se le pueden dar es el de desplegar nuestras aplicaciones utilizando el modelo SaaS (Software as a Service). Sin ser conscientes o siéndolo, utilizamos este modelo ya desde hace muchos años y, además, lo hacemos cada día: escuchamos Podcasts con una aplicación, lo mismo con nuestra música, subimos nuestros documentos a la nube, enviamos el correo, etc.
Hay muchas organizaciones que requieren de un modelo SaaS, y este puede ser accedido por diferentes tipo de “entidades”, pueden ser otras organizaciones (como un SaaS de gestión de nóminas) – modelo Business to Business B2B – , pueden ser personas individuales (como un SaaS de reproducción de podcasts) – modelo Business to Customer B2C -.
Sean las “entidades” que sean las que acceden a nuestro SaaS en la nube; éstas se denominan “Tenant” (que traducido literalmente del inglés sería: inquilino).
La pregunta que me gustaría poder ayudar a responder a cada uno de nuestros clientes en Itequia que requieren de un escenario parecido a los descritos más arriba es:
- ¿Cómo gestiono mi entorno (ya no solo SaaS), sino toda la infraestructura asociada, en un entorno multi-tenant?
- ¿Cómo aseguro que cada tenant verá sus propios datos a la vez que ofrezco la ilusión que está utilizando un sistema dedicado?
La respuesta pasa por cada uno de los puntos que veremos en esta serie de artículos:
- Entender los requerimientos de nuestros tenants
- Entender nuestro modelo de negocio y los requisitos
- Hay que considerar que nivel de aislamiento (datos, recursos, etc) necesitamos para nuestra solución
Empezaremos este camino, revisando qué niveles de aislamiento entre cada uno de nuestro tenants podemos plantearnos ofrecer.
Niveles de aislamiento entre Tenants
Para empezar, uno de los puntos a tener en cuenta es saber diferenciar qué nivel de aislamiento aplicaremos para cada tenant en nuestro sistema. Podemos tener en cuenta estos elementos al pensar qué aislamos:
- Lógica de la aplicación
- Datos
- Recursos de Azure
Y, como en todo, no es blanco o negro, sino que hay diferentes niveles de aislamiento que podemos plantearnos en función de los requisitos de los tenants (por ejemplo, el cumplimiento de GDPR), requisitos de disponibilidad del sistema, etc.
Así que podemos ver diferentes modelos de Aislamiento junto a las consideraciones que debemos tener en cuenta.
Totalmente Aislado
En este modelo nada está compartido. Cada recurso es un recurso dedicado a cada tenant:
Es el Individual Deployment o Stamp (sello) ya que cada vez que creamos un nuevo tenant en nuestro sistema aplicamos (estampamos) una plantilla del entorno.
En este escenario:
- Cada tenant tiene su propio entorno
- A nivel de carga de trabajo es el óptimo ya que tan solo tenemos que aplicar “el sello”
- Es el modelo que tiene mayor coste a nivel de recursos, dado que ninguno se puede compartir
Partición Vertical
En este caso, se trata de aplicar la plantilla compartida por varios tenants a la vez que también la aplicamos individualmente a uno o varios de ellos.
La aplicación de esta aproximación suele regirse por requerimientos de los usuarios y nos facilitará algunos aspectos como:
- Desplegar nuestra solución a nivel global (diversas regiones de Azure), aumentando el rendimiento del sistema al poder ofrecerlo más cerca de cada tenant
- Ofrecer diversas modalidades de precio para nuestro sistema
- Ofrecer distintos SLAs
- Desplegar actualizaciones de nuestra aplicación de modo gradual
Partición Horizontal
Este modelo respondería a:
En este ejemplo, estamos compartiendo la aplicación entre todos nuestros tenants, pero mantenemos aislados los datos de cada uno de ellos en diferentes bases de datos de Azure.
En este caso hay que tener en cuenta que:
- Podemos llegar al máximo de recursos en función de lo “activos” que sean los tenants
- Tenemos que saber determinar qué componente será dedicado y cuál será compartido y por qué (por ejemplo, criterios de rendimiento o de compliance)
Totalmente Compartido
Como podéis intuir se representa de este modo:
En este escenario todo es compartido por todos los tenants:
- Tiene una gran ventaja a nivel de costes ya que hacemos un uso más efectivo de los recursos
- Gestión más fácil, todo está en un sitio, la complejidad del mantenimiento es menor
- Tendremos que ser muy cuidadosos ya que, en este caso debe ser la lógica la que separe los datos de los tenants redirigiendo las peticiones a las bases de datos de los tenants que estén haciendo la petición
- También hay que prestar atención al uso de recursos por parte de cada uno de los tenants
- Si tenemos muchos tenants no nos deberíamos de olvidar de los límites de recursos de Azure
Pero ahora hemos visto solo algunos de los recursos (Web server y base de datos), pero nuestra decisión puede variar cuando más recursos entran en juego: analíticas, rendimiento, Azure AD, Application Insights, Inteligencia artificial, etc.
En este primer artículo de la serie, hemos aprendido las diferentes opciones que tenemos a la hora de aislar a los tenants de nuestra aplicación.
Te esperamos en la parte II, en la que revisaremos: límites, escalado, gestión de la computación, costes, y precios.