Arquitectura Multi Tenant para aplicaciones SaaS en AWS

¿Cuáles son las ventajas de una arquitectura SaaS multiusuario? ¿En qué se diferencia de las instancias de tenant único? Desglosamos las diferencias y destacamos los beneficios de implementar una solución SaaS para la protección de datos.

Introducción

En los primeros días de la nube, las organizaciones se mostraban reacias a adoptar estrategias de nube debido principalmente a lo que se conoce como “resistencia al cambio”, lo que suele suceder básicamente con cualquier tipo de tecnología. Sin embargo en los últimos años con la adopción de nuevas Startups tecnológicas y sus implementaciones en modalidad cloud ese miedo ha ido desapareciendo. Ahora estamos viendo la rápida adopción de plataformas en la nube por parte de organizaciones de todas las formas y tamaños.

Single Tenant versus Multi Tenant ¿cuál es la diferencia?

La traducción literal de Tenant al español es: Arrendatario, por lo que podríamos hablar de arrendatario único (Single Tenant) o múltiples arrendatarios (Multiple Tenant). En la arquitectura Single Tenant una sola instancia de Software e infraestructura sirven a un solo cliente, cada cliente tiene su propia base de datos e instancia del software de forma independiente lo que por supuesto tiene ventajas y desventajas.

Ventajas de Single Tenant

• Seguridad: un solo cliente y un solo servidor a menudo están contenidos en un hardware seguro que es utilizado por un número limitado de personas.
• Confiabilidad: con un entorno completo dedicado a un cliente, los recursos son abundantes y están disponibles en cualquier momento.
• Personalización: el control sobre todo el entorno permite la personalización y la funcionalidad adicional, si se desea.

Desventajas de Single Tenant

• Mantenimiento: un solo arrendatario generalmente significa más tareas y mantenimiento regular para que todo funcione sin problemas y de manera eficiente.
• Configuración/Administración: en comparación, los entornos multiusuario de SaaS son rápidos de configurar y administrar.
• Costo: el arrendatario único generalmente permite más recursos, pero a un precio superior dado que solo hay un cliente para todo el entorno.

En la arquitectura multiusuario significa que una sola instancia del software y su infraestructura sirven a múltiples clientes. Cada cliente comparte la aplicación de software y también comparte una única base de datos. Los datos de cada arrendatario están aislados y permanecen invisibles para los otros arrendatarios.

Ventajas de Multi Tenant

• Costo asequible: múltiples clientes significa que el costo del entorno se comparte y esos ahorros (del proveedor de SaaS) generalmente se transfieren al costo del software.
• Integraciones: los entornos en la nube permiten una integración más sencilla con otras aplicaciones mediante el uso de API.
• Mantenimiento “manos libres”: técnicamente, el servidor pertenece al proveedor de SaaS, lo que significa que el proveedor maneja cierto nivel de mantenimiento de la base de datos, en lugar de que usted mismo mantenga el entorno.

Desventajas de Multiple Tenant

• Administración/personalización limitada: si bien tiene beneficios de integración adicionales, los cambios personalizados en la base de datos no suelen ser una opción.
• Seguridad: otros arrendatarios no verán sus datos. Sin embargo, se permiten múltiples usuarios (no asociados con su organización) en la misma base de datos. Este acceso más amplio reduce el control de la seguridad.
• Actualizaciones/Cambios: si depende de las integraciones con otros productos SaaS y uno actualiza su sistema, puede causar problemas con esas aplicaciones de conexión.

Las soluciones multi arrendatario están diseñadas para ser altamente configurables, de modo que las empresas puedan hacer que la aplicación funcione de la manera que desean. No hay que cambiar el código ni la estructura de datos, lo que facilita el proceso de actualización.

Arquitectura Single Tenant y Multi Tenant en Amazon AWS

Algunas de las oferta de AWS admiten instancias de uno o varios arrendatarios. Un ejemplo es Amazon EC2 en el que los usuarios pueden lanzar instancias dedicadas que se ejecutan en hardware dedicado de un solo arrendatario o compartidas donde varias cuentas comparten el hardware. Las instancias EC2 dedicadas son más caras que las instancias compartidas. La configuración predeterminada para EC2 es compartida, de hecho, este Blog en el que escribo actualmente este artículo está montado en una instancia EC2 de arquitectura Multi Tenant.

Tipos de arquitecturas Saas Multi Tenant

Una de las preguntas más importantes entre la adopción de múltiples arrendatarios sería qué arquitectura de múltiples usuarios se adapta mejor a su aplicación SaaS en AWS. Exploraremos las dos capas necesarias para permitir que su aplicación actúe como una plataforma SaaS real, ya que es fundamental decidir qué arquitectura multiusuario incorporará en su plataforma SaaS desde la capa de la aplicación y la base de datos. Estos dos tipos de arquitecturas multiusuario son la capa de aplicación multiusuario y la capa de base de datos multiusuario.

Capa de aplicación multiusuario

La capa de aplicación es un diseño arquitectónico que permite el hospedaje para usuarios y se entrega principalmente para aplicaciones de software como servicio (SaaS). En este primer modelo, la capa de aplicación se comparte comúnmente entre varios clientes. 

Arquitectura monolítica para SaaS

Probablemente, si no has visto este artículo o similares en este Blog, o si ya has desarrollado y diseñado tu propia aplicación SaaS, estoy seguro de que has caído en este enfoque. Los componentes monolíticos incluyen instancias EC2 en el nivel web, el nivel de aplicación y Amazon RDS con MySQL para su base de datos. La arquitectura monolítica no es un mal enfoque, con la excepción de que está desperdiciando recursos de forma masiva en los niveles mencionados. Al menos alrededor del 50% y el 70% de su uso de CPU/RAM se desperdicia debido a la naturaleza de la arquitectura monolítica (nube).

Arquitectura de microservicios para SaaS con contenedores y Amazon ECS

Los microservicios son un tipo de arquitectura recomendado, ya que proporcionan un equilibrio entre la modernización y el uso máximo de los recursos de la nube disponibles (instancias EC2 y unidades de cómputo). Así como también introduce un sistema descompuesto con servicios más granulares (microservicios). No hablaré mucho sobre los beneficios de los Microservicios ya que está ampliamente explicado en este mismo Blog. Sin embargo, le recomendaré que utilice la fórmula de arquitectura de arrendatarios múltiples + servicios de AWS + microservicios + Amazon ECS como orquestador de contenedores; pueden ser la pareja perfecta. Principalmente, considere que Amazon ECS se esfuerza menos por configurar su clúster y más NoOps para su equipo de DevOps.

Capa de base de datos multiusuario

La capa de base de datos es justo lo contrario del modelo anterior, la capa de aplicación. Aquí, la capa de base de datos se mantiene en común entre los arrendatarios y la capa de aplicación está aislada. Como siguiente paso, debe evaluar qué arquitectura de base de datos multi usuario buscar con tablas, esquemas o bases de datos en silos.

Al elegir la arquitectura de su base de datos, hay varios criterios para evaluar: escalabilidad (número de arrendatarios, almacenamiento por arrendatario, carga de trabajo), aislamiento de arrendatarios, costos de la base de datos (costos por arrendatario), complejidad del desarrollo (cambios en los esquemas, consultas, etc.), y complejidad operativa (agrupación de bases de datos, actualización de datos de arrendatarios, administración y mantenimiento de bases de datos). 

Base de datos única: una tabla por arrendatario

Una base de datos única de tabla por arrendatario hace referencia a un modelo agrupado y multiempresa de base de datos. Esta arquitectura de base de datos es la solución común y predeterminada de DevOps o arquitectos de software. Es muy rentable cuando se tiene una pequeña empresa emergente o unas pocas docenas de organizaciones. Consiste en aprovechar una tabla por cada organización dentro de un esquema de base de datos. Existen compensaciones específicas para esta arquitectura, incluido el sacrificio del aislamiento de datos, el ruido entre los arrendatarios y la degradación del rendimiento, lo que significa que un arrendatario puede abusar de los recursos informáticos y ram de otro arrendatario. Por último, cada nombre de tabla tiene su propio ID de arrendatario, que es muy sencillo de diseñar.

Base de datos única: un esquema por arrendatario

Una base de datos única de esquema por arrendatario, también conocida como modelo puente (database bridge model), es un enfoque de base de datos de múltiples arrendatarios que sigue siendo muy rentable y más seguro que la tenencia pura (modelo de base de datos agrupada), ya que se trata de una base de datos única, con la excepción del aislamiento del esquema de la base de datos por arrendatario. Si le preocupa la partición de datos, esta solución es ligeramente mejor que la anterior (una tabla por arrendatario). Del mismo modo, es fácil de administrar a través de múltiples esquemas en la configuración del código de su aplicación.

Servidor de base de datos por arrendatario

También conocido como Siled model, donde necesita una instancia de base de datos por cliente. Caro, pero lo mejor para el aislamiento y el cumplimiento de la seguridad. Esta técnica es significativamente más costosa que el resto de arquitecturas de bases de datos multiusuario, pero cumple con las normas de seguridad; lo mejor en rendimiento, escalabilidad y aislamiento de datos. Este patrón utiliza un servidor de base de datos por arrendatario, lo que significa que si la aplicación SaaS tiene 100 arrendatarios, habrá 100 servidores de base de datos, lo que resulta extremadamente costoso.

Cuando se necesita cumplir con certificaciones PCI, HIPAA o SOC2, es vital utilizar un modelo de base de datos en silos, o al menos encontrar una solución alternativa con los roles de IAM correctos y la mejor orquestación de contenedores, ya sea espacios de nombres de Kubernetes o Amazon ECS, una VPC por arrendatario y cifrado, etc.

Conclusión

No quiero alargar demasiado el artículo porque estos conceptos teóricos lo hemos abordado ya en otros artículos, pero la teoría es esencial para comprender cuál es el mejor escenario al momento de abordar una arquitectura para una app de tipo SaaS. La idea en una próxima entrega es abordar aspectos más técnicos de implementación usando algunos frameworks reconocidos.