BBVA API Market
En el mundo del desarrollo cualquier cambio puede suponer una serie de errores en todo el sistema y siempre hay que estar preparado. Chaos Monkey es una herramienta que propone que sean los propios desarrolladores quienes provoquen fallos en sus herramientas y desarrollo como forma de entrenamiento.
Alejandro Guirao, Devops en intelygenz, es experto en ella y de su alcance habló precisamente en el evento Haciendo el Chaos Monkey, celebrado en el Centro de Innovación de BBVA. Hablamos con él para que detalle el funcionamiento en profundidad de esta herramienta.
Este tipo de herramientas, que se enmarcan en lo que se ha venido a llamar resilence engineering o ingeniería de la robustez, intentan utilizar un método científico de alguna manera. Primero, lo que tienes que hacer es medir tu sistema: que está funcionando y que su rendimiento es el adecuado sin hacer nada sobre él. Después formulas una hipótesis: si lo ataco, si hago esta serie de faenas, ¿será capaz de resistir? Entonces es cuando intentas probar realizando ataques con la herramienta. Y al final mides, mides y comparas, y puede ser que llegues a una conclusión distinta y eso derive en un nuevo experimento. Es un ciclo un poco reiterativo.
Básicamente verificar la robustez de un sistema. El sistema se compone de software, de una arquitectura en la que está instalado el software, también de una serie de procesos que a veces son de negocio, y a veces procesos humanos. Todo esto que forma una pirámide es lo que se acaba probando con el Chaos Monkey. El simple hecho de provocar un pequeño altercado de introducción, hace que verifiques si realmente eres capaz de sobrevivir a ello.
En sí la herramienta está bastante enfocada a la parte técnica e informática de las empresas. Por eso, su mayor validez va a ser para los departamentos de sistemas o desarrollo de software, pero si vamos un poco más allá y no nos fijamos tanto en la herramienta, sino en los principios y las prácticas de ella, es extrapolable a cualquier ámbito. De hecho, es algo que se viene realizando en la industria aeronáutica, en la de seguridad e incluso en la industria médica.
Sí, en teoría sí que podrían. De hecho, sería una forma de descubrir que realmente tenemos un problema en lo que hemos montado: en la arquitectura, el software o en los procesos. Los problemas pueden llegar y es un riesgo que existe y que se ha de asumir desde lo más alto de la empresa. Es decir, toda la dirección y la gestión de la misma tiene que ser consciente de que se están realizando estos experimentos y de que hay una probabilidad, no nula, de que afecten a la producción. También de que al final los beneficios a medio-largo plazo van a suplir este proceso con creces.
Digamos que en lugar de esperar a que llueva sobre tu tejado, tú mismo empiezas a tirar alguna piedrecilla pequeña y ves si eso resiste o si se viene abajo. Así, ves si tienes agujeros en tu sistema y es una manera de poder arreglarlo.
Sí, sí que lo pone a prueba. Desde luego este tipo de herramientas en las que suceden problemas, involucran al final en su resolución a equipos multidisciplinares y promueven el trabajo en equipo, no solamente de gente de sistemas, operaciones y desarrollo, sino de todos. Por ejemplo, cuando Google ha hecho, utilizando esta filosofía de resilence engineering, simulaciones de inundaciones en data centers, se dio un caso en el que en el simulacro tenían que recurrir a un generador diésel, y no tenían diésel, entonces la gente empezó a buscar cómo conseguir comprar diésel, empezaron a dar teléfonos los ingenieros, pero también la gente de administración y demás departamentos proporcionaron teléfonos de gente que conocían que podía conseguir diésel o que podías prestarle dinero para conseguir diésel. De hecho, hasta hubo un empleado que puso su tarjeta de crédito a disposición de la empresa para poder comprar diésel. Al final es un esfuerzo que involucra equipos multidisciplinares.
Cuando aprendes judo lo primero que te enseñan es a caer, lo que llaman ‘ukemi waza’, de tal manera que luego cuando hagas los ejercicios no te hagas daño al caer porque le has perdido el miedo y sabes cómo caer bien. Esto es un poco lo mismo, el estar acostumbrado a una serie de pequeños fallos, luego los fallos grandes los evites por la experiencia que has tenido. Entronca con la filosofía lean de las startups, el hecho de fallar rápido.
Fue muy buena desde luego, un shock auténtico. Cuando publicó esto Netflix, nadie sabía que estaba haciendo algo a esta escala. Todo lo que hace Netflix siempre sienta precedente. Que dijera que está constantemente provocando esos fallos en su producción, y que no se ve afectado porque han llegado a tal nivel de desarrollo y de ingeniería del software que son casi inmunes a muchísimos errores catastróficos, hizo que la gente quisiera emularlo. Ahí empezaron a apareces post de empresas que se animaban y se subían al carro. Y la comunidad open source en general empezó a utilizarla.
A día de hoy el equipo de Netflix es único en el mundo. Tiene ingenieros que son auténticos expertos en muchísimos temas de performances. Netflix funciona sobre la plataforma de Amazon Web Services (AWS) actualmente y tiene gente que sabe más de AWS que la propia gente de Amazon. Es impresionante. Por lo tanto, siempre es un aval cuando viene de ellos.
Además de Netflix, Google, que utiliza su propia versión de Chaos Monkey; y Amazon, están Cover Flow, IBM o Yahoo, por ejemplo, ya que publicaron artículos en sus blogs técnicos comentando que estaban empezando a usar la herramienta. También algunas otras marcas como Nike, que tiene una división tecnológica, aunque no sea lo que le viene a uno a la cabeza cuando piensa en Chaos Monkey.
Creo que debería utilizarse de manera constante en producción, es decir, con una cierta frecuencia. No que se haga una vez y se deje de hacer, sino que se vaya incrementando la frecuencia hasta que llegue un punto en que se esté más o menos satisfecho. Eso sí, hay que tener cuidado al implantarla, ya que al principio será un poco catastrófico, y tendrás algún fallo que afectará a la producción. Con el tiempo la cosa se irá estabilizando, tu sistema habrá ido mejorando mucho si has ido aprendiendo de tus fallos y al final podrás usarlo de manera constante. Además, como Netflix decía en la introducción a esta herramienta: “Nunca sabes si algún cambio que hayas hecho ayer ha provocado que tu plataforma sea más débil”. Siempre hay nuevos cambios, los desarrolladores asumen nuevas funcionalidades y puede ser que alguien haya entrado a hacer un arreglo en un momento determinado y tenga unas consecuencias que no te esperas.
Personalmente considero que es el futuro. La garantía de calidad del código que da el código abierto y especialmente además si es free software, con capacidad no solamente para poder ver el código sino poder modificarlo, amplificarlo o adaptarlo, hace que esa calidad sea algo que no puedes alcanzar en software propietario. De hecho, el software que utilizan las grandes compañías, el que utiliza Netflix, el que utiliza Google, todo en lo que se basan y toda esta tecnología sobre la que se apoya internet, está basada en herramientas de software libre, por lo que estoy completamente convencido de esto.
¿Te interesan las APIs financieras? Descubre todas las que te ofrece BBVA
Las fintech son plataformas financieras que democratizan las finanzas, así como el ecosistema, tecnología y empresas en las que se apoyan Las fintech son la siguiente iteración del mundo financiero. ¿En qué consisten estas plataformas financieras y de qué tipos existen? En España, las empresas fintech están creando un mercado maduro y en crecimiento gracias […]
Los brókers son herramientas que permiten la participación activa en los mercados financieros, así como las personas que ejecutan estas órdenes. De un modo u otro, los bróker llevan más de medio milenio con nosotros. Aunque hoy se los conoce como plataformas bróker de inversión en la que es posible desde manejarlos a nivel usuario […]
2020 fue el año en que la industria fintech se consolidó en España, con un crecimiento del sector del +15 % anual
