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.
Existen 3 tipos de arquitectura para almacenar información en base de datos y a continuación te platico cuáles son:
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:
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.
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:
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 😉
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:
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:
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:
