Conéctate con TwitterConéctate con Facebook
16

Multi-tenant: Qué es y por qué es importante

78785Puntos

hace 10 meses

Con el aumento en los últimos años de SaaS, necesitamos como desarrolladores entender cómo funcionan este tipo de servicios y la diferencia entre las diferentes arquitecuras de software que existen para estos desarrollos. Una de ellas es llamada multi-tenant.

Multi-tenant es una arquitectura de software que permite a una sola instancia de software servir a muchos clientes. En otras palabras, un solo desarrollo de código puede servir a multiples usuarios, separando la información sensible de cada uno y que solo sea visible por ellos.

Cada cliente del servicio es considerado como un tenant, esto permite que se pueda personalizar elementos de la aplicación, como son colores de la interfaz, pero no se personaliza el código como tal.

Algo que es importante resaltar en esta arquitectura es que un cliente no necesariamente es un usuario único, puede ser un grupo de usuarios. Por ejemplo algunos servicios funcionan los teams o grupos en los que un cliente puede tener un subdominio para entrar a la aplicación y este cliente puede tener multiples usuarios que ven la información de ese cliente.

Ventajas y desventajas de un multi-tentant

Ventajas.

  • Economía en desarrollo y mantenimiento, ya que los costos son distribuidos entre todos los clientes.
  • Fácil actualización, ya que es necesario solo actualizar una sola instancia.
  • Seguridad de la información de cada cliente, ya que cuenta con un schema separado para cada uno.
  • Optimiza el uso de recursos de los servidores.

Desventajas

  • Dificulta el desarrollo de características específicas para un cliente.
  • Único punto de falla: si la aplicación tiene un error o falla, fallará para todos los clientes.
multitenant.jpg

Arquitectura Multi-tenant aplicada a bases de datos.

Existen tres tipos principales de arquitecturas en las bases de datos, los cuales se explican a continuación pero primero es importante entender qué es un schema

En Postgres un Schema actúa como un nombre de espacio, lo que permite una organización/separación a la base de datos.
(Base de datos -> Schema -> Tabla)
En MySQL un Schema es una base de datos independiente.

Compartida (Shared)

Una Base de Datos - Un Schema

Esta arquitectura es la que se usa por defecto en la mayoría de aplicaciones, se separa los usuarios de la aplicación por una relación con la tabla de usuarios. Es útil para servicios B2C como Evernote o LastPass en sus planes individuales.

Ventajas

  • La capa de datos es fácil de construir (crear las tablas de la base de datos).
  • Todos los usuarios usan el mismo dominio de la aplicación.

Desventajas

  • Es costoso (Tamaño y cantidad de peticiones a la base de datos).

Separada (Isolated)

Cada cliente (tenant) tiene su propia base de datos

Esta arquitectura permite usar cualquier motor de base de datos, se puede relacionar como el proceso de virtualización en el que cada instancia se implementa para el nuevo cliente.

Ventajas

  • Mayor seguridad.
  • Fácil recuperación en caso de daño en la base de datos
  • Bajo consumo de recursos de procesamiento…

Desventajas

  • Dificultad para escalar.
  • Costoso en recursos de almacenamiento (se necesitan muchas bases de datos).
  • Dificultad para compartir información entre clientes.
  • Dificultad de actualización (hay que hacer el proceso por cada base de datos).

Híbrida (Semi - Isolated)

Una base de datos - Multiples Schemas

Esta arquitectura usa lo mejor de las dos anteriores y es posible usarla en PostgreSQL. Esto permite, por ejemplo, que cada uno de los clientes tenga usuarios y sus datos estén separados por cada schema.

Ventajas

  • Facilmente escalable.
  • Reducción de costos en almacenamiento y procesamiento.
  • Seguro (cada cliente tiene su información separada en el schema).
  • Compartir información entre clientes (hay tablas que se pueden acceder por todos los clientes).

Desventajas

  • El proceso de recuperación de datos de un schema es más complejo.
  • Es menos seguro que las bases de datos separadas.

Dependiendo de la aplicación que desarrolles y el stack tecnológico que uses, puedes elegir la que mejor se ajuste siempre teniendo en cuenta las ventajas y desventajas de cada una y el tipo de aplicación en la que estas trabajando y sobre todo pensando en el futuro de tu aplicación.

Diego Alexander
Diego Alexander
@GOLLUM23

78785Puntos

hace 10 meses

Todas sus entradas
0
3250Puntos
7 meses

Exite alguna recomendación con respecto al tipo de DB que se deben usar en este tipo de SaaS ?? es mejor utilizar bases de datos relacional o mejor utilizar NoSql o no existe ninguna diferencia al respecto salvo tener en cuenta un buen diseño del modelo de base de datos?