Una de las reglas fundamentales que permiten que DevOps funcione bien para entregar software es «probar pronto y probar a menudo». De hecho, una parte del ámbito de CI/CD (integración continua/entrega continua) consiste en generar compilaciones y realizar pruebas automatizadas de dichas compilaciones. No solo de componentes individuales, sino de toda la aplicación.
El desarrollo guiado por pruebas (TDD) es uno de los métodos; otro consiste simplemente en integrar las pruebas unitarias y del sistema en el propio proceso de compilación y publicación. Las pruebas funcionales y de regresión son imprescindibles y, en entornos muy ágiles, suelen activarse con un simple «commit» en el repositorio.
Por tanto, cabría esperar que, para cuando el software se «entregue» a los responsables de su despliegue en producción, exista un alto grado de confianza en que está listo.
Claro que, si así fuera, no estaría escribiendo esta entrada, ¿verdad?
El muro que hay que franquear para llevar el software a producción (y no nos engañemos, ese muro sigue existiendo) es donde a menudo incurrimos en lo que en filosofía se conoce como la «falacia de composición». Esta falacia lógica suele aplicarse a argumentos y demostraciones, pero, curiosamente, el software sirve de base para una sencilla explicación de este «mal argumento» que ofrece el autor Ali Almossawi en El libro de los malos argumentos (que recomiendo encarecidamente a aspirantes a filósofos y 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 se ha sometido a una serie de pruebas unitarias y las ha superado todas. Por lo tanto, cuando se integren los módulos, el sistema de software no vulnerará ninguna de las invariantes verificadas mediante dichas pruebas unitarias. La realidad es que la integración de componentes individuales introduce nuevas complejidades en un sistema debido a dependencias que, a su vez, pueden generar otras posibles vías de fallo. -- https://bookofbadarguments.com/ p. 46
Ahora, en la etapa final del proceso de CI/CD, el software no tiene por qué incurrir en esta falacia. No solo se ha sometido a pruebas unitarias, sino también a pruebas de integración de esas unidades para formar un «sistema» o una aplicación completos.
Sin embargo, una vez que llega a producción, volvemos a la casilla tres. No podemos dar por sentado, basándonos en esas pruebas, que el sistema seguirá funcionando según lo previsto. Esto se debe a que la definición de la aplicación acaba de cambiar para abarcar no solo su software y sus plataformas, sino también los componentes de red y de servicios de aplicaciones necesarios para ponerla en marcha, por así decirlo, y hacerla llegar a las pantallas de consumidores y usuarios empresariales deseosos de utilizarla.
La red y los servicios de aplicaciones afectan a la ruta de datos que deben recorrer las solicitudes y las respuestas. Muchos de esos servicios, aunque no todos, pueden modificar dichas solicitudes y respuestas de formas que los desarrolladores no habían previsto. Por tanto, es posible (y, a menudo, probable) que, una vez en el entorno de producción —aunque cada servicio y componente de la aplicación se haya probado rigurosamente de forma individual—, la aplicación sufra un fallo. Un error. Que se equivoque.
Esto se debe a que hemos caído en la falacia de composición en el entorno de producción. Aunque los desarrolladores de aplicaciones (y los equipos de DevOps) comprenden esta falacia y la abordan en las pruebas de preproducción, a menudo seguimos sin reconocer que la integración en la capa de red no deja de ser una integración y que, de hecho, puede afectar a la integridad operativa del conjunto.
La respuesta parece obvia: bueno, ¡pues haremos las pruebas directamente en producción!
Pero no lo haremos, y tanto tú como yo sabemos que no lo haremos. Porque producción es un entorno compartido, y realizar pruebas rigurosas en él aumenta el riesgo de causar daños colaterales a los recursos y sistemas compartidos, lo que puede provocar interrupciones del servicio. Estas interrupciones reducen los beneficios y la productividad, y nadie quiere asumir la responsabilidad. Es mucho más fácil realizar en producción las pruebas individuales que sean posibles y, más adelante, culpar a los desarrolladores cuando algo se estropee o no funcione como se había anunciado.
En última instancia, este es uno de los motores silenciosos de la revolución del software que está transformando las redes de producción. Antiguamente, replicar y mantener un entorno de pruebas que reprodujera fielmente el entorno de producción era demasiado difícil y costoso. Parte de esa infraestructura compartida es cara y ocupa mucho espacio. Duplicar esa red no resulta sensato ni desde el punto de vista financiero ni desde el operativo.
Sin embargo, la introducción y posterior adopción del software gracias a la computación en la nube y la virtualización han empezado a poner de relieve que replicar redes basadas en software no solo resulta asequible, sino también más sencillo gracias a conceptos como la infraestructura como código. Además, es posible replicarlas, realizar pruebas en ellas y desmantelarlas, lo que permite reutilizar los recursos para hacer lo mismo con otras aplicaciones.
Aún no hemos llegado a ese punto, pero cada vez estamos más cerca. La integración de servicios virtuales (basados en software) de red y de aplicaciones en el proceso de CI/CD es, en realidad, mucho más tangible de lo que algunos podrían pensar. Los servicios tradicionalmente basados en la infraestructura (de red) —equilibrio de carga, enrutamiento de aplicaciones y seguridad de aplicaciones web— se están integrando en gran medida en el ciclo de desarrollo del software gracias a su incorporación en entornos como las arquitecturas basadas en contenedores. Al tratarse de soluciones basadas en software, pueden incluirse al menos en la fase de pruebas del proceso de compilación, lo que aumenta la confianza en que el despliegue en producción no introducirá fallos ni errores.
Partiendo de ese software, la aplicación de la «infraestructura como código» va aún más allá. Cuando las políticas y configuraciones pueden diseñarse y perfeccionarse durante los ciclos de compilación y lanzamiento, y después implementarse en producción con pocos o ningún cambio, estamos sin duda más cerca de eliminar las falacias de composición que existen en producción.
Cuanto más se integren estos servicios —los más centrados en las aplicaciones de entre todos los servicios de aplicaciones— en la fase de pruebas de CI/CD, mayor será la confianza de todos en que el despliegue en producción se realizará correctamente.
Porque la otra falacia que existe hoy en día es que realizar pruebas en «producción» significa hacerlo en «sistemas de producción». A menudo, estas pruebas no incluyen los servicios de aplicaciones que conforman la ruta de datos en producción. Es necesario que los incluyan para que podamos reducir los errores a aquellos realmente difíciles de detectar y disponer de tiempo y recursos para solucionarlos.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.