¿Por qué NO voy a utilizar Google Keep?

No-keep-Google-Keep

Justo después de anunciar el cierre de Reader, la todopoderosa Google presenta una nueva herramienta en forma de SaaS: Google Keep. Yo lo tengo claro. Yo tengo claro que no voy a usarla, y también tengo claro que algo ha cambiado en Google. Señores: torres más grandes han caído.

¿Y qué es Google Keep? No es más que una muy muy simple aplicación para gestionar notas, algo así como la versión electrónica de los clásicos Post-it! Lo primero que llama la atención es esa simplicidad extrema: ¿cuestiones de Time To Market o es más bien seguir fieles al estilo y estética que tanto éxito ha dado a la compañía? Pues tras hacer unas primeras pruebas, me inclino más por pensar que se trata de la primera motivación. De hecho opino que el producto no está minimamente maduro, y tengo mis fundamentos:

  • Al crear mi primera nota veo que existe la posibilidad de incluir imágenes. Lo único que se puede hacer es subir imágenes desde tu equipo, no es posible incluir imágenes desde un enlace. Pero por si esto fuera poco, la subida de imágenes no me funciona y me muestra un error invitándome a intentarlo más tarde.

Error al subir imagen

  • No veo por ninguna parte ninguna forma de relacionarse con otras aplicaciones, no tiene ninguna faceta social, y ni mucho menos una forma de exportar la información. Para mi son muy importantes todos estos aspectos, en la línea de lo que comentaba en mi anterior post. Si usas Google Keep estás aislado completamente. Sólo esto ya es motivo más que suficiente como para no usar esta herramienta sin vacilar.
  • Teniendo en cuenta que la herramienta está totalmente aislada, ¿qué ocurriría si de repente Google decide que ya no es una herramienta estratégica o rentable para la compañía? Mejor no pensarlo.
  • Intento destacar un texto en negrita… ¡imposible! No me lo permite, no tengo la opción. Sólo puedo usar texto plano tal cual. Casi que para eso prefiero usar un editor de textos de toda la vida.

En definitiva son razones más que de sobra, y más que de peso, para fundamentar mi idea de no usar Google Keep de ninguna manera, pero es más, empiezo a plantearme dejar de usar muchos más servicios de la compañía. Debo admitir que hasta el momento he sido todo un fan de Google y fiel usuario pero a día de hoy me lo estoy planteando y mucho:

  • En su día dejé Firefox para usar Chrome y últimamente me está dando problemas preocupantes. Se han empeñado en incluir su reproductor PepperFlash que no hace más que dar problemas y no funciona correctamente. Y lo peor de todo, si lo deshabilitas en favor del reproductor Flash de Adobe (que sí funciona como debe ser) al poco tiempo se vuelve a habilitar él solito. La vuelta a Firefox parece ser el mejor movimiento.
  • Drive me pareció una buena opción en su día hasta que he empezado a usarlo más intensivamente. Bastante a menudo me salta con errores que sólo dejan como opción cerrar la aplicación. Desde luego que Drive no puede ser mi herramienta de almacenamiento cloud de uso prioritario.

En definitiva, Google ya no es diferente, o sí lo es pero en el mal sentido. Ya no es innovadora ni ágil como lo fue en el pasado. Ha perdido el espíritu que la hizo grande. Sus nuevos servicios suelen ser copias de baja calidad de servicios ya existentes y además llenas de errores (da la sensación de estar siempre en fase beta). Constantemente dejan en la cuneta a sus usuarios, y no sólo por lo ocurrido con Reader (aparte de que han cerrado muchos más servicios, pregunto ¿qué fue de GWT?). Intento buscar alguna razón para usar Keep pero vaya, es que no encuentro ni una sola. Me reitero en lo dicho anteriormente, “señores, torres más grandes han caído“. Bienvenidos a la etapa oscura de Google.

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.