cloud computing, Iaas, infraestructura como servicio, infrastructure as a service, Opinión, Paas, plataform as a service, Plataforma como service, Saas, software as a service, Software como servicio

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

Entradas relacionadas: