Multi-arrendamiento

Rentando tu aplicación en la nube

Multi-arrendamiento (multi-tenancy en inglés) es una manera de desarrollar aplicaciones en cloud computing, pero teniendo una sola instancia para múltiples clientes. Para lograr esto es necesario entender algunos conceptos:

Una app para todos y todos almacenando datos en ella

Cloud computing

Existen tres maneras de implementar cloud computing: Infraestructura como un Servicio, IaaS; Plataforma como un Servicio, PaaS; y Software como un Servicio, SaaS.

Los tres modelos del cloud computing permiten al usuario ejecutar aplicaciones y almacenar datos en línea con su respectivo nivel de control y flexibilidad, a continuación explico los detalles a grandes rasgos de cada uno de ellos:

Infraestructura como un Servicio

Es un espacio donde el proveedor de IaaS —Infrastructure as a Service — está a cargo de mantener los servidores. Nos dan la flexibilidad a los usuarios de adaptar y configurar nuestro ambiente como lo deseemos. Cada IaaS tiene un sistema operativo anfitrión, un hypervisor y varios ambientes virtualizados donde nosotros podremos instalar nuestras herramientas y aplicaciones.

1. Los usuarios pueden ejecutar aplicaciones nuevas o existentes en ambientes a su elección.
2. Brinda un hosting dedicado –servidores a demanda.
3. Cualquier plataforma o software montando en un IaaS se verá afectado si el Servicio está abajo.
4. Ejemplos: Amazon Web Services (AWS), EC2, Rackspace, and OpenStack.

Arquitectura IaaS

IaaS sirve para resolver los problemas de infraestructura por lo tanto está centrado en IT.

Plataforma como un Servicio

En un PaaS — Platform as a Service — , un proveedor tendrá varias instancias de sistemas operativos ejecutándose, cada una de ellas ejecuta componentes aislados de aplicaciones de diferentes usuarios. Estos componentes pueden ser: bases de datos, servidores, almacenamiento de datos, clusters de procesamiento de datos, o paquetes de desarrollo. El proveedor de la plataforma maneja el aislamiento y recursos de cada componente. Este servicio es más usado para desarrollo, ya que la infraestructura ya está resuelta, y el desarrollador puede enfocarse sólo en su aplicación.

1. PaaS nos da la habilidad de crear aplicaciones usando herramientas y lenguajes específicos, los cuáles son limitados por el servicio.
2. Es usado para desarrollar rápidamente, sin embargo no hay flexibilidad para migrar a otro PaaS.
3. Cualquier software o sitio montando en un PaaS se verá afectado si el Servicio está abajo.
4. Ejemplos: Google Cloud Platform, Force.com, and MS Azure Products, Platform.sh

Arquitectura PaaS

PaaS está enfocado a desarrollo.

Software como un Servicio

SaaS —Software as a Service — es una aplicación ya existente que fue implementada para cubrir una necesidad que pueden tener diferentes clientes o arrendatarios que a su vez tienen usuarios finales. Para poder lograr un SaaS, es de vital importancia implementar un manejo de datos multi-arrendamiento. La idea es que se tenga una sola instancia de la aplicación ejecutándose para todos tus clientes, pero manteniendo sus datos separados.

1. Las aplicaciones pueden ser gratis o por subscripción.
2. Las aplicaciones son accesibles a través de cualquier navegador, o pueden ser transferidas localmente pero se debe tener una conexión a Internet.
3. Son excelentes para trabajo colaborativo.
4. Las SaaS son aplicaciones genéricas.
5. Todos los clientes o arrendatarios se verán afectados si el SaaS está abajo.
6. Ejemplos son: Atlassian Jira, Slack, Google Suite, and Apiary.
7. Algunas SaaS para manejar la facturación y subscripciones son:

a. Zuora

b. Amazon DevPay

c. Recurly

d. Chargify

e. Spreedly

Arquitectura SaaS

Como la infraestructura y el desarrollo ya está resuelto, y el arrendatario creará datos al usar el servicio, SaaS está enfocado a datos.

Nube multi-arrendatario en SaaS

Componentes de una nube

Sin importar que proveedor se use, una nube siempre tendrá los siguientes componentes, tal vez usando nombres diferentes:

1. Servidor
2. Red
3. Seguridad (firewalls)
4. Almacenamiento

Una nube dedicada o privada sería aquella que tiene estos cuatro componentes dedicados, por el contrario si alguno o varios de estos componentes son compartidos, entonces estamos hablando de una nube multi-arrendatario.

Cloud Computing

En esta imagen podemos mostrar tres casos:

Agencia 1. Provee servicios que involucran máquinas virtuales ya que tienen servidores locales que ellos manejan. Por otro lado, el resto de los componentes los provee a través de una nube publica, por esta razón, sus servicios no están usando una nube dedicada sino una nube multi-arrendatario.

Agencia 2. Provee un servicio que sólo usa nubes dedicadas. Una de ellas está en sitio (on premise). La segunda está en otro lugar vía remota sin embargo es un servicio dedicado. Dado que ambas nubes tienen el 100% de sus componentes dedicadas, estas son nubes dedicadas.

Agencia 3. Pueden usar la nube pública pero no se les permite usar la nube privada, si lo intentan, el firewall se los va a prohibir. Al igual que la Agencia 1, ellos están usando una nube multi-arrendatario.

Arquitectura multi-arrendamiento

El termino multi-arrendamineto o multi-tenancy en general es aplicado al desarrollo de software para indicar una arquitectura en la cual se ejecuta una sola instancia de una aplicación la cual da servicio a múltiples clientes o arrendatarios. Esto es altamente común en soluciones SaaS.

Un arrendatario es un cliente que provee servicios a usuarios finales, genera datos y necesitará cierto nivel de personalización en su interfaz.

Como se dijo anteriormente, una solución de nube SaaS está enfocada en datos, entonces las diferentes implementaciones del multi-arrendamiento dependen en cómo se manejan los datos, los arrendatarios, y la información compartida. Para decidir cuál implementación es mejor para tu servicio, necesitas identificar ciertas características como la cantidad de arrendatarios, la información a compartir, el tamaño de los arrendatarios, y el tamaño del esquema de datos.

Entre más aislamiento de datos menos son los recursos compartidos.

Bases de datos separadas

1. Es el nivel más alto de aislamiento.
2. Requiere un fuerte mantenimiento de infraestructura.
3. Cada base de datos debe compartir el mismo esquema.
4. La aplicación necesita un data store por arrendatario, éste puede ser construido en tiempo de ejecución.
5. Crear reportes inter-arrendatarios puede ser posible, pero se vuelve truculento.

Schemas separados

1. Schema es un namespace para una tabla; no se refiere al esquema de la base de datos aunque puede ser un poco confuso.
2. Algunas bases de datos como PostgreSQL manejan schemas.
3. Usa la misma base de datos tal como lo hace el particionamiento horizontal o sharding.
4. La aplicación debe identificar el namespace, el cual es el nombre o id del arrendatario, en seguida hacer la operación a la base de datos.
5. No maneja transacciones perfectamente, por lo que puede ser complicado deshacer cambios.
6. Hay un schema público, donde la información compartida reside. Todos los arrendatarios pueden tener acceso a este espacio de datos.
7. Puede haber un schema de administrador, donde las cuentas pueden ser almacenadas.
8. Debe haber un schema por cada arrendatario.
9. Los datos de los arrendatarios son protegidos a través de la base de datos no por la aplicación.
10. Las migraciones de bases de datos deben realizarse por cada schema de arrendatario. Esto lo puedes resolver simplemente al implementar un ciclo en tus archivos de migraciones.
11. Crear reportes inter-arrendatarios es posible pero se hará una consulta por arrendatario y por tabla.
12. Este modelo es recomendado cuando se usan pocos arrendatarios grandes, ya que con muchos arrendatarios de este tipo sería difícil de escalar.

Scopes separados

1. Cada tabla debe tener un identificador de arrendatario — OrgId.
2. Los datos del arrendatario son protegidos por la aplicación.
3. Crear reportes inter-arrendatarios es posible con solamente una consulta por tabla.
4. La infraestructura es fácil de resolver, siendo que la seguridad y aislamiento van en el lado de la aplicación.
5. Este modelo es recomendado cuando se usan muchos arrendatarios pequeños, ya que las migraciones se vuelven difíciles de mantener.

Para cualquier caso debes decidir cómo manejar la elasticidad del tamaño de las bases de datos pero no es necesario que lo hagas desde cero, hay bases de datos disponibles como PaaS que resuelven el multi-arrendamiento y soportan los tres modelos o algunos de ellos.

También hay librerías y frameworks que manejan el modelado multi-arrendatario, como la gema de Ruby Aparment, o Hibernate. Estos dos soportan los tres tipos de multi-arrendamiento, y te permiten desarrollar tu aplicación como si fuera para un solo cliente e incluso agregar arrendatarios en tiempo de ejecución sin necesidad de reiniciar tu servidor. Te recomiendo darle una leída y seguir este tutorial que te ayudará paso a paso a implementar una aplicación multi-arrendamiento: Multi-tenancy in 15 minutes.

Al elegir la tecnología a usar hay que tomar en cuenta los requerimientos de tu aplicación pero sin olvidar los conocimientos e infraestructura con la que contarás. El multi-arrendamiento se puede implementar con el lenguaje y base de datos que más dominas, asegúrate de entender bien los conceptos, las librerías te hacen más fácil el camino pero podrías prescindir de ellas para lograr una aplicación exitosa.