Falacia de composición (por qué es tan difícil implementar en producción)
Una de las reglas fundamentales que hacen que DevOps funcione bien para entregar software es la de “probar temprano, probar con frecuencia”. De hecho, parte del dominio de CI/CD (Integración continua/Entrega continua) es el de las compilaciones y las pruebas automatizadas de esas compilaciones. No sólo de componentes individuales, sino de toda la aplicação.
El desarrollo impulsado por pruebas (TDD) es un método, otro es simplemente la integración de pruebas unitarias y del sistema como parte del proceso de compilación y lanzamiento en sí. Las pruebas funcionales y de regresión son imperativas y, en entornos altamente ágiles, a menudo se activan con una simple “confirmación” en el repositorio.
Por lo tanto, se esperaría que cuando el software sea “entregado” a las manos de los responsables de su implementación en producción, exista un alto grado de confianza en su preparación.
Por supuesto, si así fuera, no estaría escribiendo este post, ¿verdad?
El muro que atraviesa el software cuando se entrega a producción (y no nos equivoquemos, ese muro todavía existe) es donde a menudo nos topamos con lo que en filosofía se conoce como la “falacia de composición”. Esta falacia lógica se aplica generalmente a argumentos y pruebas, pero curiosamente es el software el que forma la base de una explicación simple de este “mal argumento” del autor Ali Almossawi en El libro de los malos argumentos (que recomiendo encarecidamente a los filósofos en ciernes/campeones del debate de todas las edades):
Falacia informal, suposición injustificada, composición y división
Cada módulo de este sistema de software ha sido sometido a un conjunto de pruebas unitarias y las ha superado todas. Por lo tanto, cuando los módulos están integrados, el sistema de software no violará ninguna de las invariantes verificadas por esas pruebas unitarias . La realidad es que la integración de partes individuales introduce nuevas complejidades a un sistema debido a dependencias que a su vez pueden introducir vías adicionales para posibles fallas. -- https://bookofbadarguments.com/ p.46
Ahora bien, en la etapa final del proceso CI/CD, el software no es necesariamente propenso a esta falacia. Ha sido sometido no sólo a pruebas unitarias, sino a pruebas de integración de esas unidades para formar un “sistema” o aplicação completo.
Sin embargo, una vez que entra en producción, volvemos al punto de partida. No podemos asumir que el sistema continuará funcionando como se espera en base a esas pruebas. Esto se debe a que la definición de la aplicação acaba de cambiar para abarcar no solo su software y plataformas, sino también los componentes de red y servicio de la aplicación necesarios para que la aplicación funcione, por así decirlo, y la entregue a las pantallas de consumidores ansiosos y usuarios corporativos.
Los servicios de red y aplicaciones impactan la ruta de datos que deben recorrer las solicitudes y las respuestas . De hecho, muchos de esos servicios, pero no todos, pueden modificar esas solicitudes y respuestas de maneras que los desarrolladores no anticiparon. Por lo tanto, es posible (y a menudo probable) que una vez en el entorno de producción, incluso si cada servicio y componente de la aplicación se ha probado rigurosamente, la aplicação experimente una falla. Un fracaso. Equivocarse.
Esto se debe a que hemos caído víctimas de la falacia de composición en el entorno de producción. Si bien los desarrolladores de aplicaciones (y DevOps) comprenden esta falacia y la abordan en las pruebas de preproducción, a menudo no reconocemos que la integración en la capa de red sigue siendo integración y, de hecho, puede afectar la integridad operativa del conjunto.
La respuesta parece obvia: bueno, ¡entonces haremos pruebas en producción!
Excepto que no lo haremos, y tú y yo sabemos que no lo haremos. Debido a que la producción es un entorno compartido, las pruebas rigurosas en un entorno de producción aumentan el riesgo de daños colaterales a los recursos y sistemas compartidos, lo que puede causar interrupciones. Las interrupciones del servicio implican menores ganancias y productividad, y nadie quiere ser responsable de eso. Es mucho más fácil realizar las pruebas individuales que son posibles en producción y luego señalar a los desarrolladores más tarde cuando algo falla o no funciona como se anuncia.
En definitiva, este es uno de los impulsores silenciosos de la revolución del software que está devorando las redes de producción. En épocas pasadas, era demasiado difícil y costoso replicar y mantener un entorno de prueba que coincidiera con el entorno de producción. Parte de esa infraestructura compartida es costosa y ocupa mucho espacio. Duplicar esa red no es inteligente ni desde el punto de vista financiero ni operativo.
Pero la introducción y posterior adopción de software gracias a la computación en la nube y la virtualización ha comenzado a poner de relieve la noción de que la replicación de redes basadas en software no sólo es asequible, sino también más sencilla gracias a conceptos como la infraestructura como código. No sólo eso, sino que puedes replicarlo, probarlo y desmantelarlo, lo que significa que los recursos pueden reutilizarse para hacer lo mismo para otras aplicações también.
Aún no hemos llegado, pero nos estamos acercando. La integración de servicios de aplicação y redes virtuales basadas en software en el flujo de trabajo de CI/CD es en realidad mucho más real de lo que algunos podrían pensar. Tradicionalmente, los servicios basados en infraestructura (red) (equilibrio de carga, enrutamiento de aplicaciones, seguridad de aplicaciones web) se están integrando altamente en el ciclo de creación de software gracias a su integración en entornos como arquitecturas basadas en contenedores. Como soluciones basadas en software, pueden incluirse al menos en la fase de prueba del proceso de construcción y así aumentar la confianza de que la implementación en producción no introducirá fallas ni errores.
Sobre la base de ese software, la aplicação de “ infraestructura como código ” lo lleva aún más lejos. Cuando las políticas y configuraciones se pueden diseñar y ajustar durante los ciclos de compilación y lanzamiento y luego implementar en producción con pocos o ningún cambio, definitivamente estamos más cerca de eliminar las falacias de composición que existen en la producción.
Cuanto más se integren estos servicios (los más centrados en las aplicaciones) en la fase de prueba de CI/CD, más confianza podrán tener todos en una implementación de producción exitosa.
Porque la otra falacia que existe hoy en día es que probar contra “producción” significa “sistemas de producción”. A menudo no incluye los servicios de aplicaciones que forman la ruta de datos en producción. Es necesario para que podamos reducir los errores a los realmente esotéricos y realmente tener tiempo y recursos para abordarlos.