PASADO EN CLARO: LA PRUEBA DE APLICACIONES NATIVAS DE LA NUBE

Recientemente platicaba con un amigo que no abandonó la industria del software que tengo la impresión que entre las compañías de desarrollo mexicanas no existe aún una arquitectura nativa de la nube que permita responder de forma rápida y consistente a la demanda de los clientes, realineando la aplicación a las necesidades comerciales y de negocio; eso sigue siendo mítico, el “speech comercial” para vender. También que desde mi cercanía por haber sido desarrollador y con la distancia que la ciberseguridad concede no veo que los equipos de desarrollo de software sean los grandes expertos en la automatización, ni siquiera en la mejora de procesos, tampoco en la seguridad de su aplicación. Mi visión por supuesto es limitada pero conozco ese mundo desde el hueso y toda la atención está centrada en liberar el código, entrar a pruebas y salir producción, quien me diga que no… sin duda es un experto visionario que nunca ha escrito un “Hello world”. 

Mi amigo reconocía que el desarrollo para nube nativa ha inaugurado nuevos reinos de problemas, fallas asociadas al código pero también a la propia infraestructura pero que a la par ha permitido que nuevas habilidades para su arreglo surjan entre los programadores o los perfiles asociados; los perfiles se están especializando pensando en nube. Pero le recordaba que el manejo de la complejidad siempre ha separado a los hombres de los niños, imagino que la fragmentación de servicios obliga a tener más control de los estados, rastrear componentes (faltantes o no) y detectar comportamiento extraños de la aplicación cuando las cargas se mueven o simplemente se ejecutan. El fantasma en la máquina es un temor constante aun hoy. En este contexto, convergíamos en que las pruebas se vuelven el punto fino en el proceso para no sólo comprobar funcionamiento, sino evaluar el despliegue, el rendimiento general, la compatibilidad, la escalabilidad, el acoplamiento, etc., etc.

Paradójicamente la batería de pruebas es la misma que yo conocí hace años… desde las pruebas de unidad, de componente, de construcción, hasta las de integración, pasando por las de punto a punto, para llegar a las (versiones) alfa y beta, sin olvidar el análisis de código estático y las pruebas dinámicas, sin embargo, en cuestiones de nube lo que cambia es el enfoque: 

Se debe probar la escalabilidad hacia abajo y hacia arriba para resistir la demanda variante garantizando el desempeño de cada parte del código y su empaquetamiento, sobre todo ante el aumento en las cargas o las peticiones de servicios. Sobre este último punto no se puede prescindir de verificar que la aplicación funciona y lo hace correctamente de acuerdo con las especificaciones definidas, incluso para servicios o microservicios la validación de entrada, la verificación de salida y la consistencia del procesamiento son cruciales. Por último, tenemos a la buena y vieja conocida resiliencia: las aplicaciones nativas deben tener una arquitectura de software ad hoc para sobrevivir a las fallas, se debe probar su habilidad para recuperarse ante caídas, errores, pero no sólo debidas al código sino de la infraestructura y supra estructura.

El objetivo sigue siendo el mismo: asegurar que una aplicación es funcional, escalable, resiliente y segura como para llevarla a producción sin desvelos, considerando que muchas aplicaciones no superan la prueba del ácido, algunas fallas o problemas son “inexplicables” y surgen en la implementación y operación es necesario usar nuevas formas de probar las aplicaciones nativas de la nube, una de la más interesantes es “inyectar caos”, es decir, entradas o comportamientos aleatorios e inconsistentes en condiciones controladas para ver cómo responderá el sistema. De esa manera, puede identificar posibles fallas antes de pasar a producción. También es útil implementar gradualmente de nuevas funcionalidades para un pequeño grupo de usuarios, le llaman despliegue canario pero en realidad es un despliegue “conejillo de indias” se busca identificar y corregir fallas antes de que la aplicación esté disponible para todos los usuarios.

El camino es largo y la fascinación constante, por supuesto nunca podré dejar por entero la otra vida, el desarrollo de software es al mismo tiempo trabajo de príncipes y ladrones, de lo más sublime a lo más bajo y en medio están los que prueban las aplicaciones. No se pueden separar, ya lo dijo Dijkstra: “Si la depuración es el arte de eliminar errores, entonces la programación debe ser el arte de introducirlos” o algo así…

Enrique López T.