Publicado el

Chaos Engineering: ¿resistirían tus servidores en la nube el ataque de un ejército de monos locos?

Ningún sistema o plataforma en producción es infalible a caídas. Tampoco podemos asegurar que el lanzamiento de ningún producto se venga abajo a las pocas horas. Quizás en algunos casos se podría haber evitado con un mayor esfuerzo de desarrolladores de software y los administradores de sistemas en las configuración de las aplicaciones, pero nada es así de obvio cuando dispones de una vasta infraestructura distribuida y en diferentes servicios en la nube.

Los usuarios de internet parecen acostumbrados a que sea “normal” que alguna de sus apps o plataformas en la nube se caiga cada cierto tiempo. Pasen horas sin poder acceder al servicio o no puedan ver el último capítulo de su serie. Lo hemos visto con Facebook, Whatsapp o, incluso con algo mucho más frustrante, como HBO España en el estreno de Juego de Tronos. ¿Pero cómo evitar esas caídas masivas? ¿Y, por supuesto, evitar las pérdidas de monetarias que se producen cuando esto sucede?

De aquí surge Chaos Engineering poniendo sobre la mesa la idea de cómo afrontaría cualquier infraestructura distribuida el hecho de que un ejército de monos entrara a sabotear cada una de las configuraciones de red, apagando máquinas en AWS o tirando de forma aleatoria algunos de los microservicios conectados. ¿Qué ocurría? ¿Seguimos respondiendo con normalidad? ¿O por el contrario responderemos con terribles errores 500, 503 o nada de nada?

Chaos Engineering no es algo nuevo, ni el hype del momento

Tenemos que remontarnos a finales de 2010 cuando Netflix publicó su magnífico post sobre las lecciones aprendidas migrando a Amazon Web Service. Por un lado dejaba claro, como una empresa de sus dimensiones necesitaba la nube para poder seguir creciendo y, por otro lado, dejaba claro la preocupación de cómo iba asegurar que todo funcionará bienteniendo ya decenas de servicios distribuidos y ahora totalmente deslocalizados de sus data centers.

De este modo, lo primero que hicieron fue crear un conjunto de herramientas llamadas como el cariñoso apelativo de Chaos Monkey. En un principio, para matar aleatoriamente instancias de AWS y ver cómo afectaba sobre su infraestructura.

De este modo, Netflix se aseguraba tener un control predictivo de cuál sería la experiencia del usuario cuando alguno de sus elementos más importantes se viniera abajo. Así, si el sistema de recomendaciones se caía, ellos podrían redirigir ese tráfico a algo más estático como el listado de de series más populares. O si el sistema de streaming de la plataforma fallaba podría empezar a ajustar la calidad de la reproducción hasta estabilizar la plataforma, de modo que el usuario pudiera seguir usandolo sin cortes. En ningún caso, si la base de datos de recomendaciones falla debería afectar a otro servicio aislado como el servicio de streaming. Si esto sucediera tendríamos un problema, probablemente una dependencia mal configurada totalmente innecesaria.

Causar fallos intencionadamente para descubrir errores en nuestra plataforma en producción

La metodología que promueve Chaos Engineering es simple en concepto, pero complicada de ejecutar. Si los test unitarios son la parte más “micro” centrada en que nuestro código haga lo que dice que hace, entonces Chaos Engineering se puede considerar perfectamente como la parte “macro” para asegurar el correcto funcionamiento en conjunto de toda nuestra infraestructur (en producción).

Es muy complicado a día de hoy introducir la importancia de Chaos Engineering en la cultura de muchos equipos de desarrollo. Posiblemente culpa de los responsables técnicos como el director de tecnología (CTO o CIO) incapaces de comprender lo que cuesta realmente esos fallos de producción cuando ocurren y lo que cuesta a la empresa.

Obviamente, introducir una cultura entre el equipo de desarrolladores de software en la que busquemos proactivamente los fallos de nuestro sistema no es algo habitual, más bien nos tiramos de los pelos a posteriori cuando algo falla inexplicablemente.

Aunque cueste, necesitamos encontrar esos fallos antes de que pasen en nuestra arquitectura: esas latencias innecesarias, esos fallos aleatorios que no sabemos descubrir o que nos impediría servir adecuadamente todas las peticiones que nos lleguen cuando nuestra plataforma tenga un pico de usuarios activos.

Probablemente, los primeros en convencerse serán aquellos que han tenido que luchar con fallos en producción un viernes por la noche o un día festivo. No están dispuestos a que eso vuelva a ocurrir.

Chaos Engineering en la práctica

Tal como describe el manifiesto de Chaos Engineering, para abordar la incertidumbre de los distribuidos a gran escala debemos seguir una serie de pasos para realizar los experimentos necesarios:

  • Tenemos que ser capaces de medir nuestro sistema en condiciones normales. Si no estamos monitorizando nuestra plataforma, ya no sólo no podremos averiguar qué falla cuando ejecutemos el experimento, sino que a día de hoy somos incapaces de ver que algo está dando errores. Importante siempre monitorizar tus aplicaciones y la salud de tus componentes.
  • Realizar hipótesis sobre estado al que llevaremos al sistema en producción con los fallos. ¿Cómo debería comportarse? ¿Qué esperamos de él?
  • Definiendo los puntos de fallo de nuestro sistema tenemos que acordar ciertos eventos que provocarán errores lo más parecidos al mundo real: servidores que dejan de funcionar, discos que se quedan sin espacio o pasan a modo lectura, conexiones de red inestables, latencias altas de respuestas,..
  • Trazar un plan revisando los resultados del experimento. Si se ha cumplido nuestra hipótesis o si nos hemos dado cuenta que hay debilidades reales que hacen caer al sistema. Tenemos que solucionarlas antes de que se produzcan de forma real.

Herramientas para utilizar Chaos Monkey en tus aplicaciones

Durante estos años tanto Netflix como AWS han ido desarrollando algunas herramientas para poder simular esos eventos en entornos complejos. Netflix los bautizó como su SimianArmy donde encontramos distintos agentes encargados de elementos fundamentales dentro de nuestra configuración:

  • Introducir delays artificiales a la capa RESTful client-servidor para simular la degradación del servicio y medir si los tiempos de respuestas finales se ven afectados y de qué modo.
  • Encontrar instancias que no se adhieren a los best-practices definidas y ser apagadas. Por ejemplo, esas máquinas puede que estén mal configuradas y no estén siendo autoescaladas adecuadamente.
  • Detectar recursos que no se estén usando en AWS y ser eliminados o descubrir vulnerabilidades o configuración erróneas de seguridad.

Podéis consultar el proyecto open source en Github de SimianArmy y su migración dentro de la infraestructura de CI de Spinnaker. También hay algunos proyectos como Gremlin que intenta acercar los conceptos de Chaos Engineering a más empresas de forma intuitiva a través de su plataforma.

Y si os interesa más el tema aquí os recomiendo este listado sobre recursos en Github: Awesome Chaos Engineering. Así como el libro que escribió el equipo de Netflix sobre el tema.

Como mencionamos más arriba, es necesario que estos experimentos sean adoptados como algo cultural del equipo de desarrollo. Para llevar a cabo los pasos descritos necesitamos flexibilidad para poder simular estos eventos en nuestro entorno de producción o si tenemos un entorno de staging para un experimento inicial más aislado.

Aunque tenemos que recordar que nuestro objetivo es encontrar fallos lo más reales posibles. Y, aunque suena mal, debemos hacer esas pruebas en producción.

Fuente: genbeta

Publicado el

Despues de 130 años, hoy cambia lo que pesa un kilogramo

¿Cuánto pesa un Kilogramo? La respuesta obvia es 1000 gramos. Cierto pero… ¿cuál es la referencia para saber que un kilogramo realmente pesa un kilo? Durante 130 años la referencia ha sido un objeto físico fabricado en 1889. Hoy, 20 de mayo cambia la definición de Kilogramo, una nueva medida que los científicos consideran vital para el desarrollo de la ciencia en los próximos años.

Cuando se definen las medidas, o los pesos, hay que fijar una referencia que debe ser lo más constante posible. Hace dos siglos se definía el kilogramo como la masa de un litro de agua destilada a una atmósfera de presión y 3,98 ºC. El problema de esta definición es que es complicado de conseguir en la realidad, así que en 1889 el Sistema Internacional de Medidas creó un lingote fabricado con una aleación de 90% de platino y 10% de iridio, conocido con el nombre de Le Grand K, guardado bajo llave en la Oficina Internacional de Pesas y Medidas de Sèvres (Francia). Puedes verlo en la foto de apertura de la noticia.

Con el tiempo se realizaron diversas copias de este lingote, que están guardadas en varios lugares del mundo. Cada cierto tiempo se comparan, y se ha comprobado que tras más de cien años… no pesan lo mismo. No se sabe si unos lingotes han perdido masa u otros la han ganado, pero es diferente. Hablamos de microgramos, pero no hay que olvidar que esta referencia del kilogramo no solo se usa para pesar, sino para llevar a cabo experimentos científicos. Y una diferencia de microgramos puede afectar al resultado final. Por eso, a partir del 20 mayo cambia la definición de kilogramo.

Con el tiempo se realizaron diversas copias de este lingote, que están guardadas en varios lugares del mundo. Cada cierto tiempo se comparan, y se ha comprobado que tras más de cien años… no pesan lo mismo. No se sabe si unos lingotes han perdido masa u otros la han ganado, pero es diferente. Hablamos de microgramos, pero no hay que olvidar que esta referencia del kilogramo no solo se usa para pesar, sino para llevar a cabo experimentos científicos. Y una diferencia de microgramos puede afectar al resultado final. Por eso, a partir del 20 mayo cambia la definición de kilogramo.

El objetivo del Sistema Internacional de Medidas es cambiar las referencias basadas en objetos físicos por constantes físicas que no varían, y que son fáciles de medir.

Quizá te estés preguntando por qué la definición de kilogramo se ha basado en un lingote durante más de un siglo. La razón es sencilla: hasta ahora, no había nada mejor.

Pero hace apenas un año, se descubrió una nueva forma de definir un kilogramo a través de la constante de Planck. Aplicando el valor de la constante de Planck, la masa se puede medir de manera precisa en términos de corriente y voltaje gracias a un instrumento llamado balanza de Watt. El nombre de esta herramienta proviene del hecho de que la masa de un objeto es proporcional al producto de corriente eléctrica y voltaje, que representa una potencia que se mide en vatios. La balanza de Watt mide la corriente necesaria para soportar un peso, determinando de esta manera la masa.

Este nuevo método para calcular lo que pesa un Kilogramo no solo es más preciso, sino que se basa en medidas constantes que no varían con el tiempo, y además es sencillo de calcular. Con una báscula de Watt, que es fácil de construir, se puede medir la masa con total precisión, para así calcular exactamente la masa de un kilogramo.

El Sistema Internacional de Medidas aprobó este nuevo método el pasado mes de noviembre, y entra en vigor hoy 20 de mayo.

Los científicos están contentos porque a partir de ahora los experimentos científicos basados en el peso van a ser completamente precisos, y no van a existir variaciones.

Fuente: computerhoy

Publicado el

Twitter guarda tus mensajes directos eliminados durante años, aunque desactives la cuenta, según TechCrunch

Los problemas asociados a Twitter, a diferencia de los que sufre Facebook, suelen tener más que ver con la falta de control sobre el comportamiento de los usuarios de la plataforma que con brechas de seguridad o bugs relacionados con la privacidad.

Sin embargo, en las últimas semanas, la posición de la compañía ha sufrido algún revés. En primer lugar, Twitter reconoció que al modificar la dirección de correo electrónico de acceso al servicio, algunos usuarios que utilizaran Twitter para Android y tuvieran protegidos sus mensajes frente a otros habrían visto cómo se desprotegían sin aviso ni solicitar permiso, algo grave teniendo en cuenta el acoso que sufren algunos tuiteros.

Hoy, TechCrunch desvela de manos del invstigador de seguridad Karan Saini que Twitter aloja en sus servidores durante años los mensajes directos (y por tanto privados) que el usuario ha eliminado previamente. Sin embargo, no es sólo un problema de cuentas activas, sino que los mensajes hacia cuentas que hayan sido eliminadas o suspendidas también se guardan.

Mensajes directos que se guardan aunque ambas partes los eliminen

Twitter

En la imagen, mensajes de marzo de 2016 con una cuenta suspendida que aún se puede descargar de los servidores de Twitter. Fuente: TechCrunch.

TechCrunch y Saini han comprobado que incluso aunque ambas partes eliminen los mensajes, la red social de Jack Dorsey los mantendrá en sus servidores durante un largo período de tiempo, pero tampoco especifican cuánto. Señalan, además, que aunque no se trata de un fallo de seguridad, sino de un bug de funcionamiento, sí puede suponer un riesgo de cara a la privacidad de personas.

Un caso recurrente puede ser el de periodistas u opositores a un régimen que al pulsar un boton de eliminar crean estar borrando un mensajes, para que años después un gobierno solicite esa información. Es posible que otras empresas realicen este tipo de prácticas manteniendo datos viejos, pero Twitter recoge de forma muy clara entre sus condiciones que una vez que una cuenta es desactivada, hay un período muy breve de tiempo en el que pueden acceder a la información.

CCon el RGPD, las compañías tienen mucho que perder si no realizan un correcto tratamiento de datos

Este tipo de casos antes no tenían demasiada relevancia. Las compañías «arreglaban» el problema y continuaban operando de forma corriente. En general, la actuación con respecto a la LOPD no era demasiado fuerte en empresas extranjeras. Sin embargo, la llegada del RGPD puede suponer una amenaza de multa de hasta el 4% de la actividad de negocio del ejercicio anterior. Lo que hay que esclarecer en este caso es sí un botón de eliminar que no borra un mensaje del servidor supone una vulneración de la normal.

Fuente: genbeta