¿Cómo se hace saas?
Las aplicaciones como servicio tienen una característica que hace que el modelo sea especialmente eficiente: el multitenancy. Esta es la propiedad que permite ofrecer la misma aplicación a muchos usuarios y así distribuir el coste de la infraestructura y del mantenimiento entre todos.
Técnicamente no se trata solo de ofrecer la misma aplicación, sino de realizar una aplicación que permita con una sola instancia de la aplicación y una sola base de datos o mejor dicho un único de tablas relacionadas, dar servicio a todos tus clientes. Este es bajo mi opinión es el verdadero modelo saas y es el que más optimiza los recursos del negocio.
Sin embargo desde el punto de vista de la BBDD hay otras dos implementaciones multitenancy donde el tratamiento de los datos es diferente y aunque se acercan más al antiguo modelo ASP se venden como saas. Todas tienen sus ventajas y sus inconvenientes, no son peores ni mejores, cumplen con la condición de que dan soporte a muchos clientes, pero para mí estás no son saas y por eso me gustaría diferenciarlas.
Partamos de la base que tenemos una aplicación con su parte de código y su parte de datos, donde la misma ejecución o instancia del código va a dar servicio a todos los usuarios de la saas. Hasta aquí se mantiene el modelo saas y hora veamos cuales son las tres formas (incluida la propia del saas) que en que podemos diseñar la BBDD con sus ventajas y desventajas:
Una bases de datos por cada empresa o usuario
Es decir tenemos una misma instancia de aplicación para dar servicio a todos los usuarios pero una BBDD por cada empresa. Esta es la opción que está más lejos del modelo saas y más cerca al modelo ASP. Las tablas no necesitan ningún atributo para diferenciar si los datos pertenecen a un cliente a otro, pero si es necesario tener un estructura de datos que determine qué base de datos le corresponde a cada cliente.
Ventajas
- Un Motor de BBDD dedicado para cada usuario, por tanto no te afectan los datos y accessos de otros clientes.
- Posibilidad de tener una máquina dedicada a para los usuarios.
Desventajas
- Desde el punto de vista del proveedor
- Más recursos humanos. Mantenimiento tediosos y largos ya que cualquier modificación en el modelo de datos (tablas) hay que replicarla en todas la BBDD.
- Más recursos hardware. A partir de un cierto número de clientes necesitarás más máquinas para albergar las BBDD.
- Desde el punto de vista del cliente
- Más expuestos a errores. La replicación masiva da lugar a errores y puede afectar a los datos de tu aplicación.
- Precio alto. Mas recursos, mas mantenimiento requiere más gasto y esto incidirá en el precio.
Una base de datos con N conjunto de tablas
Es decir tenemos una misma instancia de aplicación para dar servicio a todos los usuarios y una sola base de datos con tantos conjuntos de tablas como clientes haya. Esta opción se acerca más al modelo saas aunque sigue siendo un dolor su mantenimiento. Las tablas tampoco necesitan un atributo para diferenciar si los datos pertenecen a un cliente a otro, y de igual forma necesitan una estructura de datos que determine que conjunto de tablas (esquema) pertenece a cada cliente.
Ventajas
- Menos inversión hardware que la opción anterior.
- Menos mantenimiento del hardware.
- Precio menor que la opción anterior
Desventajas
- Desde el punto de vista del proveedor
- Más recursos humanos. Mantenimiento tediosos y largos ya que cualquier modificación en el modelo de datos (tablas) hay que replicarla en todos los conjuntos de tablas.
- En caso de fallo del motor de BBDD no puedes dar servicio a ningún cliente.
- Desde el punto de vista del cliente
- Probabilidad de perdida de rendimiento. Estas compartiendo los mismos recursos hardware y el mismo motor de BBDD para todos los usuarios.
- Más expuestos a errores. La replicación masiva da lugar a errores y puede afectar a los datos de tu aplicación.
- Precio alto. Mas recursos humanos requiere más gasto y esto incidirá en el precio.
Una base de datos con ÚNICO conjunto de tablas
Es decir tenemos una misma instancia de aplicación y una sola base de datos con un único conjunto de tablas para dar servicio a todos los usuarios. Esta opción es la que defiendo para el modelo saas y el mayor problema que presenta es la complejidad de la aplicación y las estructura de datos. Las tablas necesitarán un atributo para diferenciar si los datos pertenecen a un cliente a otro.
Ventajas
- Menos recursos hardware que la opciones anteriores.
- Mantenimientos menos tediosos que evita la probabilidad de error en la actualizaciones de la estructura de datos.
- Mantenimientos más cortos que permiten tener la aplicación disponible más tiempo.
- Precio menor que la opciones anteriores
Desventajas
- Desde el punto de vista del proveedor
- Aplicación más compleja porque debe determinar el acceso a los datos correctos de cada cliente.
- En caso de fallo del motor de BBDD no puedes dar servicio a ningún cliente.
- Desde el punto de vista del cliente
- Probabilidad de perdida de rendimiento. Estas compartiendo los mismos recursos hardware y el mismo motor de BBDD para todos los usuarios.
- La complejidad de la aplicación puede dar lugar a errores.
En cualquiera de las tres opciones hay que tener sumo cuidado para atacar los datos, esquemas o BBDD correcta y asegurar la confidencialidad de los mismos, es decir, que el cliente solo pueda ver sus datos y no los de otros clientes. Y otra cosa importante, es que elegida una opción la aplicación sabe de este elección y todo el diseño y desarrollo de la aplicación esta condicionado por esto. Pasar después de una opción a otra requiere casi empezar desde cero.
Puede que seas usuario final, aquel que consume las aplicaciones, y que creas que esto no tiene importancia , pero es claro que depende de como se implemente la solución puede afectar de manera positiva o negativa a los usuarios de las saas, y por tanto a ti.
Ahora solo hay que decidir: ¿Que peso tiene el precio en tu decisión? ¿Prefieres pagar más por tener tus datos aislados? ¿Prefieres reducir la probalidad de fallos? ¿Prefieres pagar menos?
