domingo, 22 de mayo de 2011

El tiempo, ese bien tan preciado

A menudo nos surgen reflexiones sobre el poco tiempo que tenemos, lo que nos gustaría hacer si tuviéramos tiempo o como malgastamos nuestro tiempo, entre otras.
Está claro que el tiempo es un bien muy preciado, todos creemos tener poco y queremos tener más. Algunos incluso cambiarían dinero por tiempo.
 En muchas de las circunstancias en las que nos referimos al tiempo, lo hacemos usando las mismas expresiones que utilizamos para referirnos al dinero: gastar el tiempo, ahorrar tiempo, invertir el tiempo, robar tiempo, etc., pero el tiempo no se puede atesorar y utilizarlo cuando lo necesitamos, tampoco podemos comprarlo o venderlo, el tiempo sencillamente pasa, da igual en que lo hayamos ocupado. 
Existen algunas iniciativas que se denominan "bancos de tiempo", donde por decirlo de una forma sencilla, se deposita el compromiso de disponibilidad de x horas de tu tiempo para realizar una actividad, las cuales se pueden canjear por otras tantas x horas del tiempo de otra persona en otra actividad. Como iniciativa de comunidad, no está mal, pero ¿por que llamarlo banco de tiempo?.

Ya que se utiliza el símil del banco, como si de dinero se tratase, veamos que la similitud no lo es tanto:

En un banco se deposita dinero por diferentes motivos: seguridad, rentabilidad, etc. Si yo deposito el compromiso de 1 hora de mi tiempo en uno de estos bancos, pasado un año, ¿tendré más de 1 hora?, pues no, ni mi tiempo estará más asegurado.

Si no tengo tiempo, ¿puedo pedir un préstamo? ¿que garantía daré?, pero yo necesito tiempo para estar con mi familia y con mis amigos, ¿va a venir un señor que sí tiene tiempo para estar con mi familia?, en fin, sin comentarios.

Si yo no tengo tiempo para arreglar un grifo, puedo cambiar ese tiempo con un fontanero para que me arregle el grifo, pero también puedo pagarle con dinero. ¿He comprado tiempo?, pues tampoco.

Hablamos también de "ladrones de tiempo", refiriéndonos a pequeñas interrupciones en nuestro trabajo, pero ¿se queda el ladrón con mi tiempo, yo tengo menos y el más?.

El tiempo es una dimensión en un solo sentido, solo fluye hacia adelante, aunque según Stephen Hawking e incluso el propio Albert Einstein, a distintas velocidades según donde nos encontremos. Por ejemplo, el la singularidad, al borde de un agujero negro.

Si tuviéramos una máquina del tiempo que nos permitiera viajar a través de él, ¿tendríamos más tiempo?, pues tampoco. Da igual cuanto tiempo haya pasado para los demás, el nuestro no habrá encogido o estirado.
Decía San Agustín: "No hubo tiempo alguno en que no hubiese tiempo".
Siempre hay tiempo, solo tenemos que elegir lo que hacemos mientras este trascurre de forma inexorable a pesar nuestro.

La cuestión, no es tener más tiempo, sino que nos sintamos a gusto con las actividades que hemos realizado durante su trascurso. Unas veces "hemos aprovechado el tiempo",  otras veces lo hemos "malgastado" y otras, sin más, lo hemos "gastado", da igual si hemos estado trabajando o de vacaciones.


Hay bienes inmateriales, como el tiempo o la razón. El tiempo, todos tenemos el mismo y todos queremos tener más, en cambio la razón, no todos tenemos la misma, pero todos creemos tener suficiente.

domingo, 15 de mayo de 2011

Sobre cerdos y gallinas


Aunque muy conocida la fábula o chiste del cerdo y la gallina, lo voy a reproducir en versión libre, para que sirva de introducción para el que no lo conozca.

“Se encuentran un cerdo y una gallina y deciden abrir un restaurante.
El cerdo dice: ¿como llamaremos al restaurante?
La gallina responde: Huevos con bacon
El cerdo contesta: No me parece justo, yo estaría comprometido mientras que tú solo estarías involucrada”

Los roles “cerdo” y “gallina” están presentes en todos los ámbitos de la vida, no solamente en SCRUM :-). En todas las comunidades, sociedades, equipos y convivencias, hay roles cerdo y gallina en mayor o menor medida.

La diferencia entre estar involucrado o comprometido, que a priori, se podría asociar al nivel de riesgo que se toma al participar en un proyecto; laboral o sencillamente de relación, en muchos casos se vuelve algo absolutamente subjetivo y cada uno cree ocupar un rol, que no es visto así por los demás.

Tenemos como “gallinas innatas” a aquellas personas que que se dedican a “estar”; en algunos casos, solo a “figurar”, que arriman el hombro en contadas ocasiones y solo, cuando no queda más remedio. Algunos de estos “fasiánidos”, suelen tener una habilidad especial, para aparecer cuando ha finalizado el trabajo.

Tenemos como “cerdos de vocación”, a aquellas personas que lo dan todo, que no reparan en sacrificios para conseguir el buen fin del proyecto y con los que puedes contar cuando se ponen las cosas feas. Este tipo de “suidos”, a menudo se ven eclipsados por los “fasianidos” cuando las cosas salen bien y cargan con las culpas cuando la cosa se tuerce.

Esta categorización puede parecer un poco extremista y de hecho, lo es, pero ¿le suena a alguien?. La realidad no es blanca ni negra y oscila sobre la escala de grises con el tiempo.

¿podemos elegir nuestro rol? . No, generalmente nos viene impuesto en cada caso, además no suele ser buena idea cambiarlo, no suele acarrear buenos resultados. Cada momento y cada escenario son una partida distinta, solo puedes jugar las cartas o pasar la mano, habrá otras.

El grado de implicación y compromiso es difícil de medir, además, bajo determinadas circunstancias, todos tendemos a pensar que los demás son las “gallinas” y nosotros los “cerdos” y esto en realidad no es más que un reflejo de nuestra propia frustración.

El cerdo y la gallina, sí pueden poner un restaurante juntos, solo hace falta cambiarle el nombre a "La tortilla de patata".

lunes, 2 de mayo de 2011

Las nubes también se caen II

Habrá que esperar algunas semanas más, antes de sacar conclusiones acerca de como va a afectar a Amazon y al Cloud Computing en general, la caída de los servicios de Amazon (Las nubes también se caen), pero de momento no parece que vaya a ser una catástrofe para Amazon, ni que esto vaya a provocar un cambio de tendencia en la adopción del Cloud Computing por parte de las empresas.

Lo que si es seguro, es que este "incidente", va a marcar un punto de inflexión en muchos aspectos relacionados con el Cloud Computing.

Amazon tendrá que hacer algo más que pedir disculpas a sus clientes y regalarles 10 días gratis de servicios. Tendrá que volver a ganar la confianza perdida y para ello deberá actuar en varias líneas de mejora.

Evidentemente, deberá poner el foco en como mejorar los procesos de mantenimiento, automatización de tareas, supervisión de procesos, monitorizaciones, etc. ya que en este caso han sido los causantes del problema.

Desde el punto de vista técnico, deberá replantearse el modelo de replicación de datos entre Zonas. Está claro que los mecanismos de aislamiento entre Zonas de Disponibilidad, no han sido lo suficientemente efectivos. El factor comunicaciones ha sido determinante.

En cuanto a comunicación y transparencia también deberá aprender de lo ocurrido. Desde siempre han sido bastante reacios a dar más información y explicaciones que las estrictamente necesarias, pero tiene que pensar que la información a sus clientes ante una caída de este tipo, puede ser beneficiosa en el sentido de que los propios clientes pueden colaborar en restaurar la situación global, ayudando a restaurar la suya propia.

El SLA que proporciona Amazon no está a la altura de las circunstancias. Cualquier empresa que decida externalizar los servicios con un tercero, negociará un SLA con su proveedor. En este caso Amazon no puede negociar con cada cliente un SLA particular ¿o si?, pero lo que si puede hacer, es proporcionar un SLA de verdad, donde se garantice algo más que un porcentaje de up-time.

Pero no solamente Amazon se deberá poner las pilas, y cuando digo Amazon, quiero decir además Microsoft, Akamai, Google, IBM, etc., sino los propios "usuarios". El proveedor Cloud ofrecerá una serie de ventajas y garantías para asegurar la disponibilidad del servicio, o en su caso, minimizar el impacto de una caída, pero el propio cliente debe hacer lo propio con su modelo de aplicación y despliegue. No es tan sencillo como poner la aplicación "en la nube" y esperar que el proveedor Cloud haga el resto.

El diseño de las aplicaciones, desde el punto de vista de disponibilidad y de seguridad es un aspecto que no va a cubrir en su totalidad el proveedor. Tampoco es que sea algo distinto de lo que se debiera hacer en un modelo on-premise, pero el contexto es diferente y las herramientas de las que dispone el cliente, no son las mismas.

Como se suele decir, "a río revuelto, ganancia de pescadores" y a buen seguro, otros proveedores Cloud, verán en este capítulo, una excelente oportunidad de ampliar su base de clientes, no solo por que abandonen Amazon, sino porque muchos de ellos, o al menos los más importantes, diversificarán sus implementaciones Cloud entre varios proveedores.

Lo que le ha pasado a Amazon, le puede pasar a cualquiera. Mejor dicho, le ha pasado a casi todos, en mayor o menor medida.

En general, no creo que vaya a cambiar nada en cuanto a la estrategia; a nivel de decisión; de movimiento hacia la nube, aunque quizá los modelos híbridos de nube pública y privada ganen posiciones frente al modelo de nube pública en exclusiva. Reddit, uno de los afectados por el "apagón", ya se ha pronunciado en este sentido.

domingo, 1 de mayo de 2011

Las nubes también se caen

La semana pasada se produjo la caída de los servicios EC2 de Amazon (Amazon Elastic Compute Cloud), los cuales tardaron varios días en recuperarse al completo. La caída afectó a conocidas empresas como Foursquare, Reddit, Quora o Hootsuite entre otras.

El impacto mediático ha sido notable, sobre todo teniendo en cuenta que en plena efervescencia del Cloud Computing, una caída de este tiempo en un proveedor de la envergadura de Amazon, da argumentos a los detractores del Cloud Computing.

Amazon tiene sus datacenters repartidos en 5 regiones; 2 en EE.UU. (costa este y oeste), uno en Europa (Irlanda) y 2 en Asia (Tokio y Singapur); y cada región se separa varias Zonas de Disponibilidad (AZ – Availability Zone). Cada AZ está aislada de las demás y entre ellas no debe haber puntos comunes de fallo, al menos es lo que publicita Amazon.

Todo comenzó el jueves 21 de abril, durante una operación rutinaria en la AZ del Norte de Virginia en la Región Este de EE.UU.. Por un error, se desvió el tráfico de uno de los routers a la red de backup, que dispone de menos capacidad y una mayor latencia. Esto provocó una atasco que se se convirtió en una reacción en cadena, primero en nodos EBS (Elastic Block Store), después en las API de control de los cluster EBS, el RDS (Relational Database Service), que se soporta en el EBS. Esto acabó afectando a todas las AZ's de la misma región.

Amazon no proporciona un servicio de replicación entre regiones, aunque si entre AZ's, a cambio, proporciona un API para que cada usuario pueda gestionar la tolerancia a fallos entre regiones. Aunque en menor medida, por este motivo otras regiones tuvieron pequeños “atascos”, que Amazon lo cuantifica en un 0,07%.

Muchos clientes, se han quejado de la poca transparencia e información que proporcionó Amazon durante la caída. En un principio la única información fue la que proporcionaba el monitor de AWS  (Amazon Web Services). De hecho, algunos clientes indican que si hubieran dispuesto de más información acerca de los motivos, hubieran podido recuperar antes sus sistemas.

Algunas quejas, como las de Justin Santa Barbara (Why the sky is falling), fundador y CEO de FathomDB, van en el sentido de que AWS no cumple sus propias especificaciones y ha roto sus promesas de disponibilidad dentro de las AZ's, aún cuando los sistemas desplegados siguieran las especificaciones de Amazon al respecto.

Pero no todo el mundo se ha quejado del incidente, de hecho hay quién indica que el perjuicio sufrido está compensado con las prestaciones y el precio que Amazon proporciona a sus clientes.

La verdad es que no todos los clientes de Amazon en la AZ afectada, que por cierto, es la más concurrida, se han visto afectados, o al menos de la misma forma. En concreto NetFlix o Twilio, no sufrieron las consecuencias.

En el caso de Twilio; según explica Evan Cook en su blog, el diseño de sus aplicaciones, el poco acoplamiento entre ellas y la distribución de los servicios, les ha permitido no verse afectados por esta caída. Quizá Amazon quiera incluir algunas de las recomendaciones que hace Evan, en sus propuestas de despliegue.

Después de todo el chaparrón, Amazon ha publicado un informe, que lo han denominado “post-mortem” explicando lo ocurrido y donde finalmente dice que “recompensará” a los clientes con instancias EC2 en la AZ afectada, con el equivalente a 10 días del consumo de los volúmenes EBS, instancias EC2 e instancias RDS, que tenían contratados en el momento de la caída.

Curiosamente, dado que la caída del servicio ha sido de 4 días, y teniendo en cuenta que; tal y como publican en el FAQ, el up-time que garantiza es del 99,95%, legalmente no se han incumplido los términos de SLA.

Ahora es tiempo de sacar conclusiones, no solamente por parte de Amazon, sino por parte de proveedores de Cloud Computing y de usuarios, actuales y futuros. Esto debe servir para aprender y mejorar los servicios y aplicaciones que corren en este modelo. En cierto modo, es bueno que pasen estas cosas.