Imagen: Jay Yuno/Getty

Las aplicaciones nativas de la nube ya no son los monolitos de antaño, encajan perfectamente en categorías de cliente-servidor o de tres niveles. Ahora son un conglomerado de servicios, que combinan su código y las herramientas de la plataforma, diseñados para administrar y controlar errores y escalar globalmente.

Es maravilloso para nuestros usuarios: obtienen aplicaciones rápidas y con capacidad de respuesta, a las que pueden acceder desde cualquier lugar y en cualquier dispositivo. Pero eso dificulta las cosas para los desarrolladores y los equipos de operaciones, con redes complejas de servicios que son difíciles de probar a escala. Podemos diseñar para fallas, creando redundancia en nuestros sistemas, pero eso agrega complejidad a las arquitecturas, con nuevos servidores e instancias de servicio adicionales.

VER: Glosario rápido: DevOps (Premium de TechRepublic)

Índice

Probar sistemas complejos haciéndolos fallar

Más complejidad requiere más pruebas, y eso puede ser un problema cuando estamos probando lo que sucede cuando un servicio falla bajo carga. ¿Cómo fallan las transacciones cuando un backend de carrito de compras necesita cambiar de base de datos en medio de una compra? ¿Cómo reaccionará un rastreador de entregas de restaurantes si su plataforma de mensajería principal no funciona?

Necesitamos un modelo de prueba que examine los sistemas en ejecución y luego comience a fallar en los elementos, lo que nos permite rastrear los comportamientos del sistema. La idea es inyectar pequeños elementos de falla en los sistemas en funcionamiento, monitoreando su reacción frente a un conjunto de condiciones objetivo. Es una técnica conocida como ingeniería del caos, pionera en Netflix con su herramienta Chaos Monkey que afectaba aleatoriamente las operaciones, con el objetivo de descubrir modos de falla que no se tuvieron en cuenta y para los cuales los equipos de DevOps no estaban preparados.

La intención de las técnicas de ingeniería del caos no es explorar cómo fallan los sistemas, aunque eso puede ser un efecto secundario beneficioso; en cambio, su objetivo es mostrar cuán resistentes son. Netflix necesitaba ofrecer una experiencia de cliente sólida en todo momento, asegurando que los usuarios vieran sus películas y programas sin importar lo que sucediera en segundo plano.

No es sorprendente que estas técnicas hayan sido adoptadas por otras plataformas, especialmente proveedores de nube a hiperescala como Microsoft Azure. Si sus aplicaciones se ejecutan en Azure, quiere estar seguro de que incluso si un servidor de Microsoft deja de funcionar, su aplicación seguirá ejecutándose. El equipo de Chaos Engineering de Microsoft explora regularmente el impacto de las fallas en la plataforma, con el objetivo de garantizar que los servicios de los que dependen sus aplicaciones manejen las fallas correctamente.

Construye tu propio caos

Pero, ¿puede usar las mismas técnicas en sus propias aplicaciones, asegurándose de que su código sea tan resistente como los servicios que usa? No hay razón para no hacerlo. Si bien Microsoft puede tener sus propios equipos de ingenieros de confiabilidad del sitio responsables de mantener Azure operativo, una vez que su código se ejecuta a escala, necesita sus propios SRE, que conocen tanto su software como los servicios que lo utilizan.

Si está trabajando a escala, deberá implementar algún tipo de ingeniería del caos para garantizar que sus aplicaciones sean resistentes. Microsoft brinda orientación sobre cómo pensar en el uso de estas técnicas como parte de su documentación de Azure, con gran parte de su pensamiento derivado de la experiencia de Netflix. El caos, dice, es un proceso.

No es sorprendente. Podemos pensar que el caos es aleatorio, pero cuando lo usamos para probar la resiliencia, debe planificarse, tratándolo como seguridad. El modelo de Microsoft habla en términos de atacantes y defensores. Los atacantes son un lado de la ecuación, inyectando fallas en un sistema con el objetivo de romperlo. Por otro lado, los defensores evalúan los efectos de los ataques, analizan los resultados y planifican medidas de mitigación.

Las pruebas deben tratarse como experimentos científicos. Debe comenzar con una suposición, algo así como "la aplicación seguirá funcionando si pierde una sola instancia de base de datos de back-end". Esto luego define el error que se inyecta, aquí deteniendo una base de datos en una aplicación en ejecución. Finalmente, tiene un resultado esperado: la aplicación continúa ejecutándose. Su plataforma de ingeniería del caos debe administrar las tres etapas, proporcionando una forma de iniciar y detener las pruebas y acceder a los resultados de las pruebas.

VER: La ingeniería del caos de seguridad lo ayuda a encontrar eslabones débiles en sus defensas cibernéticas antes de que lo hagan los atacantes (República Tecnológica)

Un aspecto importante de los controles de caos es recordar que los controles tienen un radio de explosión. Son deliberadamente destructivos, por lo que debe tener en cuenta que pueden salir mal. Esto significa poder desconectar una prueba en cualquier momento, volviendo al funcionamiento normal lo más rápido posible. Cualquier inyección de caos requiere una forma de retroceder, preferiblemente con un solo botón para automatizar todo el proceso.

Las herramientas de terceros para Azure DevOps muestran que vale la pena usar estas técnicas al probar sus aplicaciones. Las herramientas de Proofdock unen la turbulencia de la ingeniería del caos con conceptos de desarrollo modernos, trabajando con herramientas de observabilidad para proporcionar lo que ellos llaman "verificación continua", ejecutando todo dentro de un portal familiar.

Presentación de Azure Chaos Studio

Actualmente, Microsoft está realizando una vista previa de un conjunto de herramientas de ingeniería del caos para aplicaciones de Azure con clientes seleccionados, en función de sus propias herramientas internas. Demostrado por el CTO de Azure, Mark Russinovich, durante Spring Virtual Ignite de Microsoft, es una combinación de un portal de administración de pruebas de Azure y un lenguaje de secuencias de comandos de prueba basado en JSON.

Las pruebas de Azure Chaos Studio tienen dos elementos: un agente que se ejecuta en sus servidores virtuales o incrustado en su código, y acceso directo a los propios servicios de Azure. Estos están controlados por descripciones de experimentos JSON, como probar la conmutación por error de back-end de Cosmos DB de una aplicación mediante la simulación de una falla en una de las regiones de una aplicación. Como alternativa, un experimento podría usar un agente para cerrar un host de servicio en un servidor que ejecuta una aplicación node.js o código .NET, probando la resiliencia en su propia aplicación.

Las experiencias se componen de una serie de pasos, cada uno de los cuales tiene acciones. Microsoft ha desarrollado un lenguaje declarativo específico de dominio para trabajar con marcos de aplicaciones, que comparte cierta similitud con su lenguaje de descripción de recursos Bicep. Podrá crear experimentos en Visual Studio Code y guardarlos en Azure, donde se enumeran en el portal de Chaos Studio. Desde el portal, comience seleccionando los experimentos que desea ejecutar usando otros elementos de las herramientas de desarrollo de Azure para monitorear las operaciones de la aplicación, ya sea mediante el monitoreo de aplicaciones integrado en su código o las propias herramientas de servicio de Azure.

Si usa Azure DevOps u otra herramienta de integración continua/desarrollo continuo, como GitHub Actions, Azure Chaos Studio proporciona una API REST para que pueda usarla como parte de un conjunto de pruebas de integración cuando crea una nueva versión de su código. Ejecutar Chaos Studio al principio del ciclo de vida de la aplicación tiene sentido, ya que le permite incorporar pruebas de resiliencia en su proceso de lanzamiento.

A medida que madura el desarrollo nativo de la nube, la forma en que creamos aplicaciones se está convirtiendo cada vez más en la forma en que las principales plataformas y servicios en la nube crean su código. Las técnicas que antes solo necesitaban empresas como Netflix o Azure ahora las necesita todo el mundo, y la llegada de Chaos Studio a Azure está contribuyendo en gran medida a transformar lo que antes era una herramienta personalizada en una plataforma que puede ser utilizada por todos. cumpliendo la promesa de sistemas resilientes.