Continuando con esta selección de artículos en esta tercera parte de TODO SOBRE EL SAAS, que nos presenta PRODUCCIONES INTERNACIONALES & PUBLICIDAD, gracias a la saasmanía de joven talentoso profesional Español el Ing.: José Carlos Moreno Martín.

¿Qué NO es saas?

 
Dicen que a la hora de llevar a cabo un proyecto y sobretodo explotarlo, debemos saber tanto lo que somos y lo que vamos a hacer como lo que no somos y lo que dejaremos para que otros lo exploten. En la web mucho se habla sobre saas, su significado, sus ventajas y desventajas, su público objetivo, etc. pero poco sobre lo que NO es saas.

Lo cierto es que echando un ojo a los post de este blog, de algún u otro modo, se dice lo que es  y lo  que no es saas, pero  no hay nada explícito que reuna toda la parte del NO. Este post intenta precisamente declarar aquello que no es saas para aclarar más el alcance del saas:

  1. Saas no es necesariamente una aplicación web y no todas las aplicaciones web son saas.
  2. Saas no es ASP tampoco es Sosaas, saas es sinónimo de multidenancy y esto lo lleva a la verdadera gracia del saas.
  3. Saas no es producto, es un servicio que se paga por el uso de producto e infraestructura y mantenimiento del software y los datos.
  4. Saas no tiene porque estar exento de servicios de parametrizacion, consultorías y formación.
  5. Saas no significa comprar licencia de uso.
  6. Saas no se instala en los servidores del cliente.
  7. Saas no lo actualiza el cliente, esta tarea la realiza el proveedor.
  8. Saas no es inversión, y se contabiliza como gasto 100% deducible como cualquier outsourcing.
  9. Saas no trabaja con la BBDD del cliente,  trabaja con su propia BBDD donde almacena todos los datos de sus clientes.
  10. Saas no está aislado de los sistemas del cliente. Saas cuenta con APIs para conexión con el resto de entornos.
  11. Saas no tiene sentido sin conexión a Internet.
  12. Saas no es CARO, más bien barato y en època de crisis una estupenda elección

Diferencia entre aplicación web y saas

A través de las estadísticas del wordpress “WordPress.com Stats” descubres muchas cosas de los que se asoman al blog.  Desde donde te visitan, que les gusta más, que les preocupa, que es lo que están buscando. Una de las preguntas por las que más entran al blog es precisamente el título del blog: aplicaciones web vs saas.

La primera diferencia: Una aplicación saas no tiene porqué ser web. Para algunos puede ser evidente  pero lo normal es que asociemos saas con una aplicación a la que se accede a través de navegador. Un ejemplo claro es una de formas de ejecución que propone Velneo disclaimer) donde un ejecutor de aplicaciones instalado en tu PC hace lo propio con las aplicaciones que están almacenadas en la Paas de Velneo, y otro ejemplo es Adobe AIR que sin mucho esfuerzo permite ejecutar aplicaciones web  y actualizarlas en caso de que sean modifiadas en el servidor. Por tanto no todo las saas son aplicaciones web.

El resto son todas aplicaciones web y esta claro que de si existir una diferencia, que existe, las aplicaciones saas web son un subconjunto de las aplicaciones web.  Ahora del conjunto de aplicaciones web , intentemos separar las que caen bajo el modelo saas o y las que quedan fuera. ¿Resulta sencillo? Quizás no cueste mucho porque el término concepto saas se asocia con las aplicaciones empresariales que ayudan en la gestión operativa y de administración de las empresas, pero si repasamos las características de las saas:

bensaas

¿Cuantas aplicaciones web las cumplen? Hay muchísimas aplicaciones on-line que cumplen estás características y no están relacionadas con el mundo empresarial: gestión de bookmarks online, gestión de tiendas online, cms online, incluso juegos online. Y a pesar de que hay que gente que opina que saas tiene sentido dentro del marco empresarial, en función de las características de arriba, ni una de ellas hacen referencia a que las “aplicaciones como servicio” deben ser tanto funcional como técnicamente para las empresas.

Podríamos poner el punto de inflexión en la parte técnica, es decir, en la capacidad de la aplicación para que sea corporativa y permita que muchas empresas con n usuarios utilicen la aplicación. Pero ni en las mismas definiciones sobre saas repartidas por la web,  hay una distinción clara sobre si la aplicación debe ser multi-organización (1 a N*M) o basta con que sea multi-usuario (1 a N) para que sea considerada saas. Además sería demasiado restrictivo decir que una aplicación es saas si es 1 a N*M y no lo es si es 1 a N, cuando el resto de características del saas las siguen cumpliendo (precisamente las que más definen el concepto), y posiblemente la aplicación no se hiciera 1 a N*M porque su público objetivo no eran las empresas, sino lo hubieran hecho con mínimas modificaciones en el diseño de la aplicación.

Aplicaciones web hay muchas y para descubrir si son saas o no te puedes hacer preguntas: ¿Es una misma aplicación para muchos usuarios como yo? ¿Tiene alguna parte de instalación en local? Pero la pregunta clave es:

¿estoy pagando o pagaré (si hablamos de modelos de negocio Fremium)  por el uso de la aplicación o por otro concepto (producto/servicio) que estoy comprando? 

Por ejemplo en una agencia de viajes online, tu no pagas por el uso de la aplicación de la agencia de viajes a pesar de que una parte de ella es saas (registro de tu datos, solicitudes de hoteles en curso, viajes pagados, etc)  pagas por el producto/servicio que te están ofreciendo a través de la aplicación.

En fin. Que todo este ladrillo para decir que en mi opinión si hablamos de aplicaciones web la única diferencia está en el uso de la aplicación web o dicho de otro modo, el concepto por el que pagas. Y el tema de si unasaas debe ser empresarial no lo comparto.  Este es mi punto de vista, seguro que hay por ahí más reflexiones que serán bienvenidas.

¿Que implicaciones tiene el modelo saas?

  • Desaperece el concepto de licencia, se pasa a hablar de pago por uso. De manera que los clientes se “suscriben” al servicio aportado para poder utilizar las aplicaciones ofrecidas en modalidad SaaS.
  • El software no se distribuye in-house, sino a través de la red.
  • La aplicación está hosteada, de manera que da servicio a muchos clientes.
  • El hecho de que la aplicación esté hosteada implica que no se abre de una infraestructura privada, sino de una infraestructura pública que permite que muchas empresas puedan suscribirse al servicio.
  • Es un modelo descentralizado de uso de aplicacione software.
  • Permite una escalabilidad sin límites.

Este modelo es una de los elementos estratégicos claves de Microsoft, como lo demuestran algunas cifras que se aportaron durante el evento:

  • Más del 25 % de los ISV’s están desarrollando una oferta de soluciones en modalidad SaaS.
  • Más del 70 % de los ISV’s han recibido financiación por parte de Microsoft durante el año 2006 para ofrecer soluciones SaaS.

SaaS no es lo que ya teníamos con el modelo ASP porque:

  • ASP sigue un modelo de licencias frente a SaaS dónde se paga por uso.
  • ASP es un modelo pensado para ofrecer aplicaciones a unos pocos usuarios. Con SaaS, el servicio se ofrece a tantos usuarios como suscriptores.
  • ASP utiliza normalmente una infraestructura privada frente a SaaS que utiliza una infraestructura pública.

Para resumir, en un modelo SaaS:

  • El foco es el servicio frente a hablar de tecnología, aplicaciones, etc.
  • Los clientes pasan a ser virtuales.
  • Hablamos de plataformas de N clientes.
  • El cliente sale claramente beneficiado del modelo:
    • Menor coste e inversión inicial.
    • Menor riesgo.
    • Alta escalabilidad asegurada.
    • El cliente se centra en el negocio.
    • Aumenta la seguridad.
    • La respuesta ante los cambios es muy rápida.

 

En este artículo se agrupan las soluciones SaaS en 4 categorías (que dejan fuera soluciones de otro tipo):

  • Soluciones de Back Office, que incluyen aplicaciones ERP, de compra, de RRHH, etc.
  • Soluciones de mensajería, es decir, de gestión de correos electrónicos, tratamiento de SPAM, protección frente a virus, etc.
  • Aplicaciones CRM.
  • Soluciones de integración.
SaS_Post2 SaS_Post3 SaS_Post4

 

Hasta ahora hemos hablado del concepto de SaaS, las implicaciones asociadas al término, que supone para el desarrollador de software y para el cliente, así como algunos ejemplos de soluciones en modalidad SaaS. Pero, ¿qué implicaciones hay desde el punto de vista tecnológico? ¿qué consideraciones tecnológicas hay que tener en mente cuando pensamos en ofrecer soluciones SaaS?

  • Implicaciones tecnológicas para el fabricante de software:
    • Es necesario reescribir el código de las aplicaciones para que funcione correctamente en un entorno descentralizado, permite N-Usuarios y N-Empresas,…
    • Las aplicaciones tienen que incluir servicios que no existína tradicionalmente: monitorización, facturación, etc.
    • Gestión de la escalabilidad y los recuros en la medida en que la infraestructura de hosting puede ser compartida por distintas aplicaciones y un número indeterminado de usuarios.
    • Soporte 24×7, hay que asegurar a los clientes que las aplicaciones funcionan correctamente las 24 h y que no se producen anomalías en el servicio ofrecido.
    • Hay que elaborar un plan de puesta en marcha de mejoras continuas y nuevas versiones.
    • Seguridad en los datos y en las transacciones
  • ¿Cómo voy hacia SaaS?
    • Diseño de la solución:
      • Sea escalable.
      • Permita N-Usuarios.
      • Sea fiable y permita la iteracción de múltiples usuarios.
      • No afecte a otras soluciones.
      • Integre los nuevos servicios y funcionalidades necesarios en una solución SaaS.
    • Elegir la mejor arquitectura para el servicio a ofrecer:
      • Tecnologías a utilizar: Java vs .NET, versión de .NET Framework, tecnología para la GUI, ….
      • Número de capas adecuado.
      • Sistema Operativo de los servidores.
      • Integración con otras aplicaciones (del cliente).
    • Formación ténica adecuada.
    • Preparar planes de contingencia para el outsourcing de las soluciones.
  • Dudas tecnológicas:
    • ¿Sólo son posibles las aplicaciones web dentro de SaaS? La respuesta es que no, se pueden contemplar escenarios offline y clientes ricos que utilicen las funcionalidades de los servicios hosteados. Esto también aplica al desarrollo de aplicaciones en el entorno de Microsoft Office.
    • ¿Me olvido de los dispositivos móviles? Para nada, en las soluciones que implementemos tendremos que contemplar una versión móvil del servicio.
    • Una solución SaaS, ¿está aislada o se puede integrar con otras aplicaciones / soluciones? La respuesta es que no es una solución aislada, sino que tiene que incluir los puntos de extensibilidad necesarios para que se pueda integrar con otros entornos.
  • Implicaciones en la arquitectura de la solución:
    • Requisitos fundamentales:
      • Escalable de manera natural, es necesario definir un plan de escalabilidad en nuestra aplicación para estar preparados ante un número de clientes crecientes y que se aseguren los tiempos de respuesta adecuados: mecanismos de caching, compartición de recursos, entrada / salida asíncrona, etc. Hay que tener en mente que en SaaS no vamos a tener una previsión de clientes / usuarios.
      • Configurable, se trata de que el usuario de manera intuitiva tenga una cierta experiencia de configuración: llegue a lo que para el es su modelo de aplicación.
      • Eficiencia, la solución funcione manera eficiente.
    • Seguridad, pues en el modelo SaaS vamos a tener datos de diferentes clientes.
    • Arquitectura SOA, se trata de concebir soluciones no aisladas, es decir, que puedan interoperar con otras aplicaciones o servicios: Windows Communication Foundation.
    • Permita personalizar y configurar la aplicación a medida de distintos clientes, pero utilizando la misma solución. Idealmente se trataría de compartir infraestructura (servidor IIS, servidor de BD’s) y utilizar metadatos para habilitar la personalización y configuración que exige una solución multicliente y multimarca.
    • Sea escalable a distintos niveles:
      • A nivel de aplicación.
      • A nivel de estructura de datos: esquemas de replicación, mantenimientos de referencias al cambiar estructuras de datos, etc.
      • Pruebas de Stress de la solución…es fundamental en un modelo SaaS hacer este tipo de pruebas teniendo en cuenta el modelo de aplicaciones hosteadas en el que se basa.
      • Capacity planning: tener previstos un plan de incremento de capacidad para prever situaciones incremento de carga.
    • Configurabilidad a distintos niveles (y que el usuario puede tocar):
      • Esquema de datos, hay que elegir entre las opciones de: tener una BD aislada, compartir la BD pero no las estructuras de datos, o bien compartir todo.
      • Procesos (workflows) y reglas de negocio…un ejemplo tipo es el workflow de aporbación que tenemos en WSS 3.0 & MOSS.

Post_SaS_5

      • Interfaz de usuario: se adapte a las caracteristicas del usuario. Para cliente web tendríamos las siguientes posibilidades tecnológicas para habilitar este nivel de configuración.
        • ASP.NET:Master Pages, Themes, Web Parts.
        • Silverlight (XAML).
    • Seguridad:
      • ¿Qué posibilidades de autenticación tenemos?
        • Centralizada (ASP.NET membership, STS: WCF).
        • Descentralizada (ADFS y SSO).
      • ¿Qué mecanismo de autorización defino…?

Un ejemplo de arquitectura alto nivel que englobe estas y otros consideraciones es la siguiente:

SaS_Post5

  • ¿Cómo vamos a hacer la monitorización de la aplicación?
    • Lo primero es instrumentar que queremos monitorizar: eventos,contadoresderendimiento.
    • Luego hay que elegir las herramientas de administración: Powershell, MMC.
    • Creando un modelo de salud.
    • Establecimiento de métricas y facturación.
  • Y muchas cosas más….

Bajo el  concepto de SaaS hay muchas implicaciones funcionales y técnicas que hay que tener en mente a la hora de pensar en construir una aplicación en esta modalidad.  Hay muchas más implicaciones que comprender y entender sobre Saas.  Finalmente, comentar que desde Microsoft se está creando un ejemplo de aplicación SaaS: LitwareHR (se ha creado también la correspondiente sección en Codeplex).

 

¿De verdad saas es cloud computing?

Parece más o menos aceptado que saas es una parte del cloud computing. Hay numerosas referencias a lo largo de la web que defienden es postura e incluso este blog en la FAQ sobre cloud computing puedes ver al software como servicio como  parte del cloud computing . Pero ¿de verdad saas es cloud computing?

Recordemos que el factor diferencial del cloud computing es aquel que permite acceder al recurso/s hardware o software de manera casi inmediata y deshacerte de ellos de la misma forma. Es precisamente esta característica la que lo diferencia del hosting tradicional y de los ASP.

Muy por encima, técnicamente para llegar a conseguir ese factor diferencial, el cloud computing se apoya en el multitenancy como arquitectura de hardware y software para asignar el recurso y en el concepto de escalabilidad para poder atender a la demanda creciente o decreciente del cliente. Y todo esto con rapidez.

elasticidad

Desde el punto de vista del cliente que va a usar una saas¿es un recurso accesible de inmediato? Es decir, ¿saas es cloud computing? Sí. La mayoría de las saas tienen abierta la posibilidad de crear tu espacio para utilizar la aplicación online, ya sea con modelo freemium o con acceso gratis durante 30 días o de pago, y por tanto cumple con la definición de cloud computing: acceso rápido al software y posibilidad de incrementar o eliminar usuarios inmediatamente (escalabilidad) .

Ahora bien desde el punto de vista del proveedor, ¿Cuántas saas disponen de mecanismos para “asegurar” un acceso inmediato al software? ¿Cuentan con tecnología para ofrecerlo? Pues me temo que la mayoría no cuenta con ello. Cuentan con multitenancy pero no con tecnología que asegure la continuidad del servicio (escalado rápido, mantenimiento de los actuales usuarios, etc.) ante un avalancha de nuevos usuarios que desean utilizar la aplicación.

Y entonces, ¿las saas son o no son cloud computing? Siendo puristas para ser saas debieran o tener tecnología en sus sistemas para dar atender a la demanda o al menos apoyarse en un servicio paas o iaasque puedan darle cobertura ante este problema. Pero cuantas de ¿saas tienen este problema? Pues contadas con los dedos. La inmensa mayoría tiene un control del crecimiento (decrecimiento) de usuarios más o menos predecible y les da tiempo a dimensionar sus sistemas para cubrir este problema. Alguna hable de ello, si necesitas acceso rápido al recurso cloud computing es lo que necesitas, si no quizás te  es lo que necesitas, sino quizás te valga con un hosting tradicional, y esto es válido también para la saas.

Y ahora vuelve al principio del texto cambia la palabra saas por paas y poco más, y el razonamiento es igual de válido para las paas. Aunque una paas sin un mecanismos de escalado rápido es bastante más difícil encontrarla.

Y digo yo  ¿ a quién le importa esto? Pues a tontorrón como yo y a pocos más (con mi misma condición o no)

 

El factor diferencial del cloud computing

Esta semana me pedían opinión sobre un problema técnico que querían solucionarlo con cloud computing. No lo cuento porque no es muy interesante pero me di cuenta que no es la primera vez que ocurre que cuando me hacen referencia al cloud computing casi siempre se asocia a lo mismo: capacidad de computar en la nube.

Está claro que ésta es la traducción pero si lo pensamos esta capacidad de computo en la nube ya lo teníamos. Las empresas de hosting ofrecen máquinas a las que puedes acceder a través de internet desde hace la porra y los ASP ofrecen también la capacidad de utilizar una aplicación en la nube e incluso ofrecen servicios para que puedas desplegar aplicaciones y ellos te las mantienen. Es decir todas las partes del cloud computing tienen su antiguo competidor.

Entonces ¿que es lo que les diferencia? La elasticidad es precisamente el factor diferencial del cloud computing que además  lleva implícito la capacidad de escalar-reducir tu sistema y hacerlo en tiempo record.    No hace mucho Ricardo Galli nos regalo un post donde podíamos ver que esta es la verdadera potencia delcloud computing.

Repasando las partes del cloud computing y desde el punto de vista del cliente, donde más apreciamos esa facilidad y rapidez para escalar sistemas  y donde puede ser resultar más interesante es en la parte de Infraestructura como servicio (iaas).   Este gráfico lo he tomado de un documento de Amazon Web Services sobre todo que debería saber un arquitecto de cloud computing. En él se ve claramente esa elasticidad que permite adaptarse con rapidez a los cambios de la demanda frente a las tradicionales formas de escalar (vertical y horizontalmente) donde incurres en costes de oportunidad cuando sobredimensionas los sistemas  e incluso puedes llegar a perder clientes.

Las plataformas como servicio (pass) también ofrecen esa elasticidad y dinamismo a sus clientes para que puedan dejar tus aplicaciones en cualquier momento y asignar los recursos dinámicamente en función de las necesidades de sus aplicaciones.  Por ejemplo,  Heroku que es una paas para desplegar aplicaciones desarrolladas en Ruby, te permite asignar  dinámicamente Dynos que son unidades de procesamiento para tu aplicación.

Y donde menos claro se ve, o mejor, donde menos interés puede tener estar característica para el cliente es en la parte saas o software como servicio porque para él la elasticidad de una saas, en general, está en la facilidad que tiene para que un usuario pueda acceder a una nueva aplicación e implícitamente hacer uso de computación y el almacenamiento. De acuerdo que es más rápido y dinámico acceder a la aplicación pero quizás no es la más diferencial con respecto a la oferta más tradicional del ASP.

Desde el punto de vista del proveedor de paas y saas, parece claro y así lo hacen muchos, que si sus sistemas son muy dependientes de la demanda lo normal es que las paas hagan uso de la iaas y las saas de las paas o de las iaas.

En resumen, si te planteas cloud computing pregúntate para qué porque puede que te baste con un hosting o un ASP. Si necesitas rapidez de acceso al recurso, cloud computing es lo que necesitas.

¿Cuantas acepciones válidas hay para el cloud computing?

Resulta cuando menos curioso que a pesar de que la prensa, radio, TV, blogs, e Internet en general hablan de lo que es cloud computing, la nube y demás acrónimos que lo rodean, es difícil encontrar una definición de cloud computing que deje contento a todo el mundo. Este mismo blog es su FAQ y en la página ¿Qué es cloud computing?, define de una manera demasiado técnica el concepto que estoy seguro deja descontenta al alguna de la personas que lo visita:

“Cloud computing es facilidad de acceso, rapidez de entrega y escalabilidad inmediata de recursos hardware o software a través de Internet. Se paga por uso, no por licencia.”

Sin embargo, si preguntas por ahí, sobretodo a personas no técnicas e incluso a técnicos de IT que no necesitan cloud computing, lo que más me encuentro es esta definición: software y hardware que está en la nube. Y ya está. La facilidad, rapidez y escalabilidad está implícita, y en concreto no le hables del concepto escalable porque no sabe ni lo que es, ni tiene porque saberlo. Y por supuesto sin entrar en la discusión de que entiende por nube

¿Y es válida esta acepción? Pues sí porque aunque quizás sea incompleta, en esa declaración:“software y hardware que está en la nube” van implícitas muchas características del cloud computing que el hosting y el ASP carecían: fácil, rápido, sin limitaciones de recursos, pago por uso, sin instalación, etc. Es más muchos de estos usuarios, normalmente consumidores de software, no sabían de ASP y solo saben de la existencia delsoftware online y/o saas o el cloud computing.

Y entonces ¿quién valora la características del cloud computing? Pues todos a su manera. Ya sea el usuario de a pie o el perfil técnico. Y esto es algo que debemos tener presente a la hora de comunicar, esto es,  que existen principalmente 2 tipos de usuarios consumidores de cloud computing:

  •  Usuarios consumidores de Iaas y Paas.- Es un perfil técnico más cercano al hardware que sabe perfectamente la esencia del cloud computing y que ve claramente su utilidad porque sufren en el mantenimiento de sus sistemas la falta de rapidez a la hora de escalar sus sistemas.
  • Usuarios consumidores de saas .- Los tecno-conceptos (escalabilidad, multi-cliente, virtualización, etc) que rodean al cloud computing les da absolutamente igual, ellos quiere un software online, esto es, que esté en la nube (con todas las ventajas y desventajas que esto supone), sin limitaciones técnicas y que pague poco por ello. Me gustaría saber cuánta gente se pregunta si tiene algún límite de almacenamiento Gmail y esto es precisamente porque cloud computing te da esa sensación de que el recurso nunca se acaba y el usuario asume que esto deber así.

En fin, esto es lo que hay. No obstante, a pesar de esta realidad yo no desisto en el intento de relajar la explicación los conceptos técnicos para entender mejor las características del cloud computing.

La nube, cloud computing e Internet

La computación en la nube o informática en la nube, del inglés “Cloud computing“, es un paradigma que permite ofrecer servicios de computación a través de Internet. La “nube” es una metáfora de Internet.

Es decir que la nube es Internet. Y cierto es que antiguamente era asi. Que me corrijan los mas viejos del lugar pero yo con mis casi 40 castañas doy fe de que cuando hablabas de la nube hablabas de internet. Antaño y no tan antaño en los diagramas o gráficos de infraestructura la redes publicas están representadas como una nube.

Pero sin embargo “la nube” es un término que se asocia al cloud computing. Por ejemplo: hablamos de la nube de Amazon, la nube Azure, la nube de Google, etc. Que como ya sabemos son servicios cloud.

Vinton Cerf, el padre del internet, lo tiene tambien claro. Translator mediante, Vinton habla de comunicación entre la diferentes nubes en internet en el libro de Enrique Dans. Es decir, que hablamos de la nube como un lugar en Internet donde se puede acceder a ciertos recursos hardware y software.

Con esto  podriamos concluir que antes era Internet y ahora ha evolucionado al cloud computing. Pero como decíamos en la web te encuentras de todo: desde que ves claramente que se refiere al cloud computing, pasando por que intuyes que la nube es cloud computing hasta que la nube es Internet. Por ejemplo: un titular de ABC “Google quiere subirse a la nube” ¿a que nube?

Quizás es que soy demasiado tiquismiquis con el uso del lenguaje pero hablar de la nube de Amazon y Windows Azure, de que las diferentes nubes en Internet tiene que estar interconectadas y hablar de que Google quiere subirse a la nube, a mi me genera confusión.

Y es que mira que somos complicados. Traducimos cloud computing como “la nube” cuando la traducción es “computacion en nube”. Y es que como dicen por aquí, mola más decir “la nube”.Los angloparlantes lo tienen más fácil porque cuando quieren referirse al cloud computing siempre utilizan “cloud computing”. Nada de cloud.

y  los juegos online, se puede considerar nube o no? En teoria si, porque un juego online es un aplicación para jugar y por tanto es una nube.
y una agencia de viajes online? está en la nube? Es una nube? Aquí quizás tengamos la aclaración.
y un buscador? Es una aplicación que te busca cosas por internet, con lo cual es software como servicio, con lo cual es cloud computing, con la cual es una nube…..ah no, que no almacena datos entonces ¿es saas?. Jodeeee……….

No he aclarado nada, verdad? Pues en esas estamos. Cierto es que hay cierta tendencia a asociar “la nube” alcloud computing, aunque en un mismo texto puedes encontrarte contradiciones. Y yo que soy un veleta me quedo con que “la nube” es cloud computing hasta que se diga lo contrario pero sinceramente yo al cloud computing lo llamaría “cloud computing” o “computación en nube”. Por ultimo su definición made in Saasmania es esta que  podrás encontrar en la FAQ:

Es una plataforma altamente escalable que promete un acceso rápido al recurso hardware o software y donde el usuario no necesita ser experto para su manejo y acceso.

 

¿Qué es cloud computing?

Es una plataforma altamente escalable que promete un acceso rápido al recurso hardware o software y donde el usuario no necesita ser experto para su manejo y acceso.

Una nube es pública si el propietario de la nube es un proveedor que la mantiene por tí  donde pagas por el uso y disfrute del recurso a través de internet, y puede ser privada si la nube la mantienes tu dentro de tus instalaciones. Habitualmente se asocia el término cloud computing a la nube pública y es así como se utilizará en esta faq.

Las nubes suelen apoyarse en  tecnologías como la virtualización,  técnicas de programación como elmultitenancy y/o habilidades para la escalabilidad, balanceo de carga y rendimiento óptimo,  para conseguir ofrecer el recurso de una manera rápida y sencilla. Además  en el caso de las nubes públicas estas técnicas  generan economías de escala derivadas del aprovechamiento eficiente de los recursos hardware y humanos  que terminan repercutiendo en el precio que paga el cliente.

Por último, el  cloud computing lo podemos dividir en tres niveles en función de los servicios que actualmente están ofreciendo las empresas. Desde el más interno hasta el más externo nos encontramos: infraestructura como servicio, plataforma como servicio, y softwares como servicio.

¿Importa el multitenancy?

Muchas empresas se empeñan confundir “adrede” saas conASP, 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 como 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 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.

Actualiza, actualiza, actualiza…..

Una de la ventajas más interesantes de cloud computing, aquella que te permite consumir el recurso hardware o software a través de Internet, lleva consigo otra ventaja interesante: disfrutar de la última versión del software y del hardware más  puntero.

Es cierto que no de es obligado cumplimiento, pero si eres proveedor de iaas (infraestructura como servicio) y quieres ser competitivo lo normal es que dispongas del hardware de última generación para que tus clientes dispongan de el. Y por la parte software del cloud computing, si eres  proveedor de paas saas y vas liberando versiones de software que aportan nuevas funcionalidades o provocadas por arreglos de bugs del sofware ¿Por qué no darle al cliente la última versión del software que está consumiendo?

No creo que haya proveedor de saas y paas que no utilice esta gran ventaja competitiva con respecto al mundo tradicional. Ya quisiéramos disponer en el mundo offline de está ventaja que nos quitaría mas de un quebradero de cabeza a la hora de actualizar el ERP de turno o el software de BBDD  o del servidor de aplicaciones.

Google lo tiene claro y nos sorprende de poco en poco con funcionalidades nuevas en las aplicaciones online que utilizamos . Y otro que lo tiene claro es Zoho, que a pesar de que tiene unas cuentas aplicaciones on-line no para de actualizarlas y ponerlas a disposición de sus clientes.

zoho-in-2009

Así que si eres proveedor de cloud no pares de actualizar porque tus clientes te lo agradecerán y en futuro ,cuando casi todo esté en la nube, te lo reclamarán,

La ventaja escondida del cloud computing

Según el informe del ONTSI que fue hecho público el pasado lunes, la ventaja menos atractiva para la adopción del cloud computing es la prueba. Es decir, el poder probar el servicio cloud que vas a comprar a coste cero no es de lo que más se valora a la hora de adoptar cloud. Es normal. Poder probar no es un driver decisorio para la adopción, de hecho, lo debería ser es el resultado de la prueba, sin embargo, la posibilidad de probar es una enorme ventaja que te ofrece el cloud computing frente a la opciones in-house.

Larga es ya la experiencia en entornos in-house como usuario/cliente de aplicaciones de terceros y es altamente burocrático el proceso para decidir la adquisición de una aplicación y un auténtico riesgo la decisión en sí sin antes poder probarla. No todos los proveedores te ofrecen a montarte un piloto para su prueba y si lo hacen cada vez es más normal que el piloto tenga un coste para el cliente.

Frente a esto, el 99% de los servicios cloud computing te permiten probar el recurso, te permite hacerlo a coste y normalmente por plazo de un mes (ampliable en casi todos). Y ya no hablo de los servicios freemium que hay unos cuantos y no hay límite de tiempo (aunque si de funcionalidades) para utilizar la aplicación.

Esta es la ventaja escondida del cloud computing , de la que nadie habla, que además lo es desde el punto de vista del cliente y desde el punto de vista del proveedor:

  •  Para el cliente probar casi de manera de inmediata y a coste cero es realmente ventajoso otra cosa es que se valore y es que cuando te decides por un software normalmente ya tienes claro que lo quieres en cloud o en in-house y que por tanto no ha lugar la comparación.
  • Y desde el punto de vista del proveedor, la ventaja se coloca frente a sus competedores in-house, porque si una empresa no le importa adquirir un servicio cloud o in-house, será mas fácil que acerca a un servicio cloud por no tener barreras de entrada que a un software in-house, y esto pone claramente en ventaja a proveedor del servicio cloud.

Lo dicho, no es driver decisiorio pero si una clara y gran ventaja del cloud computing.

¿No te funciona la saas? No te preocupes que te lo arreglo enseguida…

Como sabemos el saas tiene muchas ventajas y otras tantas desventajas. Incluso se ven desde el punto de vista del cliente y del proveedor y aunque hemos hablado infinitas veces de ello, a veces se producen casos reales que te confirman la utilidad del modelo.

El post lo provoca una situación real que tuvimos alrededor de 2 semanas con la saas que acabamos de terminar , que en breve empezaremos a promocionar, y que ya hay gente probando que encuentra incidencias. :)

Resultó que metimos un cambio en producción. Cambio tonto que siguió el protocolo de pruebas que hemos establecido. El cambio, como a veces ocurre, tenía una situación especial no contemplada que producida un error y que encontró uno de los usuarios. La solución era tremendamente sencilla y pudimos cambiar la aplicación rápidamente. No siempre ocurre así pero en este caso fue realmente fácil.

Hasta aquí y desde el punto de vista proveedor, no hay ninguna diferencia entre una aplicación saas, unaaplicación ASP y una instalación in-house. Un usuario detecta  un fallo lo corriges y ya está. El tiempo de corrección aunque en este caso si fue determinante, en la mayoría de los casos no lo es porque necesita un análisis, corrección y pruebas, que suelen llevar más tiempo.

¿Donde está la diferencia? La gran diferencia está en el despliegue de la corrección. Para cualquier aplicación saas, el desplegué de la corrección no es traumática para nadie, ni para el proveedor ni para el cliente, y mucho más rápida que en los otros 2 casos porque el proveedor solo tiene una instancia  que da servicio a muchos clientes. Además el cliente solo tiene que conectarse de nuevo para acceder a la aplicación corregida.

Sin embargo, tanto para un ASP como para una instalación in-house la cosas no son tan sencillas. Un ASP tiene que actualizar todas las instancias de todos sus clientes, algo nada trivial. Ya he contado que algún ASP que conozco tarda en actualizar todos sus clientes mas de 1 mes. Y en una instalación in-house, el cliente tiene que actualizar el software en sus instalaciones con las restricciones típicas de que quizás tiene que actualizarlo el departamento de sistemas, en determinados momentos del día, que pueda fallar la reinstalación…etc. En ninguno de estos, conseguimos la rapidez de despliegue del saas.

En este caso en concreto que nos pasó, si unes esta gran ventaja del despliegue no-traumático a  la rapidez de la corrección, entiendes porque el usuario quedó absolutamente asombrado y encantado.

CORTESIA DE:

SAASMANIA “Todo lo relacionado con Saas, Paas, Iaas, Cloud Computing….”

http://www.saasmania.com

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s