En estas semanas, nos ha surgido la necesidad de plantear un desarrollo de producto SaaS en el que se pretende ofrecer un servicio web disponible para múltiples organizaciones. Es importante entender que cada organización tiene sus propias necesidades y debemos de construir el producto que mas se adecue a este entorno multiorganizativo. Este tipo de soluciones nos llevan hacia una arquitectura multitenant.
¿Qué es una arquitectura multitenant?
La arquitectura multitenant es una arquitectura software orientada a la nube, la cual implica una sola instancia de la aplicación, pero sirviendo a múltiples clientes u organizaciones. La idea básica de este tipo de arquitecturas es sencilla: tener una sola base de código que se ejecuta para todos los clientes, con una misma estructura de datos, pero la capa de datos separadas en distintos espacios de trabajo por cada organización.
Puede uno sentirse con la posibilidad de copiar todo el código base para cada organización y construir N aplicaciones fork por separado. Sin embargo, esta no puede ser la mejor solución ya que el equipo de desarrollo tendrá que gestionar N aplicaciones, y actualizar las características de cada instancia, pudiendo evolucionar en direcciones totalmente separadas. Esto se vuelve complejo, e inmantenible cuando el número de organizaciones que usan tu servicio empieza a crecer.
Con una aplicación SaaS con una arquitectura multitenant, el equipo de desarrollo web deberá implementar y admitir una sola base de código, y no múltiples mutaciones. De esta manera, podremos actualizar la aplicación SaaS simultáneamente para todas las organizaciones y será más sencillo gestionar la infraestructura del servidor.
Antes de afrontar la creación de una aplicación SaaS de este tipo, debemos abordar un problema importante: cómo aislar de forma segura los datos de cada cliente. Por lo tanto, la capa de base de datos requerirá de especial atención. Leyendo acerca de cómo solucionar esta casuística me he encontrado tres enfoques para diseñar esta capa de persistencia que veremos a continuación.
Diseño de la capa de persistencia en una arquitectura multitenant
Como hemos adelantado, la principal preocupación a la hora de construir una aplicación multitenant es la capa de persistencia y por ello debemos de tener en cuenta tres aspectos principales, ya que es probable que cada cliente exija requisitos en como se debe almacenar su información:
- El nivel de aislamiento de los datos de cada organización
- Las dificultades para la restauración de la información
- El nivel de encriptación debido al tipo de dato que se maneja y las leyes que obligan a ciertos niveles de seguridad
Por ello, como hemos comentado existen 3 tipos de opciones que esta arquitectura puede adoptar en la capa de persistencia:
- La primera opción es tener una base de datos por cada organización
- La segunda opción es usar la misma base de datos pero proporcionar a cada organización su propio esquema de tablas
- La tercera opción, es que las organizaciones compartan el mismo esquema en la misma base de datos
Una base de datos para cada organización
La mayor ventaja de este diseño es que aseguras un alto nivel de seguridad en los datos. Cada instancia de base de datos está separada en un servidor totalmente separado, por lo que se pueden cumplir necesidades como que la información esté alojada en distintas regiones. Esto implica que desde una organización no se puede acceder a los datos de otra, por lo que el nivel de aislamiento es alto e implica grandes ventajas.
Otra ventaja de esta aproximación es la flexibilidad, ya que igual que tenemos la posibilidad de elegir la región donde se almacenará la información, también podemos ser flexibles en decidir el tipo de encriptación de los datos. Quizás alguno de los clientes tienen algún requisito de encriptación, sin embargo, otros no es necesario. El aislamiento de las base de datos también facilita la facilidad para restaurar la información y los backups de cada organización. En caso de cualquier problema de corrupción de información, solo afectaremos a una de las organizaciones.
Viendo estas principales ventajas, parece que esta aproximación es una buena solución. Sin embargo, no todo es oro lo que reluce. Aunque esta aproximación parece la adecuada, también implica que levantar una instancia de base de datos independiente para cada organización conlleva un coste, por lo que el precio será mayor.
Para decidir si esta aproximación es la adecuada es importante conocer las necesidades de los clientes. Por ello debemos de conocer estos requisitos y descubrir si encaja con sus necesidades de seguridad y flexibilidad, además de están dispuestos a asumir un coste mayor a cambio de estas ventajas.
Si esta no es tu aproximación, vamos a descubrir una aproximación mas barata que proporciona un aislamiento parcial, los esquemas separados por cada organización:
Esquemas separados por cada organización
Como hemos visto, la aproximación anterior era ideal, sin embargo requería de un coste alto que quizás no podamos asumir, por ello esta nueva aproximación implica menor coste de base de datos.
Con este diseño de esquemas separados la aplicación conectará a una sola instancia de base de datos. Sin embargo, cada organización tendrá su propio esquema de datos. La separación de estos esquema reduce la complejidad de la infraestructura de servidor y su coste, además de proveer de beneficios de un aislamiento (aunque de una manera parcial) y de cierta flexibilidad.
Sin embargo, la separación en esquemas, puede complejizar temas como las copias de seguridad y la restauración de datos de una organización. Un cambio en la instancia de la base de datos para una organización puede afectar al resto de organizaciones, por lo que hay que tener especialmente cuidado en ciertas acciones.
Como hemos visto es una alternativa más económica y tratamos los datos de los clientes de una manera más individual.
Esquema compartido por las organizaciones
La última opción es que tengamos un esquema compartido por todas las organizaciones, lo que implica una aproximación fácil de implementar en las fases tempranas del desarrollo. Los datos de todas las organizaciones estarán almacenados en las mismas tablas, por lo que para recuperar la información se deberá de asignar un identificador que represente quien es el dueño de ese dato.
Este esquema compartido tiene ciertos beneficios, ya que no es necesario crear y ajustar esquemas para cada organización ni tampoco la necesidad de ejecutar servidores adicionales para bases de datos.
Pero, descubramos qué desventajas implica este esquema compartido. Evidentemente, la flexibilidad y aislamiento de las otras dos aproximaciones las perdemos totalmente. Si el número de organizaciones que van a usar nuestro software, aumenta, vamos gradualmente complejizando la consulta de la información, su indexación y actualización.
Además con cualquier problema de seguridad que nos encontremos comprometemos los datos de todas las organizaciones. La seguridad es importante en esta aproximación ya que debemos de verificar el nivel de acceso del usuario y de su organización. Esto además implica complejizar el manejo de las solicitudes.
Conclusión
Una arquitectura multitenant proporciona beneficios a largo plazo en la construcción de aplicaciones SaaS en términos de mantenimiento, desarrollo e inversión. Sin embargo, siempre implica un reto para identificar que aproximación es la mas adecuada y cumple con el equilibrio adecuado de las necesidades.
Uno los retos más importantes es garantizar el nivel de seguridad suficiente y los acuerdos de nivel de servicio que se ofrecen a los clientes, por lo que hay que poner una balanza las ventajas e inconvenientes de cada aproximación y tratar de elegir la mas adecuada a nuestras necesidades.
Referencias
https://rubygarage.org/blog/three-database-architectures-for-a-multi-tenant-rails-based-saas-app
https://www.yunbitsoftware.com/blog/2017/05/19/arquitectura-multitenant-que-es/
