e-Valúame

Category Archives: Opinión

Haz Saas, no SoSaas

Por inercia y hambre de negocio, uno de las preguntas más comunes que aparecen cuando la palabra saas o software como servicio empieza a tenerse en cuenta en las empresas de desarrollo de producto es: «¿y por que no colocamos nuestro software en la nube?«. Es normal, ya tienes un software incluso puede que funcione via web, ¿Por qué no?. Pues a esto precisamente es lo que le han puesto el nombre de SoSaas en inglés «Same Old Software, as a service» y en español, «El mismo software viejo, puesto como servicio».

En la última conferencia Saas organizada por IDC a la que tuve la ocasión de asistir, lo explicó perfectamente el Director Técnico de A3Software. A3Software tuvo claro que Saas y SoSaas no es lo mismo, abrió una línea de negoció nueva donde las operaciones (marketing, ventas, desarrollo, soporte, mantenimiento, roadmap del producto) y la cultura estuvieran completamente separada de la línea de producto tradicional, y desarrollaron un software para entregarlo como servicio aprovechando parte de su viejo software pero sin hacer SoSaas.  Además aprovecharón su presentación para sibilinamente «saludar» a los de SAGE, que tambien andaban por allí, porque al parecer SAGE vende «Citrix + Su aplicación» como si fuera Saas.

Este error tan común y comprensible, ha sido centro de debate de algunos bloggers y gente relacionada del sector como Abe Sultan (que estuvo por aqúí para hacerme una demo sobre SaasGrid)  que en su post «Como fallar miserablemente como Compañía Saas» explica algunos de los errores más comunes relacionados con el SoSaas o con empresas tradicionales que se aventuran con el saas. De este y otros, he extraído algunos de los errores que a continuación detallo  :

1.- No cuidar tus ventas de licencias de software tradicional

Ya consigas un aplicación saas tal y como la venden el equipo de A3 o si estas haciendo SoSaas, como tengas el más mínimo éxito puedes tener problemas con la ventas de licencias de software tradicional que fueron las que te llevaron hasta aquí y a priori tu vaca. Es decir, puedes llegar a canabalizar tu producto vaca. Ten cuidado con el público objetivo del saas, con la funcionalidad de la saas frente a la funcionalidad de tu software tradicional y los precios.

2.- Ignorar tus operaciones

Ya hemos hablado de ello. Añadir que los indicadores clave que medían cada una de las partes de tu empresa (operativas o staff) tampoco te servirán para medir como lo estás haciendo con tu saas. Deben ser más dinámicos y deben tener muy en cuenta las necesidades nuevas del usuario final (que no cliente), los ingresos mensuales, las bajas, los cobros, etc. Dicen que en el saas si sientes el dolor, quizás sea demasiado tarde.

3.- Ignorar la arquitectura, servicios, entornos y fiabilidad

No solo eres un desarrollador de producto, no solo instalas, no solo das soporte, ahora también mantienes la infraestructura y la aplicación.  Es decir, ahora ofreces un servicio y debes tener mucho cuidado con la infraestructura hardware y software para dar soporte a miles de usuarios. Asimismo, una decisión errónea en la elección de la arquitectura de tu aplicación, productos o hardware puede acabar con tu nueva aventura antes de tiempo.

4.- Ignorar el usuario final

El saas te permite mantener contacto directo y diario con el usuario final, desaprovecharlo es perder una de las ventajas competitivas que el saas te da frente al software tradicional. Si además tu competencia saas si le tiene en cuenta y explota esa información, no te cuento lo que te queda.

5.- Aplicar RoadMap tradicional

Históricamente, el roadmap de software tradicional propone versiones cada un tiempo bastante notable (6 meses, 1 año, etc) y normalmente incluye gran cantidad de cambios.  Esto atiende a una razón principal: un cliente no actualiza su software con menos periodicidad porque supone un coste de instalación y mantenimiento poco asumible. Pero el saas te permite que esto que tu roadmap sea más corto porque eres tú el que mantiene la infraestructura. Desaprovechar la oportunidad de darle al cliente sus peticiones y de arreglar los bugs en el menor tiempo posible, es perder otras de las ventajas competitivas del saas.

6.- Confundir Multitenancy con ASP

Este es otro de los errores  que apuntaba al principio del post cuando hacíamos referencia a SAGE.  Saas es multitenancy, es decir, misma aplicación y misma versión para todos los usuarios de tu sistema, y esto te lleva a obtener economías de escala que harán ofrecer la aplicación aun precio competitivo.  Intentar mantener distintas versiones o distintas ejecuciones por cada cliente o por cada conjunto de clientes te puede ir bien al principio mientras no tengas competencia, pero en cuanto la tengas no podrás competir con el precio del saas.  Y solo conseguirás sobrevivir si este servicio personalizado ofrecido a un precio mayor aporta  un verdadero valor para tus clientes.

7.- Versión Free para testear el mercado

Esta me ha gustado, y ocurre tanto si haces Saas como SoSaas.  El fremium es algo tan extendido en Internet que la tendencia natural es pensar: «ponemos una parte free y enseguida enganchamos al cliente con la parte premium«. Y esto está bien para determinadas aplicaciones, quizás aquellas muy tecnológicas que necesiten de buzz,  y sobretodo para aquellos (pocos) que pueden costear la parte free con publicidad , pero para el resto el free es un problema porque cuesta dinero, ya sea por recursos hardware, software como humanos.  La solución: versión de prueba de 30 o 60 días que seguro es mas que  suficiente para probar tu solución.

8.- Construir un producto completo para la primera versión

Muy relacionado con aplicar el RoadMap tradicional. Esperar a tener un producto completo tiene varios problemas: tiempo al mercado largo, retorno de la inversión más  largo, gran posibilidad de desarrollar funcionalidades que no son demandadas, etc. Si unes esto a que el en el software tradicional el usuario no quiere actualizaciones constantes, es lógico que se caiga en tener un producto más completo y terminado. Las condiciones de entrega del saas te permiten no tener que terminar tu producto para ponerlo en el  mercado. Puedes sacarlo con una funcionalidad mínima aceptable y poco a poco actualizar la aplicación tomando como base las peticiones de tus clientes.

Si juntamos estos errores con estos otros 10 errores más comunes de una startup de saas, ya tenemos una buena colección para no meter la pata. ¿La meteremos? Seguro.

Cuando google estornuda….

…el cloud computing se resfría. Y es que esta semana Gmail ha vuelto a tener problemas provocando que un porcentaje mínimo de usuarios no pudieran acceder a los contactos durante unas horas.  Por supuesto, se ha generado el correspondiente revuelo y  más aún cuando el Martes de esta misma semana ya hubo otro problema con Google News.  Siempre que Google estornuda es noticia, y sea por su reconocimiento mundial, por el ruido generado dada la gran cantidad de usuarios a los que afecta, o sea por lo que sea, el caso es que aparecen post para regalar criticando sus actuaciones y de paso la la viabilidad y confianza en el cloud computing. Como este de pcworld que recuerda los problemas de servicios Google en el último año :

·         September 24, 2009: Gmail outage

·         September 22, 2009: Google News outage

·         September 1, 2009: Gmail outage

·         May 14, 2009: Google network outage

·         May 18, 2009: Google News outage

·         March 9, 2009: Gmail outage

·         August 7, 2008: Gmail and Google Apps outage

Posiblemente esta noticia  hubiera entrado en el saasmanario de esta semana pero me ha llamado la atención la aparición de bastantes posts en defensa del cloud computing y ofreciendo un punto de vista menos apocalíptico sobre su uso. Incluso ha habido posts con un toque de ida de pinza,  como este de Phil Wainewright cuyo título viene a decir que : «por que deberiamos estar contentos por la caidas de Gmail» y donde  argumenta que por cada caida de Gmail, Google aprende más y más y llegará un momento que consiga el Nirvana de la excelencia operativa y nunca más los usuarios de Gmail suframos perdidas de servicio. Claro a cualquiera que le cuentes esto, este o no ligado a los sistemas de informacion, se revuelca por el suelo nada más leerlo.

No es la primera que hablo de esto pero conviene recordarlo de vez en cuando. Quizás Google la esté cagando y por tanto tendría que revisar sus procedimientos o mejor que las empresas que la auditan ajusten sus procedimientos para que las caídas no se vuelvan a producir, pero esto no va a pasar nunca. Los sistemas seguirán teniendo problemas porque están expuestos a gran cantidad de riesgos como el fallo hardware, software, amenazas externas, y a uno de los mayores y casi imposible  de eliminar:  el ser humano. Estos son los que mantienen el sistema y como tales, tarde o temprano meterán la pata ya sea en alguna actuación o en el diseño del plan de recuperación de desastres.

Esto quiere decir, que los sistemas que hacen posible la oferta de cloud computing, no están exentos de estos riesgos y por tanto asumamos cuanto antes que esto seguirá ocurriendo tanto en la modalidad outsourcing como en la in-house. Por tanto, la pregunta que nos queda responder es:

¿soy capaz de gestionar el sistema mejor que Google?

10 situaciones por las que tu jefe no apostaría por saas

Como todo en la vida, el saas propone razones para que las empresas lo adopten y tambien razones por las que no tiene sentido su utilización. Este post es una réplica del anterior, con las situaciones o razones por las que tu jefe nunca optaría por saas:

saas-dilbert

  1. Si no te fías de que los datos (tus datos), que manipularás a través de la aplicación saas, los mantenga un tercero.
  2. Si el software lo necesitas 24×7 y tu negocio no tolera el calendario de paradas programadas del proveedor de la saas debido a mantenimiento del sistema y aplicación (nuevas versiones, correccíon de bugs, etc)
  3. Si no crees que un proveedor de infraestructura y aplicaciones pueda mantenerlo mejor que tu mismo.
  4. Si necesitas integrar la aplicación o los datos de la aplicación con otros sistemas o aplicaciones y esto resulta costoso y complicado.
  5. Si coincide una situación de capacidad sobrante tanto en recursos humanos como infraestructura con la necesidad de la aplicación.
  6. Si el proveedor de la solución saas utiliza un lenguaje de programación que no es open source, o no tienes otra forma de ejecutar la aplicación que no sea a través del navegador. Recordemos el caso de CogHead que dejo a miles de usuarios colgados.
  7. Si no confias en tu proveedor de internet y no quieres tener otra línea de backup con otro proveedor.
  8. Si el software que tu quieres va a diferenciarte con el resto de tu gremio. Aunque ni siquiera encontrarás una solución saas que te ofrezca esto porque por definición el saas es para muchos y esto no te diferenciará.
  9. Si consideras que una ruptura del servicio del proveedor de la aplicación debe tener una penalización y el proveedor no te ofrece un SLA acorde con este tipo de situaciones.
  10. Si no hay cultura de Internet en tu empresa y no encuentras una saas con un «look» que no rompa con el «look» de la aplicaciones in-house.

¿Alguna más?

11 + 1 situaciones por las que tu jefe apostaría por saas

El otro día hablando sobre saas con un amigo no muy tecnólogo, me propuso que escribiera un post explicitando las situaciones en las que sería interesante adoptar saas  y me puso un ejemplo: «es que si le digo a mi jefe que podemos utilizar la herramienta y si no nos sirve el coste será mínimo, seguro que acepta». Siendo crítico me dijo que en realidad muchas de ellas se extraen con facilidad de las ventajas o beneficios del saas , pero quizás otras no estén tan claras.  Asi que, éste es el post abierto a otras situaciones que no he sabido recoger.

Vamos a recordar primero lo que significa Saas o Software as a service o Software como servicio y sus beneficios:

El saas es aquella aplicación “consumida” a través de Internet, casi siempre a través del navegador , cuyo pago esta condicionado al uso de la misma y donde la lógica de la aplicación como los datos residen en la plataforma del proveedor. En el pago esta incluido el uso de  la infraestructura necesaria para el correcto funcionamiento de la aplicación y el mantenimiento  de la infraestructura y aplicación.

bensaas

Quizás caigas en la alguna de las situaciones siguientes y te baste para adoptar el saas en tu empresa, pero lo normal es que sea un subconjunto de estas el que te ayude a convencer a tu jefe a decidirse por el software como servicio (saas):

  1. Si el precio es un factor decisorio principal en la adquisicion  o «alquiler» del software.
  2. Si necesitas implantar un software y hay riesgo de no adopción en tu empresa (temas culturales, peleas internas, etc) o no estás seguro que el software solucione tu problema.
  3. Si no dispones de fondos para comprar la infraestructura necesaria para soportar el software.
  4. Si aun teniendo fondos para la infraestructura o utilizando infraestructura as a service, no dispones de dinero para implantar/instalar el software en tus instalaciones (consultoría).
  5. Si aun teniendo fondos para la infraestructura y la implatación/instalación, no dispones de personal para el mantenimiento de la infraestructura y el software (mejoras y bugs).
  6. Si te gustaría acceder de manera inmediata desde cualquier punto geográfico al software sin preinstalaciones.
  7. Si necesitas flexibilidad y rapidez (escalable) a la hora de añadir o quitar usuarios que usen la aplicación.
  8. Si crees que el uso múltiple de la saas hace mejor a la saas (más mejoras propuestas por los usuario y más errores encontrados/corregidos).
  9. Si quieres disponer de manera inmediata de cualquier adaptación propuesta por otros usuarios y los arreglos del software por bugs.
  10. Si confias en que un proveedor de saas utiliza la mejores y más avanzadas técnicas de backup, alta disponibilidad, fiabilidad, seguridad, porque es parte de el servicio que ofrece y de esto depende su negocio.
  11. Si te gusta la idea de pagar mensualmente por uso (horas CPU, megas consumidos,etc) o por el potencial uso (pago por usuario).

…..y la 11+1:  Si la crisis te afecta o te condiciona de alguna manera te hará caer en alguna de la primeras situaciones que tiene relación con el precio, costes y gastos de la aplicación . Es claro que el saas es generoso con la conyuntura económica que nos aprieta.

Minube y Velneo: Testimonios de uso de cloud hosting

Hace un par de meses cuando se produjo el lanzamiento de hostarting y al revisar los diferentes tipos de hosting que mantienen en la web, pensé  que (como la cabrá tira para el monte) les faltaba una sección de cloud hosting. Además me hizo preguntarme que no había visto nada escrito sobre las diferentes opciones que hay en el mercado para externalizar tu infraestructura: housing, hosting, servidor dedicado, servidor virtual y cloud hosting, y sobretodo un post que explicara las diferencias entre el cloud hosting y el resto de opciones. Y me puse  a buscar.

Al poco de buscar me di cuenta que ya había gente que había escrito sobre ello solo que yo no había llegado. Casi todas  las casas de hosting tienen un documento que explica claramente la diferencias entre las diferentes opciones. Por ejemplo arsys explica en este  documento las características de cada opción y a quien va dirigido.  Y además me topé con este post de wences que  encontré a través de Error500, y que me parece realmente bueno y esclarecedor de lo que ofrece el cloud hosting en comparación con el resto de opciones.

Durante la investigación se me ocurrió que podía interesante recoger opiniones de empresas que estaban usando el cloud hosting y aunque en aquel momento pensé que el post (después de lo que ya había en la red) carecía de sentido, me he dado cuenta que siguen siendo interesantes las respuestas que me dieron Fillito de minube.com y Jose Maria de Velneo a la pregunta: ¿porque elegísteis cloud hosting?, y que a continuación os dejo:

Cuando empezamos a desarrollar minube y nos enfrentamos al diseño de la comunidad, la parte de red social, nos dimos cuenta de que si queríamos ofrecer publicación de contenidos multimedia a nuestros usuarios, nos enfrentabamos a dos grandes problemas : Almacenamiento y Capacidad de Procesamiento (para generar muchos tamaños de cada foto, y recompresión de video en tiempo real)

Realmente no hicimos comparativas entre otros productos, ya que cuando descubrimos AWS, sus características cubrían tan bién nuestras necesidades y los precios eran tan ridículos , que apostamos directamente por Amazon.

Los factores determinantes sin duda fueron:
– el excelente precio,
– escalado transparente de almacenamiento en S3. Nos olvidamos completamente del tamaño de nuestros discos duros, simplemente metemos y metemos datos. Amazon se encarga de gestionar el almacenamiento físico, replicación de datos por seguridad, y asume el coste en recursos que supone distribuir todos esos datos a muchos usuarios.
– fácil escalado de las instancias de procesado, pero sobre todo inmediato. si usásemos VPS para procesar nuestros videos, no podríamos escalar nuestras máquinas bajo demanda. Con EC2 tardamos menos de 20 segundos en tener disponible una nueva máquina, y en cuanto dejemos de necesitarla, la apagamos y pagámos sólamente por lo que hemos usado.

Todo ésto sumado a los nuevos servicios que ha sacado Amazon de autoescalado, … para nosotros no hay duda 😛

Estoy seguro que si no fuera por un servicio así de bueno con precios tan asequibles, startups como nosotros con un presupuesto muy limitado, no podríamos crear aplicaciones tan complejas.

**********************

Nosotros necesitabamos un sistema de hosting flexible. Como startup que somos, necesitamos poder subir o bajar el número de vServers disponibles para nuestros clientes en función a la demanda que tengamos. Además necesitamos un gran ancho de banda garantizado y un sistema de copias de seguridad muy fiable.

Estudiamos tres opciones: encargarnos nosotros de todo (hardware, comunicaciones, etc), utilizar un sistema de hosting tradicional o utilizar el cloud computing. Analizamos las opciones desde el punto de vista de los objetivos requeridos y desde el punto de vista económico.

Rápidamente nos inclinamos por el cloud computing, aunque no era muy bueno en España, y comenzamos a buscar proveedores. Analizamos Amazon, FlexiScale y alguna otra. Estudiamos todas las características técnicas, ubicaciones físicas (la latencia influye muchisimo en las velocidades de conexión), precios, etc.

Finalmente nos decidimos por Amazon. Nos proporciona una facilidad y una autonomía extraordinaria. Desde que comenzamos a trabajar con ellos no han parado de evolucionar: máquinas virtuales en Europa, Discos persistentes, sistema de monitorización, etc. Llevamos más de un año trabajando con ellos y todo ha funcionado correctamente.

El pago por uso es genial. Yo puedo crear una máquina en un momento dado a partir de una que ya tengo configurada, hacer las pruebas que necesite y apagarla cuando termine. En total me sale menos de un 1€. Y todo en tiempo record.

En nuestro caso, también es fundamental poder tener una máquina funcionando en tiempo record, configurada con nuestras aplicaciones. Eso Amazon nos lo permite perfectamente.

Es más, el otro día vinieron a vernos un proveedor de hosting que dispone de máquinas virtuales. Era muy interesante para nosotros, porque cuentan con CPD’s en todos los continentes. Cuando les pregunté cuánto tiempo tardaría en tener otra máquina funcionando, me dijeron que varios días… Ese tiempo es inviable para nosotros.

*********************

Si después del post de wences quedó alguna duda de la utilidad del cloud hosting y en qué situaciones es realmente ventajoso, bajo mi punto de vista, estos dos testimonios las despejan. Para cerrar me gustaría destacar la parte del testimonio de Fillito donde habla sobre el disco duro que define claramente dos de las características del cloud computing: sensación de que el recurso (disco)  no se acaba nunca y su disposición inmediata.

¿Puede ser privado el cloud computing?

Respondo ya:  NO lo es.  Al menos no lo es tal y como entendemos  el cloud computing en cualquiera de sus tres partes. Cierto es que detrás del cloud computing existe un proveedor que ofrece un servicio cloud y que se encarga de una serie de trabajos e inversiones que lo hacen atractivo. Pero no es menos cierto que el término nube privada ha aparecido y existen,  y sino que se lo digan a los de SAP que compraron la nube de Coghead para el desarrollo y despliegue de aplicaciones internas. Por tanto,  vamos a intentar dar un poco de luz  a lo que son las nubes privadas, el cloud computing y explicar el porqué de la confusión.

¿ que es una nube privada?

Una nube privada 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 .  La plataforma se encuentra dentro de las instalaciones del usuario de la misma y no ofrece servicios a terceros. Por norma general, cuando utilizamos la expresión «nube privada»  nos referirnos a una plataforma para la obtención de  hardware puro y duro, es decir, máquinas, almacenamiento e infraestructura de red (equivalente a la parte iaas del cloud computing) , pero tambien podemos tener un nube privada que nos permita desplegar aplicaciones (parte paas del cloud computing) e incluso una nube privada de aplicaciones (parte saas del cloud computing).

Si ahora echamos un vistazo a las «antiguas» ventajas del cloud computing e intentamos colgarselas a las nubes privadas evidentemente esto no cuadra por la sencilla razón de que la mayoría de ellas, aquellas que se refieren a la parte económica, hacen referencia a un proveedor del servicio cloud.

Nube privada Cloud Computing
Inversión Inicial Si No, pago por uso (incluye manto.)
Gastos de mantenimiento Si No
Riesgo por adopción de nueva tecnología Alto Bajo
La carga operacional recae sobre Sistema de Información (SI)
instalado
Proveedor del hardware y software
Alta Disponibilidad del recurso Depende de SI instalado El proveedor de Cloud ofrece un SLA
Retorno de la Inversión Lento debido a la inversion
inicial
Rápido y más predecible
Seguridad de los datos(Backup, Accesibilidad,etc) A cargo del SI Corre a cargo del proveedor

Y sin embargo si echamos un vistazo a las «antiguas»  desventajas del cloud computing, son precisamente estas las que justifican las nube privadas y que a su vez se convierten en las ventajas de montarte una nube privada.

Nube privada Cloud Computing
Localización de los datos In-house En casa del proveedor y a veces sin conocer su ubicación exacta
Precepcion de inseguridad de los datos No Si, datos y lógica fuera de tus instalaciones
Dificultad para integrar con otros sistemas propietarios Baja Alta
Puntos de fallo El propio sistema El proveedor cloud y el proveedor de comunicaciones
Paradas por mantenimiento El propietario decide El proveedor de Cloud impone los momentos de manto.

Entonces, ¿donde está el problema? Pues en definir  el cloud computing como si fuera una nube pública y fuera necesario la participación de un tercero, cuando en realidad es una nube, es decir,  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. Sin más.  Quizás el verdadero problema es que el  término está en pañales y no hay una definición clara, ni hay un institución no lucrativa para normalizar o standarizar el término, y lo utiliza todo el mundo como bien le viene.

No aburro más. Para cerrar el tema, solo decir que  me desdigo,  que el cloud computing puede ser público si el propietario de la nube es un proveedor que la mantiene por tí y pagas por el uso y disfrute del recurso, y puede ser privado si la nube las mantienes tu dentro de tus instalaciones.

Larga vida a las paas

Hace un par de semanas, Diego Mariño cofundador y CEO de Abiquo fue entrevistado en debug_mode=on. La entrevista, aunque es un poco larga,  merece la pena escucharla porque Diego es uno de los  pocos emprendedores españoles dentro del mercado cloud español y sabe de lo que habla. Además en la entrevista habla un poco sobre la oferta de Abiquo, su plan de internacionalización y por donde empezarán a expandirse y del cloud computing en general.

Una de la cosas que más me llamó la atención de la entrevista fue una declaración sobre las paas, a las que las augura un futuro negro debido a que su oferta deja al cliente cautivo , dependiente y al antojo de las mismas.  Para justificar su declaración puso el ejemplo de CogHead y su espantada hace ya algo más de 3 meses.

Bajo mi punto de vista, hay soluciones para no caer en un posible  lock-in de tu proveedor de paas.  Resumiendo lo que decía en este post , los criterios para elegir una paas pasan por:

  • La opción de Zoho  CreatorZoho ofrece la posibilidad de migrar las aplicaciones que se desarrollan en su plataforma a la plataforma Google App Engine y en el caso de que ocurra lo que a CogHead, siempre puedes llevarte el código a Google App Engine e incluso como el lenguaje utilizado por App Engine es Python (lenguaje bajo la licencia de codigo abierto) sería posible descargártelo a local y ejecutarlo en tu infraestructura si lo que deseas es huir de la paas(platform as a service) (ver los comentarios). El único “pero” de esta solución es que cuando Zoho ofreció  esta solución, había limitaciones sobre ciertos componentes y siempre te quedará la duda del grado de compatibilidad entre el lenguaje Zoho y Python.
  • Paas que ejecute código abierto como Java, Python, Ruby.- De hecho son muchas las paas que utilizan este tipos de lenguajes, se puede consultar en el  directorio cloud computing. Son todo ventajas porque puedes optar por ejecutarlo en la paas o en tu infraestructura y la compatibilidad será casí absoluta. Quizás su desventaja ante plataformas como Zoho sea la dificultad para desarrollar aplicaciones y por tanto el alto grado de conocimientos del desarrollador.
  • Paas que ejecute código propietario con opción de ejecución en tu infraestructura.- Hay algunas paas como BungeeConnect Velneo que ofrecen la posibilidad de utilizar su paas o tienes la posibilidad de utilizar el ejecutor de aplicaciones en tu infraestructura.

Sin pensar en que las paas lleguen a desaparecer,  si veo que las paas son la parte del cloud computing que más complicado tiene la «justa» justificación de su servicio. Me explico.

El servicio de las paas pasa por dejar tu aplicación en la plataforma y olvidarte del mantenimiento de la infraestructura esto es, te olvidas de escalabilidad, disponibilidad, mantenimiento de disco, mantenimiento del servidor de aplicaciones, BBDD, etc. Todo esto suponiendo que tu infraestructura la tienes contratada en la nube ( p.e. en Amazon), sino es así tambien te olvidarías de la inversión de hardware. Es decir que tu única preocupación es el correcto funcionamiento de la misma desde un punto vista funcional. Por tanto es evidente que es un servicio atractivo y que seguro que hay mercado pero ¿cuanto vale este servicio? ¿a partir de que momento merece la pena contratarlo?

Para poder responder a estas preguntas deberíamos saber lo que nos costaría mantener una infraestructura de este tipo y lo dividimos en varias rúbricas:

Coste de infraestructura.- Tienes opciones de todo tipo: servidores in-house, servidores dedicados externos, servidores virtuales, cloud hosting. Medible en cualquier caso.
Coste de licencias.- La parte del gasto correspondiente a las licencias (p.e.: servidor de aplicaciones o BBDD) es claro: tanto cuesta tanto pagas. Medible.
Coste personal.- La parte correspondiente a la cantidad de tiempo que dedica tu personal para mantenerla aunque es más jodida de calcular pero también es medible.

Ahora bien hay un conjunto de intangibles que tienen un efecto directo sobre el coste del personal pero que son difíciles de medir: la experiencia, conocimientos o competencias, rendimiento, destreza o talento, etc. de tu personal afectan en mayor o menor medida en su coste y pueden determinar la elección de una opción paas o in-house.  Y ahora las preguntas son: ¿El coste de personal es óptimo o podría ser más bajo con personal más cualificado? A pesar de tus gastos, ¿tienes un servicio de calidad?

A partir de aqui tienes argumentos o situaciones para defender ambas opciones. Es claro que una empresa paas cuya razón de ser o visión es la de ofrecer la máxima excelencia en estos servicios, uno de sus objetivos debe ser contar en su filas personal que maximizen aquellos intangible y por tanto puede tirarte más la opción de la paas, pero tambien es cierto que el cliente objetivo de las paas es personal técnico que puede contar con personal con pericia suficiente para mantener la infraestructura.

Creo que es imposible responder a las preguntas sobre si «paas si» o «paas no» sin ponerle números a todo esto y fijar una aplicación concreta, pero lo que está claro que de entrada genera una serie de incertidumbres que en las otras partes del cloud computing (iaas y saas) no es tán fácil encontrarlas y también tengo claro que no morirán por lock-in, ni porque no ofrezcan un servicio interesante.

Google Wave: open source, saas, web 2.0…¿algo más?

googlewave

Para entender lo que significa Google Wave vamos a intentar comparar lo que solemos hacer en el mundo offline en nuestras relaciones sociales y lo que Google Wave nos ofrece para hacer lo mismo en el mundo online. Todo esto se puede ver el video presentación de Google Wave, pero tiene un problema: que son 1h y 20m y encima en inglés.

Mundo Real: En el mundo real nuestra relación con los demás se basa en el establecimiento de la conversaciones . Por ejemplo:  Lunes por la mañana.Durante el fin de semana, algo sorpredente: Barsa 2- R.Madrid 0 ;). Estas tomando un cafe con uno de tus compañeros de trabajo e inicias una conversación.  «Lastima diarrea les diera a todos, es imposible con estos tipos. Son un panda de negaos».

Mundo Online: Esto es en el mundo online lo solucionamos a través de un email, chat online, twitter, etc. todo ellos con distintos niveles de interacción con aquel o aquellos con los que estableces la conversación. El inicio de una conversación en Google Wave lo llaman «wave» (ola en inglés) y es completamente interactivo. Así mientras que tu compañero está escribiendo (hablando en el mundo offline) tu estás viendo cada caracter que escribe, es decir, la wave o texto o documento está compartido con actualizaciones online immediatas. Fácil no?.  Ejem…

Mundo Real: Establecida la conversación, resulta que durante tú exposición,  el compañero de trabajo te  corta y decide añadir un comentario a una de tus frases. «Tío, asúmelo. Iniesta, es un crack».

Mundo Online: Aqui en el mundo online, ya empezamos a tenerlo un poco más complicado. Porque como mucho podemos escribir mientras el otro escribe pero ninguno de los dos se enterá hasta que pulsa «Enter» , «Update», etc. con lo que muchas veces se produce una serie de mensajes que no siguen un orden, confusos y a veces frustrantes.  Con Google Wave mientras que tu colega está escribiendo tu puedes añadir/modificar/borrar  cada palabra o frase y ambos son conscientes de que el otro está escribiendo en el mismo documento/mail o en definitiva texto compartido (wave)

Mundo Real: Resulta que, empiezas a no estar de acuerdo con lo que tu colega y decides encontrar  apoyos vikingos en el resto de compañeros de trabajo e invitas a Juan a la conversación.  Le haces un pequeño resumen y esperas a que Juan te apoye.

Mundo Online: Esto no parece muy complicado. En el mundo del correo online, le incluyes en el Para o CC de receptores y el otro se entera, en twitter puedes revisar los twits, y podriamos seguir la conversación, pero en cualquiera de los casos se hace tedioso seguir el orden de la conversación y quienes han intervenido. En Google Wave, por supuesto que puedes incorporar a gente a la conversación, pero además dispones de un reproductor del orden en como se ha producido la conversación. Si tenemos en cuenta que podemos corregir el texto de la wave,  movernos a nuestro antojo e incorporar a nuevos tertulianos,  puede convertirse aún más complicado seguir una wave. Bien pues para esto disponen de un reproductor de la conversación señalando visualmente quien intervino y su exposición.

Con este ejemplo podemos ver más o menos lo que te permite Google Wave y su principal y más importante característica. Compartir y modificar información online completamente interactiva con los usuarios que tú decidas.

Google wave es un nuevo modelo para comunicación y colaboración online en la web.

Si a esto le añades un interface típico Web 2.0, donde parece  que no estés frente a un navegador sino ante una aplicación en tu PC, hace la solución aun más  llamativa  y atractiva (al menos asi se se aprecia en el video).

Google Wave tambien proporciona una API que te permitirá crear:

  • Robots que interactuan automáticamente con la wave que escribes, como por ejemplo traducir online el texto del remitente. En el video aparece un ejemplo de como seguir una wave en twitter a partir de un determina busqueda en twitter, con actualizaciones inmediatas.
  • Gadgets que utilizan toda la potencia de compartición online de información. Disponen ejemplos como sudoku y ajedrez donde puedes jugar online con otros miembros de la wave y ver los movimientos online.

¿Y todo esto que tienes que ver con el cloud computing, el saas o el paas? Pues que no deja de ser otra aplicación en la plataforma  de Google en la nube donde han dado un vuelta de tuerca más al set de aplicaciones Google Apps. Recordemos que Google Apps ya permite la compartición online de documentos con registro de modificaciones aunque no llega a tener la interactividad a nivel de tecla pulsada como Google Wave.  Han aprovechado su experiencia en Google Apps, su experiencia en Gmail y  en general su experiencia en la nube para crear esta herramienta que a mi particularmente me parece una pasada.

Por ultimo, decir que además Google Wave es open source y con esto pretenden crear un federación de servidor waves con  aquellos que quieran convertirse en proveedores. Se ha desarrollado un protocolo para la consecución de esta federación de servidores y está abierto a contribuciones con el objetivo de mejorar la forma en la que se comparte las waves. Veremos con funciona pero la idea y la herramienta molan.

googlewavefederativo

Saas vs las reflexiones del Grupo Intercom

Ayer estuve en el Iniciador de Madrid disfrutando de la charla que nos dió Antonio Gonzalez Barros, fundador del Grupo Intercom. Esta es la segunda a la que asisto de Antonio Gonzalez y aunque ambas merecieron mucho la pena, la de ayer me gustó más porque fue más cercana y además en vez de comenzar la exposición con una presentación como suele hacer todo el mundo, y pasar al turno de preguntas, decidió que le preguntáramos primero y despues exponía. Toma ya. Sobrao, «ya me conoceis asi que preguntadme».  En resumen, hubo más de tú a tú de lo que suele haber , algo que al menos yo agradecí, y en Loogic tienes más datos sobre la exposición de Antonio.

Según Intercom y en base a la experiencia obtenida en proyectos como Softonic o Infojobs, un proyecto éxitoso en Internet debe cumplir las siguientes 9 características ya sea en su totalidad o en un porcentaje alto. Me ha parecido interesante contrastarlas con lo que sería un aplicación construida bajo el modelo saas sea cual fuera  la  funcionalidad que ofrezca, para saber de su viabilidad en el mundo Internet. El resultado ha sido que en general cualquier proyecto saas cumpliría alrededor del 90% de las características que exponen en el grupo.  Esto es lo que me ha salido:

GRUPO INTERCOM SAAS
1- Autoalimentación   
Tu negocio será autoalimentable si puede lograr adquirir más valor cada vez que sea utilizado por un usuario. Es decir, si dispones de una «plantilla virtual» que te dedicará muchas horas de trabajo que aportarán valor a tu negocio, sin costarte nada a cambio Una de los factores claves de éxito de un saas es obtener feedback de los usuarios. Esas mejoras y arreglos propuestas son repercutidos al resto de usuarios y esto lo hace cada más estable y rico en funcionalidad. Por tanto con ayuda del usuario pero un proyecto saas puede ser autoalimentable
2- Motivación  
¿Es muy alta la motivación que tienen los usuarios por conseguir lo que les ofreces? Posiblemente si van a poder obtener algo similar en muchos otros sitios, ello no será posible. A mayor motivación, más estarán dispuestos a pagar por el servicio. Y más esfuerzos realizarán, por ejemplo, llegarán a cumplimentar largos formularios de vital utilidad para ti. Si se trata de Saas vs Software tradicional, sin duda hay una alta motivación y las encuestas lo ratifican. Y aquí hay un amplio mercado por cubrir, sin apenas saturación, sin apenas competencia en mismas soluciones de software como servicio y esto se traduce en una clara oportunidad de negocio.   
3- Agradecimiento rentabilizable  
La importancia de la recomendación es enorme en Internet. Por eso es tan importante generar vinculación y agradecimiento, ya que se convierten en prescripción. Clientes satisfechos o, mejor aún, sorprendidos producirán un boca-oreja de impagable efecto multiplicador. Te habrán generado tráfico de una forma eficaz y continua. No descubro nada nuevo si digo que las ventajas del saas generan gran expectación. Lo ratifican las encuestas y muchas de la grandes (Google, Microsoft) estan apostando por ello. Además ese boca a boca se potencia cuando se trata de saas de nicho ya que los usuarios entienden los problemas de su colega del sector.
4- Sostenibilidad  
¿Disfrutarás de economías de escala, de red o de lealtad? Las economías de red son de probado valor en Internet y se logran cuando tu usuario recibe más valor cuantos más usuarios usen tu servicio. Si no existe ninguna de estas economías, en el futuro, y a pesar de tener consolidado tu proyecto, este puede estar a merced de nuevos competidores que dispongan de mayor capacidad empresarial o financiera, prestigio o experiencia en el sector. Una de las características más notables del saas es que se generan economías de escala (a través del multitenancy y la concentración de los recursos) por el aprovechamiento óptimo de los recursos y esto termina repercutiendo en el precio final del cliente. De hecho en general el precio del saas empieza siendo bajo en busca del volumen que haga sostenible el negocio.
5- Aplicación asesina  
¿Tu proyecto puede llegar a eliminar otros servicios homólogos del mundo «offline» con los que compite, al lograr alcanzar un determinado nivel de cuota de mercado? Existen servicios y conceptos en Internet que si logran absorber un cierto porcentaje de su mercado, lo hacen de modo que quienes siguen utilizando los servicios similares tradicionales están en franca desventaja… y no les queda más opción que pasar a usar los servicios online.  Si, sin duda. En general la mayoría de la aplicaciones realizar bajo el modelo saas podría llegar a eliminar instalaciones en el mundo offline. No en todos los mercados, no en todos los sectores, y en general no entorno críticos de producción pero son muchos los casos de empresas que tornan sus vistas hacia el saas dejando de lado el software tradicional. 
6- Innovación  
¿Crees que tu idea de negocio mejora notablemente algo existente en el «mundo físico»? o … ¡muchísimo mejor! ¿permite algún servicio, funcionalidad o personalización hasta hoy impensable? Relacionado con lo anterior. El saas, como el cloud computing en general, la idea de negocio es innovadora y ofrece un servicio a través de Internet que antes no se daba principalmente por impedimentos técnicos. 
7- Elimina rozamientos  
¿Tu negocio aprovecha a fondo lo que en el «mundo virtual» es mucho menos costoso (en tiempo o en dinero) que el «mundo físico»?  Quizás en este punto el saas cojea, al menos al principio. El modelo se basa en volumen de clientes y por tanto se necesita mucha pasta para aguantar hasta llegar al break-even. Pero a corto-medio empieza a ser un modelo menos costoso por el aprovechamiento de las economías de escala.
8- Genera know-how  
¿Te has planteado hasta qué punto tu negocio te generará conocimientos aprovechables en el futuro? Cuanto mayor sea el know-how generado, más contribuirá al desarrollo de tus futuros proyectos y creará barreras de entradas para tus competidores. Saas establece una relación muy estrecha entre el cliente y el proveedor que se traduce en conocimiento de las necesidades. Estas necesidades generales de funcionamiento, usabilidad,etc, podrían aprovecharse para abrir nuevos proyectos saas e incluso para abrir una Factoria Saas 😉
9- Personalización  
¿Aprovechas a fondo las posibilidades que Internet te brinda para SEGMENTAR? La capacidad de dar a cada usuario un servicio muy pensado y adecuado a él, es una de las grandes posibilidades que nos brinda Internet. Este punto es muy dependiente de la aplicación saas, y sobretodo si es horizontal o vertical. No obstante, otro de los factores clave de un aplicación saas es la posibilidad de personalización por usuario o cliente.

Linux: El sistema operativo para la nube

nubelinuxLinux Foundation, organización no lucrativa con el objetivo de promocionar,proteger y standarizar la plataforma  Linux, afirma a través de este paper,  que Linux es el mejor y el más adecuado sistema operativo tanto para los proveedores de servicios cloud (Amazon Ec2) como para  los consumidores de computación pura y dura en la nube .  Sus razones son: «Linux es modular, ofrece buen rendimiento, eficiente en el consumo energético, escalable, es código abierto y ubicuo».

El paper da una pequeña descripción de lo qué es el cloud computing. Además explican que el cloud computing no es nada nuevo pero  las mejoras en la tecnología, y en particular en la virtualización, la computación distribuida, y la administración de las TI, han hecho que se impulsará la adopción. Yo añadiría algo más importante, y son las mejoras en las comunicaciones y en concreto el acceso, velocidad y fiabilidad de Internet.

Amanda, autora del documento, repasa tambien las caracteristicas más destacadas del Linux que lo hacen más apetecible para el cloud computing. A saber:

Arquitectura.- El kernel de Linux es abierto y configurable para correr en cualquier plataforma o hardware, algo que ciertamente le viene bien al cloud computing.

Compatibilidad.- Hay cantidad de proyectos open source que utilizan Linux como sistema operativo y el uso de este en la nube, habilita la posibilidad de que estos proyectos terminen desplegados en la nube.

Coste Licencia.- No tienes costes de licencia. Importante para el proveedor y el usuario  de cloud computing en su parte Iaas.

Coste energético. El uso de Linux contribuye a la reducción del consumo energético de la plataforma.

Mantenimiento y Desarrollo.- Dado que las competencias del personal desarrollador para Linux y de administración  son parecidas, los clientes que quieran desplegar en la nube puedan aprovechar los conocimientos de su personal desarrollador para la administrar el  Linux de la nube.

Standards.- La standarización del Linux permite que puedas desplegar en otros Linux (??¿)  en incluso elegir entre desplegarlo en local o en remoto. Con matices acerca de la compatibilidad.

Virtualización.- La virtualización es la técnologia que el nivel de infraestructura del cloud computing utiliza para el mejor aprovechamiento del hardware. Los usuarios de Unix cuentan con gran cantidad de herramientas para llevar a cabo la virtualización.

Poco más que decir. Todos los proveedores cloud del nivel de infraestructura ofrecen máquinas para instalar appliance con Linux como sistema operativo porque es cierto que su ubicuidad, standarización y la ausencia de costes por licencia lo hacen atractivo para su uso en la nube. Veremos como le sienta este anuncio a Stallman. 😉

La gracia del saas

Una de las preguntas más comunes que aparecen cuando hablamos del saas es si este software puede hacerse a medida o no. No son pocos los que me han preguntado sobre esto y entiendo la confusión porque toda la vida hubo la posibilidad de hacer software a medida, porque estamos hablando de software y porque el saas tiene unas ventajas que son realmente atractivas como para planteartelo. Entonces, ¿puedes pedirle a un proveedor de saas tu particular necesidad de software bajo el modelo saas? Pues no y si. Me explico.

bensaas

No. Si el software que tú quieres es: o muy exclusivo para ti o tú negocio, o puede diferenciarte en el mercado frente a tus competidores. En definitiva, lo que necesitas es «software a medida«.

Si. Si es un software que te sirve a ti pero es muy posible que le sirva a tu gremio, entonces este sería un proyecto susceptible de que caiga sobre el modelo saas. Es “software a medida” para ti porque no hay nada en el mercado que cubra lo que tu quieres o simplemente no lo hay, pero puede que otros tengan el mismo problema y puedan beneficiarse de la solución. De hecho muchos de los productos en el modelo tradicional de software nacen de esta forma.

Hemos hablado muchas veces de que el saas por definición es un modelo de uno a muchos, donde el mismo software, la misma versión y la misma ejecución de la aplicación sirve a muchos clientes. Por tanto, la gracia del saas está en el volumen de clientes.  Apoyándonos en la fórmula, la conclusión es sencilla:

Beneficio = Precio suscripción * Volumen – (Costes Fijos + (Coste Variable * Volumen))

  • Costes: los costes son los que son, es decir, tienes personal desarrollador, comercial (si comerciales, porque el software as a service aunque sea un software que se consume a través de Intenet no quiere decir que no necesites comerciales en la calle ) y personal para staff. Siendo austero no bajas tus costes fijos de los 100.000€ anuales.
  • Precio suscripción: Los precios del saas, haciendo una medida , oscilan entre 30€/mes/usuario y 100€/mes/usuario.

con esos costes y esos precios, o tienes volumen o no hay forma de que llegues al punto de equilibrio y menos que pueda resultar rentable. De hecho, partiendo de la base de que el proveedor comparte la infraestructura para cumplir con el modelo de uno a muchos, cuanto más clientes mayor optimización de sus recursos y mayor ajuste en los precios.

Y ahora una «cuñita» bloguera. Si crees que tu software cae del lado del «si»  ponte en contacto con la Factoria Saas y estudiaremos si existe la posibilidad de desarrollarlo bajo el modelo saas. Hay otras opciones para beneficiarse de algunas de las ventajas del saas sin llegar a tener volumen pero nosotros queremos hacer saas porque creemos que hay beneficios reales tanto para el gremio como para nosotros.

Oracle Cloud

oraclecomesunA estas alturas todo el mundo sabe lo que Oracle se ha gastado en hacerse con Sun. 5.600 millones de dólares en pasta y el resto, hasta 7.600 millones, en deuda. Me comenta un amigo que Oracle pone a todos sus productos su marca por delante (en realidad espera 4 o 5 años en llevarlo a cabo pero termina haciéndolo) , pero ¿lo hará con MySql?: «Oracle MySql«. No me digan que no tendría guasa el nombre, un nombre para un producto con dos marcas de BBDD, una con la mayor cuota de mercado del mundo y otra con una cuota baja pero ya quisieramos muchos pillarla con ese volumen de mercado.

set-oracleOracle ha publicado un comunicado explicando el porqué de la compra y las sinergias que van a encontrar. Esencialmente Sun ha tenido un historia focalizada en productos hardware y Oracle en software, parece claro que no se pisan mucho (excepto por MySql) y pueden encajar e incluso beneficiarse dando una solución integral que vaya desde el almacenamiento y servidores, pasando por la BBDD, hasta el software, tal y como explican en el comunicado .

En su FAQ dicen que mantendrán su división de hardware, negocio que Oracle desconoce por completo pero si miramos la cuenta de resultados de Sun del 2008 , y aunque el año pasado la venta de servidores disminuyó respecto al anterior, es perfectamente entendible que quieran continuar con esa división porque les reporta más de 8.000 millones de ingresos. Respecto a la división Sun Cloud no han dicho nada específico, en parte porque ni siquiera era línea de ingresos para Sun, pero la previsión que había es que  que a partir de este verano ofrecerán servicios cloud para competir con los servicios de Amazon.

Y entonces, ¿continuará Oracle con la division “Sun Cloud”, o mejor con “Oracle Cloud”?

Recordemos que hasta ahora Oracle ha flirteado con el cloud computing desde la parte saas con su CRM Oracle OnDemand y con Oracle Sourcing, dos software de libro para poder llevarlos a la nube y donde los riesgos de fracaso en este punto de evolución del mercado son casi nulos. Además llegaron a un acuerdo con Amazon para hacer instalaciones en máquinas EC2 de Amazon con Oracle BBDD, donde de igual forma el riesgo aquí es nulo, ya que si la gente lo instala cobra sino no cobra pero tampoco hay inversión. Realmente si parece que a Larry esto del cloud computing no le atrae demasiado porque a pesar de que tiene productos para poder dar cloud computing no ha apostado fuertemente por la nube. No digo que sea fácil ofrecer una paas como Windows Azure pero más fácil será si ya tienes los productos necesarios que componen un paas, es decir, un servidor de aplicaciones (tiene BEA WebLogic y Oracle Aplication Server) y una BBDD (Oracle y ahora tiene MySQL), y además tienes pasta para montarlo.

Pero ahora que acaba de adquirir «Sun Cloud» y el mercado con una previsiones de crecimiento bastante alentadoras, no creo que quiera deshacerse de la división y dejar de subirse al carro. Larry cambiará su discurso sobre el cloud computing y continuará con la división, e incluso completará la oferta de servidores en la nube ofreciendo su propio software para su consumo con la modalidad de pago pay-as-you-go, tal y como ahora es posible hacerlo con la máquinas EC2 de Amazon y la BBDD Oracle. Y quizás si les va bien se atrevan a dar servicios paas o servicios de BBDD as a service. Veremos que terminan haciendo.

Amazon EC2 Reserved en Europa

Hace poco más de un mes, Amazon puso en marcha un nuevo servicio que permite reservar máquinas EC2 que hasta el momento estaba restringido para EEUU. Pues ya es posible reservarlas en Europa. Parece que el éxito en aquel continente de esta modalidad de uso ha sido notable y esperan obtener el mismo éxito para Europa. El precio es ligeramente más alto que EEUU, hecho que se repite en la modalidad de pago por uso de las instancias EC2, y consiste en un pago fijo por un o tres años a cuenta de la reserva de máquina, pago que no es reembolsable si la máquina no se utiliza, y uno variable en función del consumo que hagas de la máquina. Aquí os dejo la tabla:

amazon-pricing

Con estas dos modalidades de pago que te ofrece Amazon, es decir pago por consumo y pago por suscripción ( reserved), la jugada te puede salir realmente económica si tienes claro el consumo que vas a tener. La fórmulas son sencillas:

Amazon Reserved = CosteFijo + CosteVariable1 * horas
Amazon papo por consumo= CosteVariable2* horas

Si igualamos ambas fórmulas y despejamos las horas, conseguimos el número de horas a partir del cual comienza a ser interesante Amazon Reserved frente a Amazon pago por consumo. Por ejemplo: Para una maquina small default reservada por un año y tomando el coste de 0,11 por hora en la modalidad pago por consumo, tendriamos lo siguiente:

 325 + (0,04*h) = 0,11*h 

el número de horas (h) que nos sale es 4.642 (aprox. 193 días), es decir que si prevemos que vamos a tener la máquina funcionando durante más de 4.642 horas, saldría rentable coger la opción reserved. Si la tuvieramos funcionando durante todo un año 24*7, el ahorro sería de 288$.

 ejemplo-pricing

Pues lo dicho, a echar números y cuentas. 😉

LongJump vende su paas para instalar en in-house

longjumpLongJump es una de las empresas, que junto con la malograda Coghead, más tiempo lleva  en el mercado de las platform as a service y por tanto una de las pioneras. Su producto permite más o menos lo que permitía Coghead y pego lo que en el post sobre Coghead decía:

la creación de formularios online, el almacenamiento de los datos que introduces en esos formularios, además si se tiene la necesidad de programación dispone de un lenguaje propietario de 4ª Generación para abordar aplicaciones o lógica de negocio que no puedes salvar con un simple formulario. Hace bastante tiempo que la probé y para pequeñas aplicaciones era una herramienta que podría servirte aunque me gustó mas Zoho Creator. Sus competidores eran CaspioDabbleDBZoho Creator,LongJump, y alguna más que podemos encontrar en el directorio cloud computing.

El problema de este tipo de herramientas es el mismo que tenía Coghead y del resto que arriba menciono. Como se vaya al carajo al empresa y decidan no poner a tu disposición el código o la herramienta para su instalación in-house o en otra máquina de la nube, te quedas sin las aplicaciones que desarrollaste en la plataforma, posiblemente si los clientes que las utilizaban, y existe también  la posibilidad de que te vayas  al carajo.

Leo en el blog de Phil Wainewright que  LongJump ha decidido ofrecer su producto para su instalación in-house. De esta forma si se va al carajo al menos tienes la posibilidad de montarte un servidor en tus instalaciones o en la nube  e instalar LongJump para seguir ejecutando y modificando tus aplicaciones. Además tiene otra ventaja para los excépticos como Stallman, y es que tienes el control de tus aplicaciones, de tus datos y de las opciones generales y personalizables de la propia plataforma LongJump, tal y como explican en su post.

El precio? Pues no es público, si quieres enterarte debes llamar a este numero 800.886.9028 o rellenar este formulario.

En relación con mi ultimo post acerca de  los objetivos del open cloud manifesto y como me señalaba luis.tic616 en los comentarios, este movimiento  al menos no te deja cautivo y condicionado a las apetencias y desavenencias del proveedor paas que recordemos es uno de los principios del manifesto. Pero  incluso existiría la posibilidad de poder cambiar de proveedor de la paas LongJump si alguien montara un plataforma como servicio con Longjump y entonces conseguiríamos unos de los objetivos del manifesto 😉 . No sería los primeros partners que ofrezca servicios más baratos que la propietaria del producto.

En fin, la evolución del mercado, el uso de los servicios cloud, las nececidades de los clientes, etc. obligan a la aparición de fórmulas (recuerdese que Zoho permite desplegar sus aplicaciones en un competidor suyo, Google App Engine)   que posiblemente no estaban en los planes de  las empresas  pero esto es un mercado como cualquier otro y se trata de sobrevivir y no quedarse obsoleto.

¿Qué persigue el Open Cloud Manifesto?

Muchas son las  reacciones que el open cloud manifesto ha provocado en la blogosfera y excepto Amazon, Microsoft, Salesforce y unos pocos más,  casi todo el mundo opina que es un documento con buenas intenciones y que sobretodo beneficiará a los consumidores de servicios cloud.

opencloud

Las reacciones en español ( por ejemplo: Enrique Dans, La pastilla Roja, Alt1040) han centrado su atención principalmente en los principios en los que se asienta este documento y poco se ha hablado sobre los objetivos que persigue el open cloud manifesto y que más o menos vienen a decir lo siguiente :

Elección

Asi como una organización elige un proveedor , una arquitectura o utilizar un modelo, un «open cloud» hará más fácil utilizar un proveedor o arquitectura diferente.   Si la organización necesita cambiar de proveedor debido a las nuevas asociaciones, adquisiciones, las peticiones de los clientes o las regulaciones gubernamentales, pueden hacerlo fácilmente. Los recursos que habrían sido gastados en una difícil migración, pueden gastarse en innovación.

Flexibilidad

No importa qué proveedor  o arquitectura una organización use, una «open cloud»  hará más  sencillo trabajar con otros grupos, incluso si los otros grupos eligen otros proveedores o  arquitecturas. Una  «open cloud» les facilitará a las organizaciones interoperar entre los distintos proveedores de la nube.

Velocidad y Agilidad

Una de las propuestas de valor de la nube  es la capacidad para escalar el  hardware y/o software según sea necesario. El uso de interfaces abiertos permitirán a las organizaciones construir nuevas soluciones que integren nubes públicas, privadas y a sus actuales sistemas de TI. Asi como las condiciones de la organización cambian, una nube permitirá a la organización responder con agilidad y velocidad.

Habilidades

Un efecto colateral de una nube es la disponibilidad de profesionales cualificados. Si hay muchos modelos de programación propietarios, un profesional de IT es poco probable que abarque más que unos pocos de ellos. Con una «open cloud», habrá un pequeño conjunto de nuevas tecnologías para aprender (sobre todo cuando se utilizan las tecnologías existentes), mejorando las posibilidades de que la organización se puede encontrar a alguien con las habilidades necesarias.

Puestos a pedir,  los objetivos del manifiesto son aquellos que todo el mundo quisiera o ¿no nos gustaría poder cambiar de proveedor de ERP sin cambios traumáticos en nuestro sistema y organización? ¿y si tuviéramos la posibilidad de poder conectar las aplicaciones sin tener que hacer “arcos de iglesia” para llevarlo a cabo?  Y esto no solo en la nube también en los entornos in-house.  Todo esto esta muy bien pero realmente ¿son objetivos alcanzables?.  

Especialmente complicado veo el llevar a cabo el objetivo“Habilidades” donde se pretende limitar a un conjunto reducido de lenguajes de programación aquellos que utilicen los proveedores cloud. Me surgen estas preguntas:

  • ¿Se plantea utilizar solo los conocidos lenguajes de programación Java, Ruby, Phyton y .NET? 
  • ¿Propietarios o solo aquellos que sean libres?
  • ¿Se podrán utilizar nuevos lenguajes de programación en el futuro? ¿Cómo se incorporarán?

Me parece realmente restrictivo e incluso puede resultar poco atractivo para el consumidor de cloud computing que tiene que limitarse a lenguajes de programación que quizás no cubran todas sus necesidades. Si además radicalizamos, siendo la nube el futuro, con esta restricción no habría posibilidad de evolución en el modelaje de los lenguajes de programación ya que solo se solo se utilizan unos pocos lenguajes de programación y no habría profesionales cualificados con los nuevos. Y si la nube no es el futuro y es solo una opción más, entonces ¿qué dejamos? ¿ a los lenguajes de programación de “elite” para la nube y el resto que se desarrollen en el in-house? Casi que atenta contra la competencia e innovación de esta parte de la TI en la nube.

Algo más viable,  auque no fácil, veo la parte de cambiar de proveedor cloud. En lo que se refiere a la parte iaas , es decir, maquinas virtuales ( p.e EC2 de Amazon) y almacenamiento puro y duro, es relativamente sencillo cambiar de proveedor. La parte paas la veo menos fácil porque aún partiendo de la base de que hubiera varias paas ofertando los mismos servicios ( por ejemplo: java + mysql, phyton+SQLServer, etc), el hecho de que todas la paas tengan su BBDD  significa que si cambias de paas debe mover tu BBDD a otra paas y esto es algo que no es nada trivial.  La parte que veo más complicada es la parte saas del cloud computing porque si se trata de cambiar de proveedor de ERP + mover la BBDD se entiende que las dificultades serán las mismas que hasta ahora  hemos tenido en entornos in-house.

En cualquier caso, yo lo he ratificado, porque para mi lo verdaderamente destacable e interesante, es que al menos se traten todos estos temas  y que pueda servir para alertar de las consecuencias y peligros que, por ejemplo,  pueda tener la elección de una aplicación realizada en un lenguaje de programación (sea propietario o no)  que acaba de salir del horno (falta de profesionales, mayor numero de errores que otro lenguaje con solera, etc) o de las consecuencias de elegir un proveedor de cloud con un sistema cerrado, como por ejemplo ocurrió con Coghead que dejo a miles de usuarios finales colgados y cientos de aplicaciones sin posibilidad de ejecución en otros proveedores o entornos in-house.

Al documento le faltan cosas como la puesta en marcha de una ley de protección de datos internacional o mejor en el ámbito de internet que aunque sea un verdadero handicap se hace cada más necesaria, pero estoy seguro que algo se sacará de todo esto y tambien lo estoy de que, como comentaba al inicio del post, el consumidor cloud saldrá bien parado.