El problema de la volatilidad de servicios en la nube: cómo conseguir la independencia

Cloud ComputingEl cierre de Google Reader ha sacado a flote de nuevo los miedos por la incertidumbre que nos crea la discontinuidad de una herramienta o servicio que estamos habituados a usar. Adaptas tus costumbres, tanto personales como profesionales, a una forma de trabajar durante mucho tiempo y de repente desaparece la herramienta. Igualmente ocurre con cualquier servicio en la nube, tanto PaaS, como SaaS o IaaS.  ¿Cómo te defiendes ante esto?

La clave para tu defensa está en establecer como prioridad máxima, dentro de tus factores de decisión, la futura independencia del proveedor. Para ello tienes que evaluar los siguientes aspectos:

  • Exportación y/o backup de datos en formato estándar: que tu información se encuentre guardada o bien la puedas recuperar en un formato 100% portable entre diferentes sistemas es fundamental. Es la única forma de asegurarte de que podrás explotar tus datos usando cualquier servicio. El rey indiscutible como estándar en este terreno es XML aunque existen alternativas a tener en cuenta como JSON, YAML, etc. y otros formatos según el tipo de archivo y/o dato que estemos utilizando.
    Como ejemplo, para el caso de Google Reader es posible realizar una exportación a un fichero OPML con la herramienta Google Takeout, que exporta en formato XML y JSON.
    También como ejemplo, en el servicio SaaS Google Docs existe la posibilidad de exportar la información en formato de Microsoft Office y OpenOffice entre otros. De no existir esta posibilidad seríamos esclavos del servicio.
  • Inter-compatibilidad entre servicios: siempre, en la medida de lo posible, será fundamental que elijas un proveedor cuyo servicio (protocolos, APIs, lenguajes soportados…) sea compatible con las ofertas de la competencia. De esta forma podrás cambiar de proveedor y por ejemplo migrar tus aplicaciones en cualquier momento y sin dificultad. En este sentido es importante, desde el punto de vista de desarrollo de software, usar siempre en tus desarrollos tecnologías estándar:
    • Desarrolla en Java, tendrás más puertas abiertas y menos limitaciones. Es el lenguaje más soportado en la nube. Como ejemplo, si desarrollas en PHP (soportado en Amazon EC2) no podrás portar tu aplicación a Google App Engine.
    • Utiliza APIs estándar, e intenta evitar en la medida de lo posible APIs propietarias de la plataforma, o te encontrarás con un problema. Como ejemplo, no es recomendable usar como método de autenticación cuentas de Google y su correspondiente API si estás usando Google App Engine. Mucho mejor será basarse en estándares como OpenID y OAuth.
  • Trata de no colocar todos tus huevos en la misma cesta: tu ubicuidad siempre será una ventaja para ti. Si usas varios proveedores al mismo tiempo estarás más preparado ante discontinuidades del servicio y serás más ágil a la hora de moverte y migrar de un sitio a otro si tienes problemas con un proveedor.Huevos en distintas cestas
    • Como ejemplo, en mi caso, para almacenamiento en la nube uso DropBox, Google Drive y SkyDrive al mismo tiempo. Puedo repartir y/o clonar mis datos entre ellos consiguiendo evidentes ventajas ante la posible discontinuidad o incluso caída del servicio de cualquiera de estos proveedores.
    • En cuanto a desarrollo de aplicaciones, la mejor forma de conseguir esto es usar la filosofía SOA en todo lo que hagas. Podrás mover servicios de un lugar a otro en la nube y conseguirás gran independencia, flexibilidad y escalabilidad. Aún más notable será la escalabilidad y eficiencia si optamos por un modelo REST en lugar de SOAP, siempre que las necesidades lo permitan.

Si tienes en cuenta estos aspectos, gracias al cloud computing podrás llegar a tocar el cielo de la independencia pues conseguirás entre otras ventajas:

  • Independencia de equipos dedicados: los problemas de CPU, memoria RAM, discos, etc. pasarán a la historia. Estos recursos te los proveerá dinámicamente la nube, aportando gran flexibilidad y escalabilidad.
  • Independencia en la supervisión: ya no será necesario estar pendiente de que tus servicios y aplicaciones estén funcionando correctamente. Tu proveedor se encargará de esto.
  • Independencia económica: ya no es necesario hacer grandes esfuerzos en inversiones iniciales para equipos que no sabemos bien cómo dimensionar.

Como conclusión, si partimos de la premisa de que el futuro está en la nube, para que la nube tenga futuro debe basar su desarrollo en estándares adoptados por toda la industria. Es muy sencillo: simplemente debe aprender de errores del pasado, como los cometidos por Internet Explorer. Todo lo que se salga de ahí, tanto por parte de los proveedores como de los consumidores, será como ponerse palos en las ruedas.

Anuncios

4 pensamientos en “El problema de la volatilidad de servicios en la nube: cómo conseguir la independencia

  1. Buena reflexión, hay que tomar tu articulo muy en cuenta, pues al final una gran parte de nuestra vida digital, queda fuera de nuestro control, a merced de decisiones de terceros y lo cual puede plantear un problema bastante grave.
    Gracias por compartirlo.

  2. Gracias Pepe. Todo lo que sea estándar bajo mi punto de vista es una ventaja para el usuario y/o cliente: además de otorgar la libertad o independencia ya comentada, como consecuencia fomenta la competencia en el mercado en mayor igualdad de condiciones al facilitar los movimientos de usuarios entre distintos proveedores. Sin intención de entrar en polémicas, me baso en esto para pensar que Flex será inevitablemente desterrado por HTML5 y está equivocado todo aquel que opine lo contrario 😉

  3. David, antes que nada te dejo una gráfica actualizada de la tendencia, a nivel de ofertas de trabajo, de las tecnologías Flex y HTML5 que citas al final de tú último comentario: http://www.indeed.com/jobtrends?q=HTML5%2C+Flex&l=

    Como verás, la realidad y el “hype” generado por los medios difieren bastante y hacen que la batalla entre estas tecnologías no sea lo que muchos esperaban cuando comenzó.

    Es claro que HTML5 tiene una trayectoria imparable pero me parece que “desterrar”, para el caso de Flex, es una palabra muy dura todavía en estos momentos.

    Piensa que en este mundo la etiqueta de “tecnología muerta” la intentan aplicar aquellos que están descontentos con la misma, por la razón que sea, pero al final es el grueso de inversores, empresas y desarrolladores (los que estamos usando dichas tecnologías al fin y al cabo) son los que hacen que esto sea así o no. Flex es todavía hoy día la tecnología clave para aplicaciones RIA en el mundo empresarial y no parece que la cosa vaya a cambiar mientras HTML5/JS no consiga una evolución a nivel de herramientas y metodologías de desarrollo que le permita llegar donde tecnologías como Flex están hoy en día.

    Seguramente se llegará, dada la inversión que se está haciendo a nivel mundial, pero de momento, y aún en estos días, no estamos mucho más cerca de lo que estábamos hace 2-3 años cuando empezó esta batalla. Yo todavía sigo a la espera de esa evolución tecnológica y de esas herramientas que me permitan ser productivo en HTML5/JS, y que me permitan tener un framework que funcione sin fisuras, programar en OOP o evitar la fragmentación originada por los diferentes proveedores de navegadores….por poner solo algunos puntos clave todavía no resueltos en la “tecnología web del futuro”.

    En otro orden de cosas, enhorabuena con el artículo, pues me parece la mar de interesante.

    Carlos

  4. Carlos, gracias por tu comentario. No te falta razón, yo dije que Flex será desterrado por HTML5 y parece que has interpretado que dije que Flex ha sido desterrado. No es así, en estos momentos aún no. A Flex aún le queda cuerda, pero tal como están las cosas o Flex se reinventa o es cuestión de tiempo que se convierta en “legacy”, que es lo que está apenas empezando a suceder. ¿Qué sucederá si Adobe decide abandonar Flash, o si otras empresas en bloque se niegan a incorporarlo en sus productos como ya hizo Apple? Tampoco a Google parece que le guste mucho para Chrome, sino ¿por qué desarrollar PepperFlash?
    A mi personalmente lo que menos me gusta de Flex es esa dependencia de Flash, un producto propietario “caja negra” que te deja a merced de decisiones “estratégicas” de un proveedor.
    Ya para acabar, lo que más me escama de todo esto es la reciente marcha del CTO de Adobe a Apple sin que Adobe tenga la intención de sustituirle. En palabras de Adobe: “No vamos a sustituir la posición de CTO, la responsabilidad para el desarrollo de tecnología radica en nuestros dirigentes de la unidad de negocio bajo el liderazgo del CEO de Adobe, Shantanu Narayen”. Carlos, no me negarás que eso huele fatal.

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 )

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 )

Google+ photo

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

Conectando a %s