e-Valúame

¿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

NBBDDEs 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

NESQUEMASEs 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

MODSAASEs 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?

Entradas relacionadas:

15 Responses to ¿Cómo se hace saas?

  1. Información Bitacoras.com…

    Valora en Bitacoras.com: 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 …..

  2. Javier dice:

    Excelente artículo. Muchas veces se olvidan los principios básicos técnicos que convierten al SaaS en una alternativa verdaderamente interesante. Ahora que el SaaS está en todas partes hay que tener este tipo de debates.

  3. Daniel Ríos dice:

    Muy buen post! Haré un RT en Twitter! ;-D

  4. Pedro Roses dice:

    El analisis es tecnologicamente perfecto pero por lo que dices parece que el cliente siempre estara a favor de la independencia de su base de datos.
    Otro punto clave es si al ISV, proveedor de la aplicación, le es interesante la compatibilidad entre las versiones on premise y saas y si es necesaria esta compatibilidad para asegurar la supervivencia en caso de discontinuidad del servicio.

  5. jcmmartin dice:

    Muchas gracias.
    Saludos

  6. En mi caso suelo utilizar una base de datos por empresa. Más concretamente, uso una base de datos global que almacena las uri e informaciones de acceso a las bases de datos de las empresas. Esto me permite, por una parte, hacer actualizaciones automáticas sobre todas las bases de datos (puesto que controla la bd global) y por otra parte mucha independencia y agilidad sobre cada empresa al usar cada una su propia bd. Como dices, tiene algunos fallos, como todo, pero por mi propia experiencia es la solución que mejores resultados me ha proporcionado.

  7. jcmmartin dice:

    @pedro Pues no pretendía eso. El cliente puede preferir pagar mas o menos, o puede arriesgarse a que en un modelo multi-base de datos tenga más probabilidad de errores. Desde luego es el mercado el que manda.

  8. jcmmartin dice:

    @Javier gracias por contarnos tu experiencia. Supongo que tu operativa debe ser delicada pero seguro que tienes mercado. Para gustos…
    Saludos.

  9. Angel dice:

    Interesante análisis.
    Yo también me plantee estas cuestiones cuando inicié mi primer proyecto personal, y finalmente decidí optar por un modelo con un único conjunto de tablas. Eso sí, creo que has pasado por alto (o mencionado vagamente) el problema que puede generar este modelo si se disponen de muchos clientes con múltiples datos, ya que a partir de cierto tamaño (decenas o cientos de millones) las BD empiezan a responder con tiempos demasiado altos a una simple consulta tipo SELECT, y puede ser la ruina de un SAAS. En cambio, en el módelo con múltiples BD te puedes encontrar con varios miles de bases de datos (una por cliente), lo cuál a su vez tiene un riesgo alto de errores debidos a excesivas conexiones en paralelo (una por cliente online) y probablemente un uso poco eficiente de la caché al estar gestionado individualmente. El modelo 2 no me acaba de convencer, porque creo que si buscas independencia de datos debes ir al modelo 1 y en otro caso al modelo 3.

  10. jcmmartin dice:

    Gracias Angel.
    Llevas mucha razón. Manejo saas desde mucho tiempo y es algo que tarde o temprano te dá en la cara. Aunque tambien es cierto que se sale de ello.
    En cuanto a la opción 2 creo que tiene verdadero valor para el proveedor para el cliente es cierto que preferiría la opción 1.
    Saludos

  11. […] ¿Cómo se hace saas? Comentarios Recientes […]

  12. […] que evidentemente suele mejorarse progresivamente. En realidad son el uso de técnicas como el multitenancy o la virtualizacion las que permiten estas economías de […]

  13. […] no es ASP ni tampoco es SoSaas, saas es sinonimo de multitenancy y esto le lleva a la verdadera gracia del […]

  14. […] cada cliente. Los proveedores de aplicaciones, ya sea saas  o ASP, saben de lo que hablo. Saben cómo se hace saas y saben qué beneficios les trae el multitenancy pero ¿ de verdad importa también para el […]

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *