A menéame que lo parta un rayo

Bueno, lo de las caídas de Amazon ya no es trending topic, pero quería hablar sobre ello, más por Amazon que por otra cosa. Y porque lo tenía como borrador cogiendo polvo…

Leí en meneame.net (en uno de esos post recursivos) que un rayo caído en las dependencias de Amazon WS en Irlanda fue la causa de la web llevara caída un tiempo (3 días, sin ir más lejos). Existen otras webs que se vieron afectadas, pero me interesa menéame porque a raíz de esa noticia he encontrado un caso práctico de Amazon Web Services, que es en el mundillo en el que estoy medio metida ahora.

Menéame, tras pasar por varios servicios de hosting, finalmente se pasó a «la nube» de Amazon hace algún tiempo. Concretamente utilizan instancias EC2 (Amazon Elastic Compute Cloud). Es decir, utilizan servidores virtuales de diferentes capacidades, algunos persistentes y otros que utilizan las capacidades de crecimiento bajo demanda, para las peticiones web. Además para los backups utilizan S3 (Amazon Simple Storage Service).

No voy a contar detalladamente su arquitectura, que eso ya lo cuenta uno de los creadores, Ricardo Galli, de meneame.net en su blog, en el fabuloso post «Cómo montamos Menéame en Amazon EC2«.

De lo que quiero hablar es de si los 3 días que perdieron levantando la Web tuvieron que ver con Amazon o también con la arquitectura que han elegido, como algunos trolls les han echado en cara. Dicen que su mayor problema se lo ha dado el servicio EBS (Elastic Block Storage). ¿Y qué es EBS? Pues son volúmenes de almacenamiento a nivel de bloque diseñados para utilizarlos con las instancias de Amazon EC2 a modo de volúmenes persistentes (si muere la instancia el volumen persistente se mantiene y se puede volver a montar en ella o en otra).
Al parecer, Amazon descubrió poco después del rayo que tenían un bug en la gestión de la copia de seguridad de los volúmenes EBS ¡Ole!.

Partimos de la base que Amazon tiene que ser fiable y profesional, ya que muchos externalizamos la complejidad apoyándonos en que ellos pueden darnos servicios que para nosotros serían impensables: por lo caro y complejo. No nos hacemos la idea de que sus copias de seguridad fallen y que se puedan perder datos. Y esto es justo lo que ha pasado en algunos casos.

¿Es culpa de meneame.net no haberlo previsto? En este caso creo que no, precisamente por la premisa del párrafo anterior: Ey tíos, que vosotros lo sabéis hacer mucho mejor, tenéis recursos «casi infinitos», sois más guapos y ¡leche! Sois Amazon. Pero sí sería su culpa si vuelve a pasar y no han creado un plan alternativo.

En mi empresa hemos tenido una experiencia agridulce estos últimos meses con algunos servicios de Amazon. Más dulce que agria, eso también es verdad. Usamos, entre otras cosas, EC2, S3, SimpleDB y el servicio AIM (AWS Identity and Access Management) que permite tener múltiples usuarios pertenecientes a una misma cuenta de Amazon.

A raíz de agunos problemas con AIM nos hemos encontrado con un servicio técnico bastante regular, pocas soluciones a nuestros problemas y, lo que es peor, datos inconsistentes entre fuentes internas. Seguimos una arquitectura basándonos precisamente en datos dados por ellos, y en su promesa de que «Oye, que si quieres más sólo tienes que pedírnoslo (y pagárnoslo)«. Eso hicimos, pero ¡Oh, sorpresa! ¡Oh, campos de soledad! Resulta que ESO no se lo podíamos pedir. Ni pagando.
Veredicto: Cambio de arquitectura en el último momento y esperando a su promesa de «Estamos preparando una cosa genial que será mejor que IAM«.

Siento ser tan críptica, pero la empresa no es mía y no creo que dar detalles de arquitecturas y demás aclare mucho.

Para finalizar: creo que Amazon está muy bien, aunque es algo inmaduro. Madura a base de sus clientes, del dinero de éstos y de sus férreas claúsulas legales por las que si pierden cosas tuyas te tienen que indemnizar realmente poco. Así que si estais pensando en usar AmazonWS, tened claro un plan B, y bastante dinerito.

Microsoft, eres muy raro

Hace algún tiempo aprendí algo muy curioso sobre los ficheros separados por comas (csv) en Windows. Un extraño error que aparecía al intentar abrirlos con excel si tenían algo parecido al siguiente contenido:

ID, NAME, PHONE
1234, Pepe, 915555555
1235, Ana, 915555556

El error que daba era «Se ha detectado que ‘nombrefichero’ es un archivo SYLK, pero no se puede cargar. Puede que el archivo contenga errores o no tenga formato de archivo SYLK. Haga clic en Aceptar para intentar abrirlo con otro formato.«.

¿Qué tiene de especial el fichero anterior? Aparentemente es bastante normal. Pues no, resulta que tiene una particularidad. Si cambiamos el contenido por:

id, name, phone
1234, Pepe, 915555555
1235, Ana, 915555556

Lo abrimos con excel y ¡funciona! No da el error extraño y nadie se queja de nada.

La respuésta la encontramos en lá página de soporte de Microsoft en español o en inglés. En ella se explica el bug: «Cuando Excel identifica este texto al principio de un archivo de texto, interpreta el archivo como un archivo SYLK. Excel intenta convertir el archivo desde el formato SYLK, pero no puede hacerlo porque no hay códigos SYLK válidos después de los caracteres ‘ID’.»

La solución se puede conseguir de tres maneras:

  • Poner «id» en minúsculas.
  • Poner un apóstrofe delante de «ID»
  • Pasarse a LibreOffice

Evidentemente yo recomiendo la última.

Otro de los Expedientes X que me he encontrado es que no se pueden crear ficheros, ni directorios de nombre «con» (o «CON»). Si indagamos un poco, veremos que «con» es una palabra reservada que, junto a unas cuantas más, no se pueden usar desde el pleistoceno hasta Windows 7 (¿y las siguientes versiones? Pues ni idea…).

¿Conocéis alguna otra cosa «rarita» sobre Windows o sus programas?