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:
La respuesta pasa por cada uno de los puntos que veremos en esta serie de artículos:
Empezaremos este camino, revisando qué niveles de aislamiento entre cada uno de nuestro tenants podemos plantearnos ofrecer.
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:
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.
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:
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:
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:
Como podéis intuir se representa de este modo:
En este escenario todo es compartido por todos los tenants:
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.