El SCI por sus siglas en inglés (Software Carbon Intensity) 

Es una medida creada por la GSF (Green software foundation) para poder comparar las emisiones de carbono generadas por nuestra aplicación. No se trata de un valor absoluto sino más bien un valor que nos permite comparar la eficiencia energética de nuestra aplicación según los cambios que vayamos realizando. Tampoco es una medida diseñada para comparar distintas aplicaciones sino para permitirnos ver las variaciones en la eficiencia energética de nuestra aplicación según los cambios que realicemos.  

Vamos a ver la fórmula usada para el cálculo de SCI y su significado: 

SCI = (E * I) + M per R 

 

Donde: 

E : Consumo de energía en kilovatios hora. 

I : Factor de emisión. Es un valor regional y que depende de mix energético de cada región. Se suelen usar valores anuales. Aunque idealmente se deberían usar los valores actuales (durante el cálculo del SCI) 

M : Emisiones generadas en la construcción / destrucción de los equipos. 

R : CO2e emitido por unidad funcional.  

 

Ninguno de estos valores es sencillo de obtener y sus valores dependerán mucho de los criterios que usemos para calcularlos. Veamos cada uno de ellos con un poco más de detalle. 

 E La forma más sencilla y directa de calcular este valor sería tener nuestra aplicación en un servidor y entre este y la toma de corriente un medidor de energia. Evidentemente este caso no suele ser el habitual así que normalmente tendremos que recurrir a estimaciones basadas en el uso de CPU, GPU memoria y almacenamiento.  

I Para el cálculo del factor de emisión podremos usar API´s de terceros (generalmente de pago) que nos ofrecen estos valores o bien usar los datos publicados por alguna entidades como: 

https://ourworldindata.org/grapher/carbon-intensity-electricity 

https://carbonintensity.org.uk 

https://www.ree.es/es/datos/generacion/no-renovables-detalle-emisiones-CO2 

M para el cálculo de las emisiones generadas por los equipos existen algunos fabricantes que publican estos datos como dell (https://www.dell.com/en-us/dt/corporate/social-impact/advancing-sustainability/climate-action/product-carbon-footprints.htm#tab0=0) o Apple (https://www.apple.com/environment/pdf/products/iphone/iPhone_14_PER_Sept2022.pdf).  

Para las máquinas en la nube de distintos proveedores podemos hacer uso de los datos publicados AQUÍ: https://docs.google.com/spreadsheets/d/1k-6JtneEu4E9pXQ9QMCXAfyntNJl8MnV2YzO4aKHh-0/edit#gid=0 Además para la obtención de este dato debemos tener en cuenta el tiempo de uso que hagamos de la máquina y si esta estará compartida por otras aplicaciones. 

R : La unidad funcional es un valor que debemos elegir y dependerá de nuestra aplicación, pueden ser por ejemplo el número de usuarios de nuestra aplicación por hora, el número de peticiones a nuestro api, el tiempo que tarda en ejecutarse un procedimiento determinado.. etc. 

 

En cualquier caso a la hora de calcular el SCI debemos especificar como  se ha calculado cada uno de estos valores. 

Existen algunas herramientas que nos permiten calcular o facilitan el calculo del SCI como Green Metrics Tool  https://docs.green-coding.berlin que nos permite calcular el SCI de aplicaciones contenerizadas. 

   

¿Cómo mejorar el valor de nuestro SCI?  

Se puede mejorar el valor del SCI mejorando cualquier de los valores de la fórmula.  Si nuestra aplicación esta diseñada para trabajar en la nube posiblemente la forma más sencilla sea moverla a una región donde el factor de emisión (I) sea menor.  

Otra forma podría ser mejorar los algoritmos usados para que usen menos tiempo y/o uso del procesador consumo de energía (E). En el caso de una aplicación web reduciendo el tamaño de las imágenes, haciendo uso de la cache del navegador evitaremos llamadas innecesarias y por lo tanto tiempo de procesamiento, uso de red .. etc lo que reducirá la energía consumida y seguramente el coste de la infraestructura.  En general cualquier optimización de la aplicación repercutirá positivamente en el valor del SCI ya que bajará el valor de E y de unidad funcional (R).  

Por último, aunque no tengamos control sobre el carbono emito al fabricar los equipos podriamos mover nuestra aplicación a máquinas con menor emisiones generadas (M), aun que este punto, sobre todo en instalaciones on-premise, suele ser complicado y normalmente una vez comprados los equipos no compensa cambiarlos ni económicamente ni por el impacto de la huella de carbono generada. 

 

Oscar Blanco
Senior Software Engineer at ilitia Technologies

Las empresas Best Workplaces son un reflejo de la experiencia que defiende Great Place To Work para cada empleado y empleada en cada compañía. Great Place To Work significa sentir tu trabajo como algo más que un trabajo, confiar en tus líderes y compañeros y compañeras de equipo, ponerte en la piel de otra persona, encontrar un lugar al que perteneces, ser tratado/a equitativamente… Great Place To Work quiere un gran lugar para trabajar para todas las personas.

El pasado martes 10 de junio tuvo lugar en la sede del grupo Vocento y ABC, la entrega de los premios del ranking Best Workplaces del sector tecnológico en 2024.

Y nos llena de orgullo haber conseguido… ¡la primera posicion de este prestigioso ranking! (categoría de hasta 50 empleados/a).

 

Queremos agradecer a GPTW la entrega de este premio y felicitar a todas las empresas del sector tecnológico que han sido reconocidas en este ranking.

Puedes consultar aquí todos los detalles del ranking Best Workplaces en Tecnología 2024.

Y referencias en prensa, como esta en ABC: Las firmas tecnológicas que llevan el cuidado del talento al siguiente nivel.

 

El Global Azure es un evento anual centrado en la plataforma de nube Microsoft Azure. Reúne a entusiastas de todo el mundo para compartir conocimientos y experiencias sobre temas como inteligencia artificial, datos, infraestructura, desarrollo de aplicaciones y más. Durante el evento, se ofrecen sesiones en directo donde los asistentes pueden disfrutar de charlas de ponentes y sesiones de networking.

Por otra parte, la Netcoreconf es un evento tambien anual dedicado al desarrollo de software y las tecnologías Microsoft relacionadas. Reúne a profesionales de todo el mundo para conocer las últimas novedades en NetCore, Azure, Xamarin, IA y Big Data, donde además gracias al networking se crean vínculos entre expertos, empresas e instituciones.

Siguendo nuestra tradición desde hace varios años, hemos vuelto a ser sponsors de estos dos eventos clave de la comunidad de desarrolladores .Net y Azure cloud, respectivamente.

La Global Azure 2024 tuvo lugar en Barcelona el viernes 19 de abril 2024 y en Zaragoza y Madrid, simultáneamente el sábado, 20 de abril 2024.

La Netcoreconf 2024 se celebró en Barcelona el sábado 23 de abril 2024, y se realizará en Madrid el viernes 15 de Noviembre 2024. ¡Allí estaremos!

Great Place To Work® es un reconocimiento en el ámbito de la gestión de personas y estrategia de negocio más prestigioso en el ámbito nacional e internacional, que se otorga anualmente a los mejores empleadores del mundo.

¡Estamos muy orgullosos de ser una empresa certificada como Great Place to Work!

Y sobre todo de los datos de la evaluación realizada por Great Place To Work®:

• 100% de las personas opina que este es un excelente lugar para trabajar
• 100% de las personas afirma que puede ser él/ella mismo/a en su lugar de trabajo
• 100% de las personas afirma que se celebran los acontecimientos especiales
• 100% de las personas afirma que cuando te incorporas a la empresa, te sientes bien acogido/a

No podríamos estar más orgullosos de nuestro equipo: En ilitia damos la prioridad #1 a las personas.

Mira lo que dicen nuestros empleados que hace que trabajar aquí sea tan bueno en nuestro perfil de empresa como Great Place to Work Certified company.

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