Software Carbon Intensity. Cómo medir las emisiones de nuestros desarrollos
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:
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
