¡Es la época más espeluznante del año! Puede que pienses que lo espeluznante y la tecnología no están relacionados, pero te equivocarías. Bueno, en realidad, probablemente tengas razón, pero no debemos analizar sobre la importancia de la lógica de limpieza de TestContainers.

Los zombis en las películas dan miedo, pero (spoiler) no existen. Lo mismo ocurre con los vampiros.

Pero en el mundo de la tecnología, estos monstruos sí existen. Y son bastante malos. Tal vez no tan malos como para arrancarte la cabeza, pero definitivamente lo suficientemente malos como para que valga la pena exorcizarlos.

Código de vampiro

Empecemos hablando del código. Como desarrolladores, trabajamos muy, muy duro para crear código. Muchos de nosotros asumimos que el código debe ser un activo. No lo es.

El código es un pasivo. Cada bit de código que producimos necesita mantenimiento. El código aumenta la superficie de ataque de las aplicaciones, crea una carga cognitiva para los desarrolladores y ralentiza la compilación. ¡Uf! ¿Quién querría código?

Martijn Verburg dijo una vez que pagaba a sus desarrolladores junior por la cantidad de código que escribían y a sus desarrolladores senior por la cantidad de código que borraban. A veces, la gente compara trabajar con un LLM con programar en pareja con un desarrollador junior muy entusiasta. El modelo se entusiasmará con tu solicitud y producirá la mayor cantidad de código posible. Sospecho que algo en las matemáticas de cómo se entrenan estos modelos los inclina hacia la verbosidad. Esto pudimos verlo al generar una aplicación Quarkus y el 70% del código generado era innecesario. Las bibliotecas Hibernate con Panache eliminan la necesidad de código repetitivo, pero el asistente de IA puso todo el código repetitivo de todos modos.

El análisis estadístico de las bases de código parece confirmarlo. Un estudio de GitClear descubrió que las bases de código actuales tienen más código duplicado que antes de que los desarrolladores comenzaran a usar herramientas como CoPilot y ChatGPT. También encontraron una reducción en la cantidad de confirmaciones que eliminaban código. Como desarrolladores, pasamos mucho más tiempo leyendo código que escribiéndolo, por lo que este exceso de código se convierte en una pérdida constante de tiempo del desarrollador.

El código puede ser código vampiro incluso cuando realmente se necesita en la base de código. Todas las bibliotecas, excepto las más pequeñas, suelen incluir archivos y funciones que una aplicación de consumidor en particular podría no usar. Aunque no se usen, estos fragmentos de código inactivos aún tienen un costo. Aumentan el tamaño de la aplicación empaquetada, lo que significa un mayor tráfico de red para los usuarios. Esto es especialmente malo para las bibliotecas de Javascript, que se descargarán cada vez que se cargue una página web. La hinchazón del código no solo hace que la carga de la página sea más lenta, sino que también consume energía.

El código adicional también puede significar un mayor consumo de memoria; por ejemplo, el entorno de ejecución de Java cargará clases de soporte de base de datos no utilizadas en la memoria como parte del proceso de arranque de Hibernate. Las clases se descargarán, pero para entonces ya será demasiado tarde; el requisito de memoria máxima se ha establecido alto.

El código adicional puede incluso ralentizar las aplicaciones. Por ejemplo, en Java, el proceso de invocar un método de interfaz en un objeto es más lento si existen múltiples implementaciones posibles en la ruta de clases. Si la JVM tiene que elegir entre varias implementaciones, se denomina despacho megamórfico. Es más lento que el caso de una sola implementación, el despacho monomórfico.

La buena noticia es que existe una solución. Para Javascript, donde el código adicional tiene un impacto negativo tan obvio, la mayoría de las herramientas de compilación modernas realizarán un proceso llamado tree-shaking, que elimina el código no utilizado. Históricamente, Java no tenía un proceso similar, pero eso ahora está cambiando. Por ejemplo, la creación de un binario nativo de GraalVM eliminará agresivamente el código no utilizado. El proyecto Leyden también puede tener algunas ideas de tree-shaking para la propia JVM.

A un nivel por encima del tiempo de ejecución, la arquitectura Quarkus está diseñada para reducir el código vampiro. Quarkus aplica una serie de optimizaciones en tiempo de compilación a las aplicaciones, y las bibliotecas pueden participar en este proceso de optimización a través de extensiones.
Por ejemplo, ¿todas esas clases de soporte de bases de datos no muertas en Hibernate? La extensión Hibernate de Quarkus se asegura de que nunca lleguen a la aplicación compilada. Piense en la arquitectura de compilación de Quarkus como una estaca de madera extensible.

 

Servidores zombis

El código vampiro se produce cuando una parte del código base de una aplicación no se necesita. Los zombis se producen cuando no se necesita toda la aplicación. Por extensión, no solo la aplicación desperdicia recursos, sino también toda la infraestructura que la ejecuta.

¿Cómo es posible que una aplicación entera no se utilice? Normalmente, la causa principal es el olvido: olvido individual y también olvido organizacional. Puede ser que algo se haya utilizado bien en un principio, pero luego los procesos cambiaron. O tal vez se puso un prototipo en fase de prueba y nunca pasó a producción, pero tampoco se desmanteló.

El exceso de aprovisionamiento también causa zombis. Las estructuras de incentivos organizacionales fomentan el exceso de aprovisionamiento, porque nadie quiere ser la persona que aprovisionó muy poca infraestructura y provocó una interrupción. Para evitar esta situación que limita la carrera, muchas personas pecarán de cautelosas y configurarán demasiada capacidad.

¿Qué tan grave es la amenaza zombi? Es grave.

La investigación de NRDC concluyó que el servidor promedio funcionaba al 12-18% de su capacidad máxima. Eso no sería terrible, excepto que una máquina que funciona con tan bajo nivel de utilización aún utiliza entre el 30 y el 60 % de su potencia máxima. (Esta relación se llama “proporcionalidad energética”, si desea utilizar los términos técnicos). Las cosas son aún más desproporcionadas cuando analizamos el hardware. Construir un servidor sin uso emite exactamente la misma cantidad de carbono y consume la misma cantidad de recursos naturales que construir un servidor bien utilizado. El costo para nosotros y para el planeta es el mismo, pero el valor es mucho menor.

Una encuesta de 2017 descubrió que, durante un período de seis meses, el 29 % de los servidores tenían una utilización inferior al 5 %. Una cuarta parte de los servidores no tenían ninguna utilización; estaban completamente sin uso.

Esa cuarta parte es el promedio de una muestra grande e incluía varias empresas diferentes. En algunas organizaciones desafortunadas, la proporción de zombis puede ser mayor. Mucho, mucho mayor. Building Green Software comparte la historia de un centro de datos de VMWare en Singapur. El centro de datos se estaba trasladando físicamente, por lo que antes de realizar el traslado, el equipo verificó qué se estaba ejecutando en las máquinas. Increíblemente, el 66 % de todas las máquinas host eran zombis. Se trata de un escenario totalmente propio de Veintiocho días después, en el que los zombis superan en número a las máquinas que crean valor.

La búsqueda de servidores zombis no es trivial; por definición, los servidores olvidados son difíciles de encontrar. La razón por la que VMWare los descubrió fue porque el traslado físico obligó a una limpieza virtual. De lo contrario, ¿quién sabe cuánto tiempo podrían haber estado ahí los servidores inútiles? Las auditorías periódicas de un patrimonio pueden ayudar, pero, lamentablemente, son bastante aburridas de ejecutar. Como alternativa más gratificante desde el punto de vista intelectual, considere la posibilidad de implementar una solución de escalado elástico o incluso una optimización de recursos autónoma completa. La infraestructura como código puede ayudar a que sea más fácil controlar lo que se está ejecutando, y el arrendamiento efímero puede ayudar a acelerar el lanzamiento de sistemas que en realidad ya no se necesitan.

El código vampiro y los servidores zombi son, fundamentalmente, un desperdicio. Consumen recursos y no tienen ningún valor. Ese desperdicio nos cuesta dinero, pero también amenaza al planeta. ¿Por qué no organizar algunas expediciones de trick-or-treat para dar caza a esos servidores infrautilizados y esas líneas de código inútiles?