Software como servicio – SaaS

Todo lo relacionado con Saas, Paas, Cloud Computing…..

Posts Tagged ‘multitenancy

Semanario – Semana 48/2008

leave a comment »

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.

Anuncios

¿Cuales son los requisitos mínimos del Saas?

with 2 comments

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.

Written by jcmmartin

mayo 18, 2008 at 10:29 am

¿Cual es el modelo de saas óptimo?

with 7 comments

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.

Written by jcmmartin

mayo 11, 2008 at 5:31 pm