Tipos de arquitectura de datos para Software as a Service (SaaS)

by Alex Dzul

Tal vez has tenido la oportunidad de utilizar algún software en internet que no has tenido que instalar en tu computadora y que simplemente con abrir tu navegador de internet, ingresar la URL del sitio y registrarte has podido disfrutar de sus beneficios y funcionalidades. Bueno, esto que acabo de describirte se llama Software como Servicio, o SaaS por sus siglas en inglés (Software As A Service).

Este tipo de software nos permite trabajar con cualquier sistema de manera rápida y saltarnos pasos complejos de instalación, ejemplo de ello: Gmail, Facebook, Twitter, Slack, Canva, GDrive, Google, en fin…, esta lista es muy grande.

La complejidad técnica en este tipo de sistemas es más alta con respecto al software tradicional (ese que instalas en tu computadora) ya que gestiona grandes cantidades de información de diversos clientes al mismo tiempo y por tener información sensible de ellos, debe garantizar alta disponibilidad y seguridad al almacenarlo en bases de datos centralizadas.

El día de hoy quiero platicarte de algunas técnicas de manejo de datos para software que funciona como servicio y te mostraré las ventajas y desventajas de utilizar cada una de ellas.

Tipos de arquitectura de datos.

Existen 3 tipos de arquitectura para almacenar información en base de datos y a continuación te platico cuáles son:

1) Totalmente aislada.

Esta técnica lo utilizan aquellos sistemas de software que trabajan con una sola instancia de base de datos por cliente y que requieren de una instalación limpia del software para poder trabajar de manera correcta.

Nota: En mi opinión, este tipo de sistemas aún se consideran como software tradicional y no orientado a servicios (Saas).

Este tipo de arquitectura se utiliza para:

1. Situaciones en los que tu software tendrá muchas personalizaciones (funcionalidades exclusivas) y que evolucionará según las necesidades de cada cliente.
2. Esquemas de instalaciones privadas para garantizar seguridad en los datos y en los que el cliente desea tener el software en su nube privada.

¿Quienes lo utilizan?

Sistemas ERP.

Ej.:SAP, Syteline by Infor, Odoo Cloud.

Estos sistemas por su naturaleza de corte empresarial, requieren de aislamiento total por empresa a fin de garantizar privacidad en los datos del negocio.

WordPress.

Este gestor de contenido (CMS) maneja una sola base de datos y la información que genera no es compartida con nadie más.

Ventajas.

• Cliente tiene control total en sus datos.
• Alta seguridad.
• Esquema de respaldos muy sencillo.
• Es posible realizar personalizaciones al software a nivel base de datos.

Desventajas.  

• Las actualizaciones son complicadas, cada cliente tiene una versión de software y base de datos distinta.
• En ocasiones los costos para mantener activo el servicio es alto ya que las instalaciones tienen requerimientos mínimos en infraestructura de cómputo que hay que cubrir para que funcionen de manera óptima.

2) Totalmente compartida.

La gran mayoría de los sistemas SaaS manejan este esquema, una sola base de datos (o tal vez varias) manejan la información de todos sus usuarios.

Este tipo de arquitectura se utiliza para:

3. Situaciones en las que necesites manejar nombres de usuario o cuentas de correo electrónico únicos. Internamente estas bases de datos utilizan una tabla central de “Users” para dividir la información según el usuario que se conecte a la plataforma.
4. Esquemas de trabajo del tipo B2C (Business to Consumer).

¿Quienes lo utilizan?

Aquí podríamos hablar de muchos ejemplos pero por mencionar algunos:

Facebook.

Tu url de usuario “https://www.facebook.com/<username>” nadie más lo puede tener.

Gmail by Google.

¿Has visto alguna vez que otro usuario tenga tu misma dirección de correo? Lo dudo, eres único en su base de datos 😉

Ventajas:

• Solo necesitas crear la base de datos y tablas una vez en tu vida.
• Es fácil compartir información entre los usuarios.
• Solo necesitas un dominio para tu plataforma (https://midominionice.com)

Desventaja:

• Menos segura. Es necesario integrar nuevos esquemas de protección de datos.
• Al crecer el número de usuarios, igual crece el tamaño de la base de datos y las peticiones que se realizan por día pueden ralentizar el sistema.

3) Multi Inquilinos (Multi tenants).

Ni muy compartida, ni muy aislada.

Utiliza una sola base de datos pero separa la información en algo que se llaman “esquemas” (algo como carpetas) lo cual permite mantener un nivel de separación de datos bastante confiable utilizando una misma instalación del software en la nube.

Un inquilino es un cliente que se encuentra alojado en tu plataforma digital, le ofreces acceso a tus servicios de manera personalizada a través de un subdominio único en internet.

A nivel técnico es que la base de datos puede separar los datos a manera de grupos y las consultas ya no serán así:

“select * from <db>.<tabla>”

Si no que agrega un nivel más:

“select * from <db>.<squema>.<tabla>”

Uno de los motores de base de datos que tienen soporte para trabajar con multi inquilinos es “PostGreSQL” con esquemas.

Como pueden ver en la imagen anterior, los schemas en PostGreSQL son como carpetas que contienen tablas independientes pero todas se encuentran asociadas a una misma base de datos. ¡Increible!

Este tipo de arquitectura se utiliza para:

5. Ofrecer a los usuarios una forma personalizada de trabajar con la información de su base de datos.
6. Evitar que choque información, como nombres de usuarios, con otros clientes en tu sistema.

¿Quienes lo utilizan?

El ejemplo más claro de este tipo arquitectura es Slack.

Cuando creas un espacio de trabajo ingresas a través de un subdominio por ejemplo “micanal.slack.com” y no desde “slack.com”.

Tal vez perteneces a varios canales de slack y en cada uno te han solicitado que te registres para ingresar y has podido utilizar tu mismo correo sin que te salga un mensaje de error notificándote que ya existe alguien con ese mail. ¡Ahora todo tiene sentido, multi-tenants!

 Ventajas:

• Puedes compartir información entre clientes.
• A su vez, la información se encuentra aislada por “carpetas”.
• Muy fácil de escalar y mantener el código.

Desventaja:

• Durante la programación de código hay que hacer mayores consideraciones para evitar escribir sobre otros tenants.
• Si se daña la base de datos, todos los inquilinos se quedan sin servicio.
• Generación de respaldos un poco compleja.

Resumen.

Si te encuentras desarrollando una plataforma digital que deseas comercializar como Software As A Service y no sabes si la arquitectura de datos que estas utilizando es la correcta a futuro, te recomiendo estudiar más a fondo cada una de las técnicas que hemos visto en esta publicación e identificar cuál de ellas se apega más a las necesidades de tu usuario final objetivo.

Fuentes:

1. https://www.postgresql.org/docs/9.1/ddl-schemas.html