Enfoques de Arquitectura Multitenant para Aplicaciones SaaS

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?

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

  • 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

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

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

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

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://www.netsolutions.com/insights/5-reasons-why-you-should-choose-multi-tenant-architecture-for-your-saas-application/

Artículo publicado en: https://adrianalonso.es/arquitectura-del-software/enfoques-de-arquitecturas-multitenant-para-aplicaciones-saas/

Full Stack Web Developer — adrianalonso.es

Full Stack Web Developer — adrianalonso.es