Software Carbon Intensity. Cómo medir las emisiones de nuestros desarrollos

/by

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

Green Metrics Tool: Mide y Reduce tu Huella de Carbono Digital

/by

En un mundo cada vez más consciente de la importancia de la sostenibilidad ambiental, la medición y reducción de la huella de carbono se ha convertido en una prioridad para muchas empresas y desarrolladores. Green Metrics Tool (GMT) es una herramienta de código abierto diseñada para medir la energía consumida y las emisiones de CO2eq generadas por aplicaciones software. En este artículo, exploraremos en detalle cómo GMT puede ayudarte a cuantificar y reducir el impacto ambiental de tus aplicaciones.

Green Metrics Tool es una primera aproximación práctica (desarrollada por el grupo de Green Coding Berlín) para llevar a la práctica la fórmula de Software Carbon Intensity de la Green Software Foundation

Contenarización con Docker Compose

Para empezar a utilizar GMT, debes contenerizar tu aplicación utilizando Docker Compose. GMT actualmente no es compatible con aplicaciones en Kubernetes. Una vez que hayas contenarizado tu aplicación, el siguiente paso es convertir tu archivo Docker Compose (compose.yml) en un archivo usage-scenario.yml. Este archivo es una extensión de la especificación de Docker Compose, aun que a su vez impone algunas restricciones.

Sin embargo, las claves que existen tanto en Docker Compose como en usage-scenario tienen el mismo significado en ambas especificaciones.

Estructura del archivo usage-scenario.yml

El archivo usage-scenario.yml se compone de cuatro bloques principales:

  1. Networks: Define las redes que se utilizarán.
  2. Services: Define los servicios de tu aplicación.
  3. Compose-file: Este bloque es opcional y te permite incluir archivos compose.yml existentes para reutilizar definiciones de servicios.
  4. Flow: Aquí es donde se definen los flujos de aplicación, que se medirán durante la fase de Runtime. Los flujos son esenciales para comprender cómo se consumen los recursos en una aplicación. Por ejemplo, en una aplicación web, puedes crear una imagen de Docker adicional que actúe como cliente y realice diversas interacciones con la aplicación para medir el consumo generado por un usuario.

Fases de Medición en GMT

La medición en GMT se realiza en seis fases distintas:

  1. Baseline: En esta fase, se mide el sistema (la infraestructura) sin tener la aplicación instalada. Esto proporciona una referencia del consumo de recursos sin la aplicación en funcionamiento.
  2. Installation: Se mide el sistema mientras se crean las imágenes de Docker necesarias para la aplicación.
  3. Boot: En esta fase, las imágenes y la aplicación se inician. Se mide el consumo durante el arranque.
  4. Idle: Se mide el consumo de la aplicación después del inicio, pero antes de que se ejecuten los flujos definidos en el archivo usage-scenario.yml. Esto refleja el consumo en estado de espera.
  5. Runtime: Aquí es donde se realiza la medición principal. Se registran los flujos definidos en el archivo usage-scenario.yml mientras se ejecutan. Esto proporciona información sobre el consumo real de recursos durante el funcionamiento normal de la aplicación.
  6. Remove: En la fase de Remove, se mide el consumo mientras el sistema se detiene y vuelve a la fase de Baseline. Esto permite evaluar el consumo cuando se detiene la aplicación.

Interfaz Web y Servicio en la Nube

GMT ofrece una interfaz web que te permite visualizar las mediciones realizadas, compararlas en diferentes momentos y obtener insignias por logros ambientales. Además, GMT proporciona un servicio en la nube donde puedes medir tu aplicación en la infraestructura que ofrecen. Sin embargo, ten en cuenta que para utilizar este servicio, el repositorio de tu aplicación debe ser público y solo se permite una solicitud por día, que se encolará para su ejecución.

En resumen, Green Metrics Tool te proporciona una forma estructurada de medir el consumo de recursos de tus aplicaciones. GMT te ayuda a tomar decisiones informadas para optimizar tus aplicaciones y reducir su impacto ambiental. Con GMT, estás un paso más cerca de contribuir a un mundo más sostenible y responsable ambientalmente.

 

Oscar Blanco
Senior Software Engineer at ilitia Technologies