Apple y el día después

Steve Jobs deja de nuevo Apple. 

Aunque las razones de su renuncia no hacen alusión de forma expresa a problemas de salud, todo parece indicar que esta vez, su salida se debe a una nueva recaída en su enfermedad. "El día que no pueda hacer frente a mis obligaciones al frente de la compañía, lo dejaré" y este parece ser el argumento de su renuncia.

La pregunta que nos hacemos muchos es si Tim Cook será capaz de mantener en la cresta de la ola, a una Apple que vive uno de sus momentos más dulces. 

El que las acciones de Apple hayan bajado más de un 5% nada más conocerse la noticia, no es un dato relevante respecto a su futuro, sino el efecto inmediato y previsible de una noticia de este calado.

Apple a lo largo de su historia ha pasado por luces y sombras. Algunas de las sombras estuvieron a punto de dar al traste con la compañía, pero siempre, como Ave Fénix, Jobs a resurgido de sus cenizas y ha sido el impulsor de una nueva etapa de gloria.

Steve Jobs tiene 56 años, por lo que si su salud mejora, seguro que volverá a Apple, pero no solo porque en un hipotético caso, Apple necesitara de un nuevo golpe de efecto, sino porque Jobs es Apple (el tiempo dirá si Apple es Jobs) y mientras pueda y le dejen, él estará ahí.

La sucesión de Jobs por Tim Cook, es algo que ya estaba previsto, pero, ¿habrá sabido este recoger la esencia de Jobs?, no solo para mantener la filosofía de calidad y diseño que ha caracterizado siempre a Apple, sino la capacidad de sacarse de la manga un producto que revolucione el mercado.

La inercia que tiene Apple en este momento, con productos estrella como iPhone e iPad, hará que el efecto de la salida de Jobs, se vea amortiguado y habrán de pasar varios años para ver si Apple, con Cook  o cualquier otro a la cabeza, son capaces de reinventar el gadget de turno para convertirse de nuevo en líderes de mercado y ser el ejemplo a imitar. La fórmula parece sencilla, calidad, elegancia y sencillez, pero está claro que solo Apple ha sabido conjugar de forma magistral estas tres variables. 

En esta ocasión, la salida de Jobs es algo que se ha venido madurando desde dentro de Apple y guiada por el propio Jobs, no es como cuando John Sculley le largó con cajas destempladas y le costó a Apple pasar por un sendero de decadencia de casi 15 años.

En cualquier caso, y pase lo que pase con Apple, será difícil encontrar una persona con la visión y el empuje de Jobs. El perseguir hasta el último detalle y sacar de quicio a los ingenieros hasta conseguir lo que él quería, no será lo único que ha hecho que Apple esté donde está, pero seguro que sí ha tenido mucho que ver.

Posiblemente Apple no pueda continuar durante mucho más tiempo en una posición dominante en ciertos mercados como lo es ahora, pero esto, seguramente también ocurriría aunque Jobs siguiera en la brecha.

Todos trabajamos en equipo, pero...

Esta historia es un clásico de la literatura sobre el trabajo en equipo y la comunicación, pero sigue vigente hoy en día. A mi, por lo menos, me suena de algo...

Había que hacer un trabajo muy importante y “Cada uno” estaba seguro de que “Alguien” lo haría.

“Cualquiera” pudo haberlo hecho, pero “Ninguno” lo hizo. “Alguien” se disgustó por eso, ya que el trabajo era de “Cada uno”.

“Cada uno” pensó que “Cualquiera” podría hacerlo, pero “Ninguno” se dio cuenta que “Cada uno” lo haría.

En conclusión, “Cada uno” culpó a “Alguien” cuando “Ninguno” hizo lo que “Cualquiera” podría haber hecho.

 ¿También a ti te es familiar?

Cobra por lo que vales o acabarás valiendo por lo que cobras

Cobra por lo que vales o acabarás valiendo por lo que cobras. Esta es la frase (no es mía) que me vino a la cabeza después de leer las peripecias acontecidas en el Ayuntamiento de Bilbao con los dispensadores de tikets de turno en el Servicio de Gestión de Espera.

Este es un suceso lamentable, en el que todos, desde la empresa adjudicataria como el propio Ayuntamiento de Bilbao y los propios ciudadanos, han salido perjudicados. ¿Quien tiene la culpa de que sucedan este tipo de cosas? ¿Las administraciones públicas? ¿Las empresas? ¿La crisis?. Todos y ninguno. No hay una respuesta sencilla para esta pregunta.

Evidentemente, este no es un hecho aislado y en muchas otras ocasiones se han producido casos similares, donde una empresa acude a un concurso público con un precio muy por debajo del precio de licitación, los cuales, huelga decir que siempre están muy ajustados. ¿Por que ocurre esto?. En este caso, la respuesta es más fácil, desde mi punto de vista.

Hay dos posibles respuestas: una es cuando se considera una inversión, donde se asume el riesgo o incluso la certeza de la pérdida económica y otra, la de la pura subsistencia.

Ya sabemos que el “dumping”, cuando menos, es una práctica desleal, pero a menudo utilizada para acceder a un mercado o simplemente para desbancar a la competencia.

Si ponemos como ejemplo las administraciones públicas, sabemos que son; o al menos lo eran hasta hace poco, un cliente apetecible para la mayoría de los proveedores por dos motivos: son (o eran) clientes que siempre pagan y por otro lado, son (o eran) clientes que dan continuidad a las inversiones. Pero por otro lado, también sabemos que acceder a las instituciones públicas no es fácil y muchas veces es un coto cerrado, en el que no se entra sin una ayuda externa.

En muchas ocasiones, las empresas asumen el acceso a un concurso o proyecto, como una inversión para captar un cliente, del que se espera obtener un beneficio futuro donde se retorne esta inversión inicial. Evidentemente, esto no es aplicable a todas las empresas ni proyectos ya que puede ser un riesgo o coste fuera del alcance de muchos. ¿Que ocurre si después de este proyecto no hay continuidad?

Hay otros casos en los que las empresas se ven abocadas a obtener proyectos de forma desesperada, únicamente con el objetivo de poder mantenerse en el mercado o en el propio cliente. Está claro que cuando esta es la circunstancia, el riesgo es aún mayor ya que el impacto sobre la empresa, en caso de fracaso, suele ser letal.

Si echamos la vista atrás, al menos en el mercado de las IT, vemos que los precios de contratación de proyectos y servicios, no solamente no han subido en los últimos años sino que han descendido considerablemente. Podríamos pensar que es lo habitual en cualquier economía de mercado, donde aumenta la competencia y la oferta supera a la demanda, pero, ¿es esto realmente lo que ha ocurrido?. En parte si, ya que veníamos de unos años de bonanza económica y de sobre valoración de ciertos productos y servicios relacionados con las IT. El problema, es que hemos pasado de pagar/cobrar casi cualquier precio por obtener/proporcionar un producto o servicio con calidad y garantías, a una situación en la que prima sobre todo el coste, descuidando la calidad de los servicios y dando una patada hacia adelante a los problemas derivados de la falta de calidad.

Algunas empresas han sabido reaccionar ante esta nueva coyuntura y han sabido conjugar la moderación de los costes con un aumento en la calidad de sus productos y servicios, aportando de esta forma un factor diferencial sobre el resto. Pero esta no es una fórmula fácil de aplicar, de echo, está incluso fuera del alcance de muchas empresas.

Cada vez está calando más hondo la apuesta por la calidad, tanto desde el punto de vista del que compra como del que vende y aunque en tiempos de crisis poner en práctica medidas para aumentar la calidad, muchos lo ven como un coste inasumible, está claro que es la apuesta por la continuidad del negocio.

Quiero dejar claro, que con mis anteriores comentarios, no me estoy refiriendo a la empresa adjudicataria del servicio al que hacía referencia al inicio, ya que desconozco totalmente a la empresa y sus circunstancias, así como el proceso de licitación del citado concurso. Solamente he utilizado este suceso como base para esta reflexión.

El salvaje Internet

En los últimos meses, estamos viviendo una especie de película de aventuras en Internet, de hecho, algunos lo ven como una película del oeste y lo califican ya como un “webstern”.

Por un lado, tenemos a los chicos de Anonymous haciendo de “Los Vengadores” y a los de LulzSec haciendo de “Joker”. Los unos porque se han erigido en garantes de las libertades del pueblo y los otros porque se divierten mostrando las vergüenzas a nivel de seguridad de todo el que se cruza en su camino.

Para colmo, en los últimos días hemos visto lo que parecía un enfrentamiento entre Anonymous y LulzSec, por un supuesto “chivatazo” al FBI , por parte de Anonymous, sobre la identidad de algún integrante de LulzSec. Esto parecía que iba a ser “Furia de Titanes”, pero no, al final ha sido algo más parecido a “Ocean's Eleven” y se han juntado para fastidiar al SOCA (El FBI británico), en la operación #Antisec.

De repente, cuando todo el mundo estaba atento a la película, aparece un “To be continued...” y los chicos de LulzSec deciden retirarse de la escena, dejando en suspense al personal. Ya estamos acostumbrados a las segundas partes...

Alguno puede pensar que esto de buscar relaciones entre estos grupos y el séptimo arte no está justificado, pero si vamos a la página LulzSec Exposed, donde Anonymous le mete el dedo en el ojo a LulzSec, podemos leer en su cabecera “Web Ninjas” in Action. ¿Estará Jackie Chan detrás de todo esto?.

No tengo claro el final de esta película, de hecho, no se quienes son los buenos y quien los malos, es más, no tengo claro el fin a conseguir. Quizá, como ocurría en “El Plan Perfecto”, hasta el final no conoceremos los verdaderos motivos.

Internet es aún un territorio salvaje, donde hay mucho por conquistar, muchas leyes por aplicar y sobre todo, mucho sentido común por usar. Cada vez tenemos que estar más atentos a lo que hacemos en Internet y a lo que nos llega de Internet. No hay que tener miedo, que el miedo nunca es bueno, pero si hay que ser precavidos.

Me gustaría ser optimista y pensar que todos los acontecimientos que hemos vivido en los últimos meses, realmente servirán para hacer que este “agujero de gusano” que es Internet, acabe siendo un lugar más seguro por el que transitar. En realidad no hay nada nuevo que no viniera pasando desde hace años, pero últimamente si que está cambiando la forma en la que ocurren las cosas.

Quizá estemos viendo algo similar a lo que ocurrió años atrás, cuando los creadores de malware solo pretendían notoriedad, aunque si extrapolo los resultados..., me temo que algunas cosas van a cambiar de forma sustancial.

Entonces... ¿Hadoop no es nada?

Efectivamente, podríamos decir que Hadoop, en sí, no es nada. No es nada al menos en el sentido en el que , equivocadamente, mucha gente piensa.

Hay una creencia bastante extendida de que Hadoop es una base de datos distribuida o una base de datos NoSQL (ver post Bases de datos NoSQL... ). No, no es eso. Veamos lo que sí es.

Hay infinidad de documentación sobre Hadoop en Internet, así que tampoco pretendo entrar demasiado en detalle, además, necesitaría más tiempo y más de un post. No es el objetivo.

Para empezar, podemos echar un vistazo a la página web de Hadoop (http://hadoop.apache.org/), donde ya nos deja claras las cosas desde el principio:

"La librería de software Apache Hadoop, es un framework que permite el procesamiento distribuido de grandes cantidades de datos a través de clusters de ordenadores, usando un modelo simple de programación"

Librería, Framework,...Vaya, que decepción, así que ¿para usarlo hay que programar?. Pues si, en efecto. Es lo mismo que si instalamos en nuestro ordenador el ".Net Framework 4.0". Nos da la herramienta, pero la casa la tenemos que construir nosotros.

El proyecto Apache Hadoop, consta de tres subproyectos: Hadoop Common, Hadoop HDFS y Hadoop MapReduce, que combinados de forma conjunta, nos proporcionan las herramientas necesarias para construir un sistema que, como dice el enunciado, nos permita procesar grandes cantidades de datos, en un modelo distribuido, con alta disponibilidad, usando un hardware barato y con un alto rendimiento. La verdad es que dicho así, suena muy bien.

Ya veremos más adelante lo que son Common, HDFS y MapReduce. De momento, vamos a centrarnos en las cinco características, que nos han llamado la atención:

Procesamiento de grandes cantidades de datos

Hadoop sirve para procesar GRANDES cantidades de datos, y digo GRANDES con mayúsculas, porque estoy hablando (es un decir) de muchos miles de millones de datos. Si no es el caso, pensemos en otra solución (aunque puedes seguir leyendo el post hasta el final).

Modelo distribuido

El que sea un modelo distribuido, no es solo una ventaja, es también una necesidad. Excepto si es para desarrollar, no sirve de nada montar un sistema basado en Hadoop con una sola máquina. Se puede hacer, pero como digo, solo para desarrollar o "cacharrear" con ello. De hecho, necesitaríamos al menos dos. (Cloudera proporciona una distribución bastante estable y sencilla, que permite simular un cluster en una sola máquina y se instala en unos pocos minutos).

Hasta aquí, lo que parecían ventajas, alguien lo puede ver como inconvenientes. Pero bueno, sigamos...

Alta disponibilidad

Esto está muy bien. Si se rompe una máquina, el sistema sigue funcionando. No perdemos los datos y el sistema se recompone para repartir la carga entre los nodos restantes. Evidentemente, cuantos más nodos tenga nuestro cluster, más protegidos estaremos frente al fallo de alguno de ellos.

Que el sistema siga funcionando pese a la caída de un nodo, no es nada especial, pero el que el sistema redistribuya la carga, si es una importante ventaja.

Hardware barato

Este es otro punto interesante. No necesitamos grandes máquinas, prácticamente cualquier PC con disco duro, procesador y memoria, nos sirve para incorporarlo al cluster, además no tienen por que ser todos los nodos iguales. Cada nodo soportará una carga proporcional a los recursos de los que dispone.

Para que no todo sean ventajas, hay que decir que en el apartado de networking, si es preciso gastarse unos euros. Montar un cluster de un par de docenas de nodos, con PC's de 300€, está muy bien, pero si los unimos con un switch de 10MB, por muchos nodos que añadamos, el rendimiento no mejorará.

Alto rendimiento

En este caso, la potencia no nos la proporciona Hadoop sino la acumulación de nodos al cluster, cuantos más nodos, más rendimiento. Obvio ¿no?.

Dado que podemos utilizar un hardware barato, incrementar la potencia de nuestro cluster, no requerirá una fuerte inversión, además, el escalado horizontal es prácticamente ilimitado.

Ya ha quedado claro al principio, que Hadoop es una herramienta, o más bien un conjunto de ellas:

Hadoop Commons: Son un conjunto de librerías y utilidades sobre las que se soportan el resto de subproyectos. Dan soporte para interactuar con el sistema de archivos distribuidos, gestionar el control de acceso a los nodos, colas de trabajos, etc..

HDFS (Hadoop Distributed File System): Es el sistema de almacenamiento distribuido en el que se soportan las implementaciones de Hadoop. Consta de un nodo primario o "NameNode" que  controla los "DataNodes", que son cada uno de los nodos donde finalmente se almacenan los datos.


MapReduce: Es en si el framework que nos permite desarrollar las aplicaciones que son capaces de procesar en paralelo los datos suministrados.

Los trabajos MapReduce se basan en la separación de los datos de entrada (tareas Map), que son enviados como entrada a las tareas de agregación o combinado (tareas Reduce). Que lío ¿no?.

La verdad es que puede parecer complicado pero en realidad es más simple de lo que parece. Pongamos el ejemplo tonto, que no tiene utilidad práctica, pero si didáctica:

Supongamos que tenemos un fichero de texto con varias líneas y queremos contar las palabras distintas que hay en el texto y saber cuantas veces aparece cada una de ellas.

El primer grupo de tareas Map, recibiría cada una de las líneas del fichero y se encargaría de separar cada línea en sus diferentes palabras. Estas palabras se pasarían a las tareas Reduce, que se encargarían de contar las apariciones de cada palabra, así en diferentes niveles de agrupación (tareas Reduce encadenadas), hasta conseguir el resultado final.

En realidad se trata de ir separando los datos hasta el nivel de granularidad adecuado y después agruparlos para conseguir la segmentación deseada.

¿El truco? tareas sencillas que realizan solo una parte del proceso. Si tenemos muchas de estas y trabajando todas a la vez, tenemos un resultado espectacular.

Y esto, a mi ¿para que me sirve?. Esta es la pregunta del millón.

Lo primero que hay que tener claro es que Hadoop no es la panacea para resolver los problemas de almacenamiento, disponibilidad, sustitución de bases de datos, etc.. Hadoop es bueno, pero solo para resolver unas problemáticas muy concretas.

Quizá, para no perder el tiempo, lo primero que se debería hacer es conocer "Que NO es Hadoop". Para empezar, recomiendo la propia Wiki de Hadoop.

Hadoop es una herramienta excepcional, pero solo si se utiliza para el propósito adecuado.

Aunque pueda parecer a simple vista algo muy complicado de poner en marcha, en realidad no lo es tanto. La instalación de los componentes es relativamente sencilla (Proveedores como Amazon, tienen disponibles nodos preinstalados listos para usar). En realidad, solo nos tenemos que preocupar de desarrollar nuestros programas MapReduce y para ello podemos utilizar varios lenguajes como Java, C++, Python, etc., así que alguno de ellos nos resultará más próximo y será más fácil comenzar.

Yo no trabajo por 800 euros

Esta es la frase con la que me encontré haciendo un zapping la semana pasada. En realidad, creo que fue "Yo no trabajo por 800 míseros euros". Se trataba de un programa de televisión, en el que participaban entre otros, unos jóvenes del movimiento 15M.

En el punto en el que yo llegué, hablaban en concreto sobre lo difícil que lo tienen los jóvenes para encontrar un trabajo. Hasta aquí todos de acuerdo, pero mi sorpresa llegó cuando uno de ellos; que creo recordar nunca había trabajado; espetó la frase lapidaria "Yo no trabajo por 800 míseros euros".

Al oír la frase, me llamó la atención y seguí escuchando el debate. La verdad es que acabé impresionado, o más bien indignado, hasta tal punto que apagué la televisión.

Entiendo que un joven que acaba de terminar la carrera (no se si era el caso), aspire a un trabajo relacionado con sus estudios y con una retribución salarial acorde a su nivel de estudios o experiencia, si es el caso. Lo que no entiendo es como se puede hablar con desprecio de un trabajo de 800 euros.

Seguramente este joven (o esta, no lo recuerdo), vive en casa con sus padres, no le falta comida, ropa y dinero para gastar el fin de semana, porque sus padres se lo pueden permitir.

Supongo que si no tuviera el paraguas de sus padres y sin otra fuente de ingresos, no le haría tantos ascos a los 800 míseros euros. De hecho, hay familias enteras en este país, que viven con esos ingresos.

Aplaudo que los jóvenes reivindiquen reformas laborales, económicas o sociales, de hecho creo que lo deberían hacer más frecuentemente y con más ahinco. También estoy de acuerdo que en la situación económica actual, los jóvenes tienen muy complicado encontrar un trabajo, independizarse, etc.

A veces escucho decir, que antes los jóvenes lo tenían más fácil, había trabajo para todos. Es cierto que antes había más facilidad para encontrar trabajo, pero también creo que es cierto, que se ha perdido cierto "garbo" o "coraje" para saber buscarse la vida, aunque en esto, seguramente parte de la culpa recae en los propios padres.

La situación laboral es complicada para los jóvenes que buscan trabajo, pero no nos olvidemos que es complicada también para los que no son tan jóvenes y cuando se tienen responsabilidades, lo primero es saber buscarse la vida.

Hay un punto que me gustaría resaltar, y es que tan complicado es encontrar un trabajo como saberlo mantener. En esta vida nadie te regala nada.

No nos engañemos, las empresas no son ONGs y están ahí para ganar dinero, así que no nos van a dar nada que no nos hayamos ganado previamente. Bien es cierto que hay quién se aprovecha de la coyuntura para para dar una vuelta de tuerca más y engordar la cuenta de resultados a costa del sacrificio ajeno.

Un trabajo de 800 euros no es para toda la vida, pero puede servir para adquirir experiencia, saber valorar el trabajo y ser un primer paso para encontrar otro mejor.

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.

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

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.

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.