Redefinición del concepto de multitenencia
Los términos multitenencia y SaaS suelen estar estrechamente relacionados. En algunos casos, las organizaciones describen el SaaS y la multitenencia como una misma cosa. Si bien esto puede parecer natural, equiparar el SaaS con la multitenencia suele llevar a los equipos a adoptar una visión puramente técnica del SaaS cuando, en realidad, el SaaS es más un modelo de negocio que una estrategia de arquitectura.
Para entender mejor este concepto, empezaremos explicando la visión clásica de la multitenencia. En esta visión centrada exclusivamente en la infraestructura, la multitenencia se utiliza para describir la forma en que los inquilinos comparten los recursos con el fin de aumentar la agilidad y la rentabilidad.
Supongamos, por ejemplo, que tiene un microservicio o una instancia de Amazon Elastic Compute Cloud
El problema de esta definición es que vincula demasiado directamente la noción técnica de multitenencia al SaaS. En esta definición se asume que la característica que define un modelo como SaaS es tener una infraestructura compartida multitenencia. Esta visión del SaaS comienza a fallar cuando observamos las diversas formas en que el SaaS se implementa en diferentes entornos.
En el siguiente diagrama se muestra un sistema SaaS que expone algunos de los desafíos a los que nos enfrentamos a la hora de definir el concepto de multitenencia.
Aquí puede ver el modelo SaaS clásico descrito anteriormente, con una serie de servicios de aplicaciones rodeados de servicios compartidos que le permiten administrar y controlar sus inquilinos de forma colectiva.
La novedad son los microservicios que hemos incluido. El diagrama incluye tres ejemplos de microservicios: productos, pedidos y catálogos. Si observa detenidamente el modelo de tenencia de cada uno de estos servicios, observará que todos emplean patrones de tenencia ligeramente diferentes.
SaaS y multitenencia
El servicio de productos comparte todos sus recursos (cómputo y almacenamiento) con todos los inquilinos. Esto se ajusta a la definición clásica de multitenencia. Sin embargo, si observa el servicio de pedidos, verá que tiene un recurso de cómputo compartido, pero un almacenamiento independiente para cada inquilino.
El servicio de catálogos añade otra variante en la que el recurso de cómputo es independiente para cada inquilino (una implementación de microservicio independiente para cada uno), pero el almacenamiento es compartido por todos los inquilinos.
Las variaciones de este tipo son comunes en los entornos SaaS. Vecinos ruidosos, modelos organizados en niveles o necesidades de aislamiento son algunas de las razones por las que podría decidir compartir o aislar partes de su solución SaaS de forma selectiva.
Teniendo en cuenta estas variaciones (y muchas otras posibilidades), resulta más difícil determinar cómo utilizar el término multiinquilino para definir este entorno. En general, en lo que respecta al cliente, se trata de un entorno multiinquilino. Sin embargo, si utilizamos la definición más técnica, algunas partes de este entorno son multiinquilino y otras no.
Por eso se hace necesario dejar de utilizar el término multiinquilino para definir los entornos SaaS. Aunque podemos hablar de cómo se implementa la multitenencia en una aplicación, debemos evitar usarla para definir una solución como SaaS. Si se va a usar el término multiinquilino, tiene más sentido emplearlo para describir todo el entorno SaaS como multiinquilino, sabiendo que es posible que algunas partes de la arquitectura se compartan y otras no. En general, este entorno se administra y controla según un modelo multiinquilino.
Un caso extremo
Para entender mejor el concepto de tenencia, veamos un modelo SaaS que tiene inquilinos que comparten cero recursos. El siguiente diagrama es un ejemplo de entorno SaaS que utilizan algunos proveedores de SaaS.
Pila por inquilino
En este diagrama, puede ver que todavía tenemos un entorno común alrededor de estos inquilinos. Sin embargo, cada inquilino se implementa con una colección de recursos dedicada. Los inquilinos de este modelo no comparten nada.
Este ejemplo pone en cuestión qué significa adoptar un modelo multiinquilino. ¿Se puede decir que es un entorno multiinquilino aunque no se comparta ninguno de los recursos? Los inquilinos que consumen este sistema tienen las mismas expectativas que tendría cualquier inquilino de un entorno SaaS con recursos compartidos. De hecho, es posible que no sepan cómo se despliegan sus recursos en el entorno SaaS.
Aunque estos inquilinos operan en una infraestructura organizada en silos, se administran y controlan de forma colectiva. Comparten una experiencia unificada de incorporación, identidad, métricas, facturación y operaciones. Además, cuando se lanza una nueva versión, se implementa para todos los usuarios. Para que este sistema funcione, no puede permitir personalizaciones únicas para inquilinos individuales.
Este ejemplo extremo proporciona un buen modelo para probar el concepto de SaaS multiinquilino. Aunque es posible que no consiga el nivel de eficiencia de una infraestructura compartida, se trata de un entorno SaaS multiinquilino totalmente válido. En el caso de algunos clientes, el ámbito de su empresa puede requerir que algunos de sus clientes o todos ellos utilicen este modelo. Eso no significa que no sean SaaS. Si utilizan estos servicios compartidos y todos los inquilinos usan la misma versión, este modelo sigue cumpliendo los principios fundamentales del SaaS.
Teniendo en cuenta estos parámetros y esta definición más amplia de SaaS, es obvio que hace falta reformular el uso del término multiinquilino. Tiene más sentido definir como multiinquilino cualquier sistema SaaS que se administre y controle de forma colectiva. Después, se puede recurrir a una terminología más específica para describir cómo se comparten o se dedican los recursos en la implementación de una solución SaaS.
