Quinto y último post de nuestra serie dedicada al Green Software, en este caso orientado a cómo generar un código más eficiente.

Aprenda a optimizar y desconfíe de los robots

Como decíamos, cuanta menos memoria asigne nuestra aplicación y menos ciclos de computación conlleve la ejecución de nuestro código, menores emisiones de gases de efecto invernadero provocará nuestro software. Con esto en mente, decidimos idear una estrategia de optimización para uno de nuestros proyectos existentes.

La primera preguntar era obvia: ¿debíamos optimizar toda la aplicación? La respuesta es no. Cuando una aplicación lleva viva cierto tiempo, la cantidad de código que la compone puede ser considerable. Por eso, lo mejor es centrarse en los llamados hot spots: a menudo un conjunto muy pequeño de métodos son los que procesan la gran mayoría de las peticiones, y es en ellos donde deberíamos centrar nuestros esfuerzos.

La segunda pregunta era incómoda: ¿estás acostumbrado a optimizar código? Y la respuesta, en el caso de muchos programadores, también es no. Porque, no nos engañemos: hoy en día, la mayor parte de programadores somos en realidad consumidores de APIs, librerías y frameworks. Las estructuras de datos y los algoritmos no forman parte del día a día del programador medio, y hacer un código optimizado no es su prioridad: lo que debe hacer es sacar adelante historias de usuario utilizando el framework de moda.

Por tanto, si no estás acostumbrado a optimizar código, puedes empezar por echar un vistazo a recopilaciones de consejos de optimización como este, o puedes preguntar a ChatGPT. Sin embargo, ninguna de estas dos estrategias es infalible, por lo que, hagas lo que hagas, asegúrate de que de verdad estás mejorando el código haciendo mediciones con alguna herramienta de benchmarking.

En nuestras pruebas, usamos BenchmarkDotNet, una librería de código abierto para .NET que se encarga de todo el proceso de ejecución del benchmark, desde la ejecución del código hasta la presentación de los resultados, y proporciona diagnósticos detallados, como el tiempo de ejecución, el uso de memoria, las veces que se invoca el recolector de basura (GC), etc. Y no es un proyecto marginal: lo usa la propia Microsoft en sus desarrollos, .NET incluido.

Una de nuestras pruebas consistió en tomar código de una de nuestras aplicaciones, pedir a ChatGPT que nos ayudara a optimizarlo, y ejecutar la herramienta de benchmarking para comprobar si, efectivamente, la optimización era cierta. Sin entrar en detalles, estos fueron los primeros resultados:

Es decir, el método optimizado por ChatGPT era 6 veces más lento que el original, asignaba 464 B que no asignaba el original y, además, hacía una llamada al recolector de basura que no hacía el original.

Empleada de Ilitia al descubrir que ChatGPT también se equivoca

Aunque, tras varios prompts adicionales, conseguimos llegar a un método más optimizado, el fiasco anterior nos hizo más sabios, pues aprendimos que:

• ChatGPT puede ayudarnos a optimizar código, pero…
• ChatGPT no es la Panacea. A veces se equivoca, o no entiende el prompt que le hemos dado, y es necesario afinarlo.
• No podemos confiar a pies juntillas en sugerencias de ChatGPT ni en recopilaciones hechas por “expertos”. Lo mejor es hacer pruebas con una herramienta de benchmarking como BenchmarkDotNet. Una prueba vale más que mil suposiciones.

 

Aplicaciones web y viejas-nuevas buenas prácticas

Si te dedicas al desarrollo web y, como yo, recuerdas el ruido que hacía un módem de 56k al conectarse a internet, se pueden asumir dos cosas sobre ti: deberías tomar yogures de los que bajan el colesterol y sabes lo que es optimizar una página web para que cargue rápido. Y, pese a la llegada de las conexiones rápidas y los anchos de banda de hoy en día, es algo que no hemos dejado de lado del todo: con la irrupción de los dispositivos móviles y sus limitadas conexiones de datos tuvimos que desempolvar aquellos conocimientos y adaptarlos al nuevo entorno tecnológico.

Ilitio viejoven tomando fresas voladoras mientras optimiza una web escrita en Klingon

El caso es que, si bien en la actualidad las conexiones rápidas abundan, no debemos dejar de lado la optimización, pues, cuanto más pesa una web, más consumo eléctrico requiere transmitirla desde el servidor hasta nuestros dispositivos (con las consiguientes emisiones de gases de efecto invernadero).

Por eso, y con el fin de reducir nuestras emisiones el máximo posible, en Ilitia nos hemos propuesto recuperar aquellas buenas prácticas (¿recuperar? nunca las perdimos, ejem) para que en nuestros desarrollos sólo viajen los datos estrictamente necesarios entre clientes y servidores. Así, siguiendo las recomendaciones de la Green Software Foundation más nuestra propia experiencia, estamos repasando nuestras aplicaciones para asegurarnos, entre otras cosas, de:

Usar versiones recientes de software y librerías. Los desarrolladores de frameworks y librerías front-end importantes como Angular o Vue.js trabajan constantemente en la optimización de sus productos. Con cada nueva versión, se implementan mejoras no solo en el rendimiento, la velocidad y la eficiencia del código, sino también en la reducción, en la medida de lo posible, del tamaño de dichos frameworks y librerías.

Utilizar imágenes del tamaño adecuado. A menudo se usan imágenes más grandes (en píxeles) de lo que después se muestra en pantalla. Por norma, una imagen mayor en píxeles tendrá mayor peso en bytes, por lo que se recomienda que las imágenes no excedan por mucho el tamaño (en píxeles) que se vaya a mostrar en la pantalla. Cuanto menor sea el tamaño de la información transmitida por la red, menos energía será necesaria para transmitirla (y, por tanto, menos emisiones se producirán). Sirva como ejemplo la mejora que obtuvimos al reducir el tamaño del logo de una de nuestras aplicaciones:

Usar formatos de imágenes modernos y algoritmos de compresión de imágenes eficientes. Si bien, en general se recomienda utilizar formatos modernos, como WebP y AVIF, que permiten mayor compresión sin pérdida de calidad, nosotros hemos obtenido resultados muy notorios sometiendo las imágenes a algoritmos de compresión más eficientes, pero sin cambiar el formato. Existen numerosos servicios gratuitos que ofrecen compresión de imágenes. En nuestras pruebas hemos utilizado TinyPNG, que es un proyecto consolidado y respaldado por importantes compañías del sector:

https://tinypng.com/

Los resultados (muy significativos) de la compresión de las imágenes de uno de nuestros proyectos son los que siguen:

Activar la compresión GZip en nuestros servidores web, ya sean clásicos (IIS on premise) o modernos (nginx sobre Kubernetes).

Cachear tanto contenido como sea posible, ya sea información que viaje entre el servidor y los dispositivos en que se consumen nuestras aplicaciones, o entre el servidor y sus fuentes de datos.

De este modo, lo que antes se hacía meramente para mejorar la experiencia del usuario (evitando que la carga de una página conllevara prolongados tiempos de espera) ahora lo hacemos para evitar emisiones de gases de efecto invernadero.

José Ángel Fernández
Full-Stack Senior Software Engineer at ilitia Technologies

Edición: Jon Burguera

El cuarto post dedicado a la optimización de ejecución de procesos en los momentos más eficientes.

Hilando aún más fino: ¿cuándo ejecutar una tarea?

Hasta ahora hemos hablado de: borrar recursos que no usamos, desactivar los que tenemos cuando no estemos trabajando, e instalar los nuevos en las zonas menos contaminantes. Pero aún podemos hilar más fino, pues el mix energético varía dependiendo del momento del día:

• Normalmente, la producción solar es más abundante desde las 10 de la mañana hasta las 2 de la tarde.
• El patrón de vientos, por otro lado, varía según la región y la estación (por ejemplo, hay zonas en que los vientos son más fuertes debido a la variación térmica; en otras, las brisas diurnas (por ejemplo, las brisas marinas) pueden aumentar la producción eólica durante el día.

Tanto la producción solar como la eólica dependen, también, de las condiciones atmosféricas del momento, por lo que no siempre es fácil determinar el mejor momento para ejecutar una tarea pesada.

Cómo consultar el mix energético

Por suerte, existen APIs que ofrecen datos de producción y consumo de energía (¡bien!), de las cuales las más conocidas son, tal vez, WattTime y Electricity Maps. Por desgracia, estas fuentes de datos son de pago (¡mecachis!). Sin embargo, tras investigar qué fuentes de datos alimentan, a su vez, a estas APIs, pudimos comprobar que (al menos en el caso de Electricity Maps) agregan datos de fuentes que están disponibles de forma gratuita (¡bien!).

De las fuentes disponibles, en Ilitia hemos explorado la web API de ENTSO-E, la asociación europea de los gestores de transporte de electricidad. Utilizándola como fuente de datos, hemos logrado determinar los mejores momentos para ejecutar un job en los data centers de Azure de Europa.

Asimismo, hemos empezado a trabajar en un dashboard que nos permite estimar las emisiones de nuestra infraestructura cloud, cruzando los datos de generación de energía de ENTSO-E con los de consumos de Azure ofrecidos por Microsoft. Sabemos que existen iniciativas parecidas, pero en este caso nos aseguramos de que los datos de producción de electricidad son recientes.

¿Y la ejecución de software, qué?

Es verdad: hasta ahora nos hemos centrado en soluciones de infraestructura, pero hacer nuestro software más eficiente también puede ayudar a reducir nuestra huella de carbono. Grosso modo, menos ciclos de computación y menores asignaciones de memoria se traducen en menor consumo de electricidad y menor huella de carbono.

Asimismo, menor cantidad de datos navegando por la red también se traduce en menor consumo de electricidad.

Por tanto, debemos hacer un esfuerzo por escribir software eficiente que intercambie sólo los datos imprescindibles.

Empleados de Ilitia midiendo la eficiencia de su software.

Continuará… con medidas tangibles para realizar en el desarrollo del software.

José Ángel Fernández
Full-Stack Senior Software Engineer at ilitia Technologies

Edición: Jon Burguera

Reducción de emisiones en el sector IT

En el anterior post, ya hemos comentado una primera medida de reducción de emisiones prolongando la vida útil. Hoy vamos a hablar de medidas de reducción en la infraestructura cloud.

Apagar los equipos físicos y reducir consumos en la nube

Otra medida evidente cuando los equipos son físicos es apagarlos cuando no se estén utilizando. Sin embargo, cómo hacer esto cuando gran parte de la computación se hace hoy día en la nube no resulta tan obvio.

En nuestro caso, siendo Ilitia partner de Microsoft, nuestro proveedor de servicios en la nube es Azure. Por tanto, nuestra primera medida fue buscar y eliminar recursos en nuestras cuentas de Azure que fueran residuos de proyectos pasados, borrando así máquinas virtuales, cuentas de almacenamiento, bases de datos, jobs de IA, etc. que ya no se estaban utilizando.

Empleado de Ilitia borrando recursos de Azure.

A continuación, abordamos los recursos de proyectos en curso. Por desgracia, no todos los recursos de Azure se pueden apagar cuando no están en uso. Un tipo de recurso que se puede apagar, y que a veces se utiliza en los proyectos como cajón de sastre, son las máquinas virtuales. Éstas lo ponen fácil para apagarlas cuando no están en funcionamiento: el propio portal de Azure incluye un scheduler para tenerlas encendidas sólo a determinadas horas.

Kubernetes

Pero los tiempos cambian y las tendencias en IT también, y hoy en día las máquinas virtuales son casi cosa del pasado: ahora todo se instala en contenedores, donde el estándar de facto es Kubernetes. Aquí surge un problema, porque el portal de Azure no incluye ningún scheduler para sus Azure Kubernetes Services (AKS). Para solucionarlo, hemos aplicado dos vías:

• Cuando estamos fuera de horario de oficina, escalamos a cero las user workloads de los AKS mediante KEDA, que proporciona capacidades avanzadas de escalado automático en Kubernetes y que, entre otras opciones, permite escalar siguiendo un horario (mediante expresiones CRON).
• Además, mediante una automation account de Azure que ejecuta un script de PowerShell, hemos hecho que los propios clústers (AKS services) se paren fuera de las horas de oficina.

Dime dónde te instalas y te diré cuánto emites

Una vez hecha la poda de recursos obsoletos y la programación de apagados allá donde era posible, quedaba seguir refinando. Como sabemos, no todas las fuentes de energía que se usan para producir electricidad dejan la misma huella de carbono. Echemos un vistazo a la siguiente tabla:

Energy type	GCO2eKwh
Fossil Coal-derived gas	850
Fossil Hard coal	820
Fossil Gas	490
Fossil Oil shale	385
Fossil Peat	381
Fossil Brown coal / Lignite	332
Fossil Oil	249
Biomass	230
Waste	230
Solar	48
Geothermal	38
Hydro Run-of-river and poundage	24
Hydro Water Reservoir	24
Dispatchable hydro resource	24
Marine	17
Nuclear	12
Wind Offshore	12
Wind Onshore	11

Se puede observar la gran diferencia de emisiones entre las llamadas energías limpias (eólica, solar, geotérmica…) y las sucias (los combustibles fósiles). Sabiendo esto, convendrá instalar nuestros recursos en zonas en las que el mix de electricidad provenga en su mayor parte de energías limpias. Por ejemplo, en Ilitia, estamos priorizando los data centers de Azure que se encuentran en zonas en que la producción de electricidad deja una menor huella de carbono, por dar prioridad a fuentes de energía limpias.

Aquí tenemos una lista data centers de Azure de la UE (donde, por las leyes de protección de datos, nos conviene albergar nuestros recursos):

Id	MT per kWhour	Display Name
swedencentral	0.00000567	Sweden Central
francecentral	0.00005128	France Central
francesouth	0.00005128	France South
northeurope	0.0002786	North Europe
westeurope	0.0003284	West Europe
germanynorth	0.00033866	Germany North
germanywestcentral	0.00033866	Germany West Central
polandcentral	N/A	Poland Central

De acuerdo con lo anterior, en estos momentos estamos dando prioridad al data center de Sweden Central, por ser unas 9 veces menos contaminante que la segunda opción, Francia, y unas 60 veces menos contaminante que Alemania. De Polonia no hemos encontrado datos, pero sospechamos que se encuentra, al menos, a la par que Alemania en cuanto a emisiones, de acuerdo con lo devuelvo por la web API de ENTSO-E, de la que hablaremos a en próximos posts.

Continuará… con medidas tangibles para realizar en la ejecución del software.

José Ángel Fernández
Full-Stack Senior Software Engineer at ilitia Technologies

Edición: Jon Burguera