CO2-Fußabdruck von Software berechnen? So geht’s! 

Diskussionen rund um die CO₂-Emissionen konzentrieren sich heute in der Regel auf die Hardware. Der Einfluss von Software auf die CO₂-Bilanz eines Geräts ist noch wenig beachtet – zu Unrecht. Denn die Bereitstellung und Nutzung der Software trägt durchaus zu den Gesamtemissionen eines Geräts bei.

Insgesamt ist die Software-Branche für etwa drei Prozent der weltweiten CO2-Emissionen verantwortlich – das entspricht ungefähr dem Anteil der Luftfahrtindustrie. Im direkten Vergleich sind die CO₂-Emissionen von Software jedoch viel weniger greifbar.

Betrachten wir einen Laptop. Der Strom, den ein Laptop für den Betrieb benötigt, verursacht bei der Erzeugung eine bestimmte Menge an Emissionen. Dies ist der sogenannte Basis-CO₂-Ausstoß. Nun trägt die Software allerdings unmittelbar zu einem höheren Energieverbrauch bei, da durch ihre Nutzung Akku und Arbeitsspeicher stärker beansprucht werden. Folglich kann man sagen, dass die Software ihre Emissionen über die Hardware ausstößt.

Aus diesem Grund gibt es in der Branche ein wachsendes Interesse daran, „grüne Software“ zu entwickeln, die weniger CO₂-Emissionen verursacht. Eine Grundvoraussetzung dafür ist, die Emissionen erfassen zu können. Hier kommt die Arbeit der Green Software Foundation (GSF) ins Spiel. Gegründet von IT-Unternehmen wie Microsoft, GitHub und Thoughtworks hat die Stiftung das Ziel, einen Standard zu schaffen, der die Entwicklung umweltfreundlicher Software ermöglicht.

Die CO2-Emissionen von Software messbar machen 

Es bleibt die große Frage: Wie kann man nun den CO₂-Ausstoß von Software messen? Um das zu beantworten, hat die GSF einen Standard entwickelt – die „Software Carbon Intensity“ (SCI). Sie definiert eine Methodik, um die CO₂-Emissionen eines Software-Systems zu berechnen. Die Stiftung empfiehlt, bei den Berechnungen pro Durchlauf jeweils nur eine Systemkomponente zu betrachten. Generell ist es wichtig, die Berechnungen nur innerhalb der Grenzen eines Softwaresystems durchzuführen. Dies ist wichtig, da die Berechnungen im ersten Schritt für jede einzelne Komponente eines Softwaresystems durchgeführt werden müssen, bevor der SCI des gesamten Systems bestimmt werden kann.

Ein Beispiel: Wir erstellen eine Backend-API, die eine Liste von Produkten zurückgibt (eine Produkt-API), und führen diese API zunächst lokal aus – ohne sie bereitzustellen. Bevor wir nun die CO₂-Emissionen dieser Produkt-API berechnen können, müssen wir uns zunächst den Laptop ansehen, auf dem sie ausgeführt wird. Er könnte zwar im Leerlauf sein, aber auch eine Maschine im Leerlauf verbraucht Energie. Diesen Verbrauch müssen wir berechnen, wenn wir einen genauen Überblick über alles bekommen wollen, was vor sich geht. Sobald wir das anhand einer Standardformel erledigt haben, können wir die Emissionen eines Geräts im Leerlauf berechnen (SCI). Dann können wir die Produkt-API anwenden und den SCI erneut messen. Die Differenz zwischen diesen beiden Werten ergibt dann den CO₂-Ausstoß der Produkt-API. Es ist wichtig, bei wiederholten Messungen und Berechnungen jede Änderung der Komponenten zu berücksichtigen. 

Software-Grenzen 

Es gibt viele Beispiele für Software-Grenzen. Die Green Software Foundation stellt einige Beispiele auf ihrer Website zur Verfügung: 

• Rechenkapazitäten 
• Speicher 
• Netzwerkausrüstung 
• Speicher 
• Monitoring 
• Geräte im Leerlauf 
• Protokollierung 
• Scannen 
• Erstellung und Bereitstellung von Pipelines 
• Testen 
• Training von ML-Modellen 
• Betrieb 
• Backups 
• Ressourcen für Redundanz 
• Ressourcen zur Ausfallsicherung 

Funktionelle Einheit (R) 

Die Frage, die wir uns stellen müssen: Ist die Basis immer die gleiche? Was ist, wenn die Anzahl der Produkte auf einem Laptop steigt? Oder wenn die Anzahl der API-Aufrufe steigt? Die CO₂-Intensität wird selbst mit derselben Software-Grenze steigen, weil die CO₂-Emissionen je nach den verwendeten Energieeinheiten unterschiedlich sind. Das wiederum hängt von der Skalierbarkeit ab. Und hier stehen wir vor ähnlichen Herausforderungen wie bei der Skalierung von Software in der DevOps-Welt.

In den SCI-Spezifikationen wird die kleinste relevante Einheit der CO₂-Intensität als Funktionseinheit bezeichnet. Nehmen wir als Beispiel wieder eine Produkt-API. Muss ich den SCI berechnen, ist der erste Schritt, die kleinste funktionale Einheit festzulegen. Der SCI-Standard schreibt vor, dass wir berechnen, verbessern, neu berechnen und immer weiter verbessern müssen, um die CO₂-Emissionen zu senken. Was dabei konstant bleiben muss, ist die funktionelle Einheit R. Die Differenz im Stromverbrauch zu berechnen, ist in bestimmten Situationen recht einfach, wenn ein Voltmeter zur Verfügung steht. Fließen Clouds mit in die Gleichung ein, wird es komplexer. Alle vier großen Cloud-Anbieter haben auf ihren Websites eine Stelle eingerichtet, an der Software-Entwickler:innen einsehen können, wieviel Energie ihre Dienste verbrauchen. Wie kann man aber wissen, wie hoch der Energieverbrauch ist, wenn man nicht mit einem dieser Cloud-Anbieter zusammenarbeitet? Wenn man die Details des Energieverbrauchs seiner Arbeitslast nicht kennt?

Die SCI-Gleichung 

Die Gleichung des SCI lautet: 

SCI = ((E*I) + M) pro R 

Was steckt dahinter? Wir haben bereits R beleuchtet, betrachten wir nun E. 

Energieverbrauch (E) 

Jeder Cloud-Anbieter kann Spezifikationen für die verwendete Hardware bereitstellen. Und jeder Hardware-Anbieter kann Angaben über den Energieverbrauch machen, den der Arbeitsspeicher seines Produkts (zum Beispiel) normalerweise verbraucht. Anhand dieser Daten lässt sich das CO₂EQ (Kohlendioxidäquivalent) für 1 Kilowattstunde Energie berechnen. 

Standortbezogene marginale CO2-Intensität (I) 

Wenn ich nun weiß, wie viel Energie meine Software verbraucht, wie kann ich das in Kohlendioxidäquivalente umrechnen? Dafür gibt es keine allgemeingültige Formel, denn jede Region hat ihren eigenen Standard. In Australien zum Beispiel gibt es einen Standard, der angibt, wie viel Kohlenstoff pro verbrauchte Kilowattstunde Energie erzeugt wird. In der Formel zur Berechnung des SCI wird dies als Location-Based Marginal Carbon Intensity (standortbezogene marginale CO₂-Intensität) bezeichnet und mit „I“ abgekürzt. Im Kontext von „E“ wird „I“ mit „E“ als „O“ bezeichnet, also betriebliche Emissionen (Operational Emissions). Das ist die Menge an CO₂, die bei einem bestimmten Prozess freigesetzt wird. 

Eingebettete Emissionen (M) 

Eingebettete Emissionen, auch „graue Energie“ genannt, sind die Menge an CO₂, die bei der Herstellung und Entsorgung eines Hardware-Geräts entsteht. Läuft Software auf einem Gerät, wird ihr ein Teil der eingebetteten Emissionen zugeschrieben. Dies ist der Wert M, der in der SCI-Gleichung berechnet wird. Dieser Anteil besteht sowohl aus einem Zeit- als auch aus einem Ressourcenanteil. Den Zeitanteil bestimmt die Dauer, die Software auf einem Gerät läuft. Der prozentuale Anteil der Geräteleistung, der während dieser Zeit nur für diese Anwendung reserviert ist, bestimmt den Ressourcenanteil. Im Gegensatz zu früheren Berechnungen erhalten wir so direkt den CO₂EQ. 

Mehr Einblicke für mehr Nachhaltigkeit 

CO₂-Emissionen werden bei der Software-Entwicklung oft nicht so ernst genommen wie andere Aspekte. Ein guter erster Schritt dagegen ist, in unsere CI/CD-Pipelines Zeit und Kapazitäten einzuplanen, um den CO₂-Fußabdruck zu messen und zu überwachen. Denn wir alle tragen Verantwortung für die Umwelt. Ein sorgfältiger Umgang mit dem SCI kann einen großen Schritt auf dem Weg zu umweltfreundlicher Software darstellen.