e-Valúame

Tag Archives: multitenancy

¿Importa el multitenancy?

Siempre que hablo de este tema me tiran tomates pero es lo que tiene el masoquismo, que tienes que darle de comer. En fin, allá que voy. El caso es que muchas empresas se empeñan confundir “adrede” saas con ASP, y eso que por definición no te puedes confundir adrede, pero lo hacen para aprovechar el tiron del saas o el cloud computing que no consiguió en su día el ASP.

Vaya por delante que no tengo nada en contra del ASP, es más hay modelos de ASP que tienen ventajas competitivas frente al saas,  pero decir que ASP es lo mismo que saas sería faltar a la verdad.

Desde el punto de vista del cliente ASP y saas son confundibles e incluso puede parecer que es lo mismo porque practicamente la totalidad de los beneficios del saas lo tienes en ASP. Repasémoslos en este gráfico.
Acceso a través de internet, actualizaciones y backup sin intervención del cliente, pago por uso, infraestructura del proveedor, etc. Pero diferencias hay y la mayor de todas está en el multitenancy. Recordemos que la arquitectura Multitenancy te asegura que una misma infraestructura (servidor de aplicaciones y BBDD) logre dar servicio a todos los clientes. Por contra el servicio más común de un ASP es proporcionar una infraestructura por 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 cliente? Pues bajo mi punto de vista, si. Veamos:

  • EL TCO en un ASP es mayor. Por lógica no es lo mismo adquirir y mantener N infraestructuras que una, y si el gasto de mantenimiento es mayor, ¿Que pasará con el precio a trasladar al cliente?. Esta es una de los beneficios del saas que no comparte con el ASP.
  • Mayor probabibilidad de fallos en el mantenimiento. De igual forma cuanto más grande sea la infraestructura a mantener mayor probabilidad de fallo. No es lo mismo actualizar una infraestructura que actualizar N, sobretodo si cada infraestructura está personalizada y adaptada a cada cliente.
  • Precios cada vez más competitivos. A medida que crece el número de clientes que utilizan la solución saas se va optimización el uso de la infraestructura, esto conjugado con un mercado competitivo hace que los precios del saas sean cada vez más bajos.  Esto hace que un ASP no pueda competir  aunque hagan uso de la virtualización para dar el servicio.
  • Posibilidad de acceder a la aplicación desde el primero momento. Quizás no sea un requerimiento para todos los clientes pero la arquitectura multitenancy ofrece esa flexibilidad para que puedas acceder desde el primer minuto a la aplicación, algo que el ASP no puede ofrecer. Otra historia es parametrizar la aplicación.
  • Actualizaciones del software más frecuentes. En saas, dado que se trata de mantener una aplicación para todos, es perfectamente asumible y deseable que el proveedor actualice la aplicación con relativa frecuencia. En ASP la historia se complica porque la actualización de la aplicación se debe realizar a cada cliente. Sé de algún ASP que tarda más de un mes en actualizar a todos sus clientes y por tanto es algo que no lo realizan más una o dos veces al año.

Lo dicho, importa y mucho. Pero insisto, el modelo ASP funciona, tiene su ventajas y este post solo pretende explicar los beneficios del multitenancy.

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

Semanario – Semana 7/2009

Estas son la noticias que más me han llamado la atención durante esta semana:

 Sincroniza tus email de Gmail con los de Zoho Mail .- Zoho nos enseña a sincronizar los emails de ambas soluciones orientándolo para dar respuesta a la necesidad de realizar backup de tus correos.  Tontos no son: te enseñan como hacer backup,  implicitamente usas su herramienta y se posicionan junto a Gmail. Hace poco hicieron un movimiento parecido cuando Google decidió dejar de continuar Google Notebook y Zoho sacó un herramienta para importar el Notebook de Google en Zoho Notebook. 

McAfee crea una unidad específica para SaaS.- La nueva unidad, SaaS Security Business Unit, agrupará todos los productos de McAfee que son entregados a los clientes sobre Internet, incluida su tecnología de escaneo de seguridad  y sus soluciones de protección Web y de correo electrónico, así como su gestión remota de software y hardware basada en host.

Dos formás de llevar a cabo la arquitectura multitenancy.-    El multitenancy es uno de los pilares clave del  software como servicio que genera economías de escala derivadas de la optimación de recursos físicos y humanos.  Este blog dibuja dos esquemas de base de datos para poder llevarlo a cabo.

RightScale ofrece tambien sus servicios para la EC2 de Europa.-  Desde el pasado mes de diciembre las maquinas Ec2 de Amazon cruzaron el atlántico para alojar en Europa y poder ser consumidas por clientes europeos reduciendo así la latencia. Ahora los servicios de escalabilidad, balanceo de carga y monitorización de las Ec2  que ofrece RightScale y que hasta ahora se limitaban a las máquinas alojadas en US, tambien será posible utilizarlos en las máquinas de Europa.

Nero ofrece servicios de almacenamiento online.- Aunque no es un servicio para almacenamiento puro donde puedas albergar cualquier tipo de  información, cada vez más empresas aprovechan sus herramientas in-house para dar servicios de almacenamiento en la nube. Recordemos que la infrastructure as a service (iaas o infraestructura como servicio) recoge los servicios de almacenamiento relacionado (BBDD) y no relacionado.

Velneo cuenta con nueva web y blog para su versión V7. El pasado mes de Octubre vió la luz esta nueva versión de Velneo que podrá consumirse in-house o en su platform as a service (Paas), y ahora disponen de una web y blog con cantidad de información sobre las diferentes partes del producto y descripciones detalladas sobre las formas de consumo.

Semanario – Semana 48/2008

Estas son las noticias que más me han llamado la atención en esta semana:

Facebook te cobra por las aplicaciones que alojes. En realidad el servicio que te da es el de certificar las aplicaciones fiables y aquellos que no menos fiables, no es necesario pagar sino lo deseas.

Opengoo: una aplicacion online en tu casa. Se trata de una aplicación office (manejo de documentos, email, calendario,etc.) con todas las caracteristicas del saas pero que te permite instalarlo en tu casa o en los servidores que tu elijas.

Consejos para el 2009 en el mercado del saas. Una presentación de Bessemer Ventures que teniendo en cuenta la coyuntura económica, aconseja una serie de acciones para que no cierres tu startup saas.

Una aplicacíon in-house para manejar almacenamiento out-house . Gladinet es una aplicación gratuita para Windows, que permite que manipular los archivos almacenados en servicios como Google Docs, Picasa Web Albums, Windows Live SkyDrive, y Amazon S3.

¿Quieres programar en Apex para alojar tus aplicaciones en la paas Force? Una presentación que te explica el concepto multitenancy y te enseña a utilizar las herramientas que tiene Force.

¿Cuales son los requisitos mínimos del Saas?

Desde el punto del cliente que va a adquirir los servicios de una aplicación ofrecida como servicio, existen una serie de requisitos mínimos necesarios que una Saas debe ofrecer:

Rendimiento.- Una saas debe ofrecer un rendimiento mínimo y aceptable para que sea atractiva su adquisición. El problema aquí es definir mínimo y aceptable y aunque es un concepto subjetivo puede ser medible en tiempos de respuesta en el acceso a los datos, de ejecución los procesos de negocio, de comunicación a la propia aplicación ( delay producido por el alojamiento geográfico de esta), etc….

Acuerdo de Nivel de Servicio ( en inglés Service Level Agreement) .- El ISV de la aplicación Saas debe proveerte de varios niveles de servicio al que los cliente pueda adherirse. Habrá clientes que necesiten su aplicación disponible 8×5 (5 dias a la semana, 8 h) y habrá que clientes que necesiten 24 X 7. El ISV deberá instalar en sus sistemas los mecanismos necesarios para poder ofrecer este tipo de acuerdos, esto es, backup,  cluster de alta disponibilidad de datos y aplicación, etc…..

Privacidad en las comunicaciones.- Debido a la importancia de los datos que puedan albergar las aplicaciones en necesario que la comunicacion que se realiza a través de Internet sea segura, esto es, la comunicación debe realizarse a través de https u otra forma de comunicación que asegure la privacidad de las comunicaciones.

Privacidad de los datos.- De igual forma el ISV debe asegurar que los datos esten seguros y accesibles única y exclusivamente por el dueño del dato. Esto debe ser especialmente perseguido en la aplicaciones multitenancy ( nivel 3 y 4 de maduración) que explique en este post.

Monitorización de la aplicación.- El cliente debe saber de alguna forma que es lo que ocurre en su aplicación, por ejemplo: quién accede, a qué procesos, a qué datos,etc. Esto es obligado cuando el pago por el uso de la aplicación se realiza a través de conceptos como horas de utilización de la aplicacion, consumo de espacio de disco, o cualquier otra forma que sea variable.

Acceso de a los datos.- El resto de la aplicaciones de la organización deben acceder a través de APIs o de Web Services , a los datos y lógica de negocio que se utilizan y genera por el uso de la saas, sobretodo, en clientes que tengan adoptado la arquitectura SOA en su sistema de información.

¿Cual es el modelo de saas óptimo?

Cuando nos enfrentamos a elegir qué aplicación saas queremos que cubra cierta funcionalidad para nuestra empresa o area funcional, debemos saber que es lo que nos ofrece el proveedor desde diferentes puntos de vista. Por ejemplo, no es lo mismo que el software te lo ofrezca a tí solo, que lo compartas con otros clientes y tampoco es lo mismo que el recurso que compartes sea el código de la aplicación que la base de datos donde lo almacenas.

Para decidir que es lo que más nos interesa desde el punto de cliente, antes veremos que es lo que actualmente nos podemos encontrar en el mercado tomando como referencia lo que Microsoft definió y llamó el modelo de madurez de saas. Este gráfico nos ayudará a entender los niveles de maduración que a continuación se describen (puntualización: cuando se habla de instancia se refiere a lógica de negocio y datos, no solo a código):

  • El primer nivel de madurez es similar al tradicional Aplicación Service Provider (ASP), modelo de entrega de software, que se remonta a la década de 1990. En este nivel, cada cliente tiene su propia versión personalizada de la aplicación , y cuenta con su propia instancia de la aplicación en los servidores del proveedor de saas.
  • En el segundo nivel de madurez, el proveedor del software ofrece una instancia para cada cliente (o inquilino) pero a diferencia del primer nivel donde cada cliente tiene su propia versión, en este nivel, todos los instancias utilizan la misma versión de la aplicación, y el proveedor cumple con las necesidades de los clientes mediante las opciones de configuración.
  • En el tercer nivel de madurez, el proveedor a traves de una única instancia da servicio a todos los clientes, ofreciendo la posibilidad de cada uno pueda configurar la metaestructura de la aplicación para personalizarla . Las políticas de autorización y seguridad permiten que cada cliente mantenga sus datos separados de los de otros clientes y, desde el punto de vista del usuario , no hay indicios de que la instancia esté siendo compartida entre varios clientes. Como varios clientes comparten una instancia, los datos de cada cliente son lógicamente separados de la de otros clientes.
  • En el cuarto y último nivel de madurez, el proveedor da servicio a varios clientes a traves de varias instancias de nivel 3 balanceando la carga ( clientes conectados a cada instancia) de cada instancia . Cada instancia puede dar servicio a varios clientes desde máquinas distintas ofreciendo este nivel un alto grado de escalabilidad , ya que el número de servidores pueden ser aumentados o disminuidos, según sea necesario para satisfacer la demanda, sin necesidad de rediseño de la aplicación. Salesforce ofrece un nivel 4 de madurez con posibilidad de configurar tus propias tablas compartiendo la misma BBDD.

Como se puede ver a medida que aumenta el nivel de madurez se obtiene un mayor aprovechamiento de las economías de escala provinientes de la reducción en cada nivel de los recursos necesarios que componen la solución y por tanto del menor mantenimiento.

Desde el punto de vista del proveedor el nivel de madurez elegido para su aplicación Saas dependerá del compromiso entre el coste de la solución y el beneficio a obtener a corto,medio y largo plazo. Tambien dependerá de los productos propietarios del proveedor que rodean a la solución saas, por ejemplo si el proveedor dispone de un servidor de aplicaciones propietario, rapido, estable y consume pocos recursos de la máquina, es posible que le merezca la pena quedarse en el primer o segundo nivel de madurez y ofrecer un servidor de aplicaciones para cada instancia o quizás no porque el mantenimiento de tener varios servidores de aplicaciones es mayor.

Desde el punto de vista del cliente, además de saber cual es el nivel de madurez que ofrece el proveedor ( hay que tener en cuenta que en todo momento hemos hablado a nivel de instancia) me parece importante que además informe de las posibilidades que tengo en cuanto a infraestructura, por ejemplo:

  • ¿ Puedo tener mi aplicación en una máquina en exclusividad?
  • ¿Puedo tener mi aplicación en un servidor de aplicaciones en exclusividad?
  • ¿Comparto el servidor de aplicaciones con varias instancias por cada cliente?
  • ¿Comparto la BBDD de Datos con otros clientes?
  • Si me ofrece un nivel 3 de madurez y comparto la BBDD. ¿A que nivel se comparte? ¿a nivel de tablas o nivel de esquema de usuario?

Por tanto, vistos los niveles de madurez y la posibles combinaciones de infraestructura que nos pueden ofrecer, estos serán los factores que intervendrán a la hora de adoptar la solución:

  • Seguridad de los datos, habrá clientes que prefieran un nivel de madurez bajo para que sus instancias ( logica y datos) esten separadas del resto de instancias correspondientes a los otros clientes por miedo que sus datos puedan ser vistos por otros clientes.
  • Rendimiento, de igual forma habrá clientes que prefieran que sus instancias esten separadas para que el rendimiento no sea dependiente del numero de clientes que se conecten a la instancia, incluso preferiran que el servidor de aplicaciones sea diferente.
  • Escalabilidad, el potencial crecimiento de uso de la aplicación puede tambien ser determinante y los niveles bajos ofrecen soluciones menos optimas para el proveedor y por tanto más caras que los altos.
  • Nivel de servicio (disponibilidad de la aplicación), por ejemplo un nivel 4 de madurez nos garantiza un nivel cercano al 100% de servicio de la aplicación y posiblemente un coste reducido por el uso del mismo.
  • Coste del saas, a priori un nivel bajo de saas debería ser más caro que un nivel alto de saas y por tanto esto influirá en la decisión del cliente. Digo que debería porque un saas con un nivel de madurez alto requiere mayor diseño y desarrollo que uno bajo y por tanto requerirá mayor inversión ( aunque tambien se aprovechan de las economías de escala) y esto puede revertir en el precio al cliente final. Este dato es dificil de obtener y costoso de comparar.

Resumiendo, debemos tener en cuenta tanto los niveles de madurez como la infraestructura donde corren estos niveles y elegir qué solución es la que más nos adecuada que engancha con nuestra cultura de empresa, que cubrá nuestra necesidades de funcionalidad y que cumpla con nuestros requerimientos de seguridad , servicio de aplicación y rendimiento.