Wenn Software heiß läuft

Was und wie wir entwi­ckeln, hat enormen Einfluss auf den Energie­ver­brauch unserer IT-Systeme. Softwarearchitekt:innen können durch bewusste Entschei­dungen nachhaltige Impulse für mehr Energie­ef­fi­zienz setzen. Während bei der Bewertung von Systemen im Betrieb bislang Kriterien wie, Funktio­na­lität, Kosten und Zeit im Fokus standen, rückt das Kriterium Klima­folgen immer stärker den Vorder­grund. Dieser Artikel zeigt, wie sich Klima­schutz und Archi­tek­tur­arbeit sinnvoll verbinden lassen.

Wie Software-Archi­tektur den CO₂-Fußab­druck bremst

Die Klima­krise ist ein drängendes Problem. Auch die IT-Branche trägt maßgeblich zum weltweiten CO₂-Ausstoß bei: Verschiedene Studien^[1] kommen zu unter­schied­lichen Ergeb­nissen. Schät­zungen für das Jahr 2020 reichen von 2,1% bis 3,9% Anteil der weltweiten CO₂-Emissionen durch Rechen­zentren. Studien beschreiben, dass der Energie­ver­brauch weiter ansteigen wird, insbe­sondere getrieben durch die zuneh­mende Digita­li­sierung und KI. Im Projekt­ma­nagement für Software­ent­wicklung wird das Kriterium „in Climate“ deshalb immer wichtiger – neben den klassi­schen Anfor­de­rungen wie: in Budget, in Time, in Functionality.

Abbildung 1: Schätzung des IKT-Anteils am weltweiten CO2-Ausstoß. Angelehnt an [2]

Die Rolle der Softwarearchitekt:innen

Mit ihrer Kompetenz und Erfahrung tragen Softwarearchitekt:innen maßgeb­liche Verant­wortung, die weit über bishe­rigen Anfor­de­rungen an Software­architektur hinausgeht. Diese Handlungs­felder sind entscheidend, um den CO₂-Ausstoß in IT-Vorhaben zu verringern:

Anfor­de­rungen:

Nicht jede funktionale Anfor­derung ist zwingend erfor­derlich. Manche sind sogar bei Stake­holdern umstritten. Anfor­de­rungen unter Aspekten von Nachhal­tigkeit und Verfüg­barkeit neu zu priori­sieren oder sogar abzulehnen, ist nur eine Option, um Energie­ef­fi­zienz zu steigern. Natürlich ist es einfach, Dienste durch­laufen zu lassen oder cloud­ba­siert in mehreren Regionen zu betreiben, um gute Antwort­zeiten zu erreichen. Aber braucht es wirklich alle Dienste in gleichem Umfang, rund um die Uhr und weltweit verfügbar? Durch Ermitteln des tatsäch­lichen Bedarfs und Anpassung der laufenden Dienste daran lässt sich viel Energie einsparen.

Architektur/Implementierung:

Bezogen auf Energie­ef­fi­zienz kann Software gut oder schlecht imple­men­tiert werden. Archi­tektur- und Design­ent­schei­dungen wirken sich positiv oder negativ auf die Energie­ef­fi­zienz aus. Es gilt also, Wege zu finden, wie auf Basis der Quali­täts­an­for­de­rungen eine geeignete und gleich­zeitig CO₂-emissi­ons­ef­fi­ziente Archi­tektur entworfen werden kann.

Ein weiteres Beispiel sind die einge­setzten Archi­tek­tur­stile: Micro­ser­vices haben unbestritten ihre Vorteile, z. B. zur horizon­talen Skalierung. Aber wird das wirklich immer benötigt? Könnte ein in vielen Situa­tionen energie­ef­fi­zi­en­terer Modulith (modularer Monolith) bei gleichen Anfor­de­rungen besser sein? Lassen sich beide Stile verbinden und Micro­ser­vices nur dort einsetzen, wo Skalier­barkeit auch wirklich benötigt wird?

Betrieb:

Selbst bei Software, die mit Fokus auf Energie­ef­fi­zienz entwi­ckelt wurde, kann im Betrieb viel davon auf der Strecke bleiben. Auslastung der Hardware, sinnvolle Betriebs­zeiten, Betrieb in Regionen mit einem hohen Anteil erneu­er­barer Energien im Stromnetz oder Abschaltung nicht benötigter Dienste sind Beispiele dafür, wie der Betrieb nachhaltig gestaltet werden kann.

Redundanz:

Für redun­dante Dienste mit hohen Verfüg­bar­keits­an­for­de­rungen werden zusätz­liche Ressourcen benötigt, der Energie­bedarf steigt. Statt­dessen können kleine Dienste genutzt werden, die in sehr kurzer Zeit nachge­startet werden können. Das ermög­licht ein vergleich­bares Verhalten mit deutlich verrin­gertem Ressourcenbedarf.

Energie­ef­fi­zienz als Qualitätsanforderung:

Mit Energie­ef­fi­zienz kommt eine neue Qualität hinzu, die mit anderen Anfor­de­rungen in Einklang gebracht werden muss. Abbildung 2 zeigt Möglich­keiten auf, die sich bei Archi­tek­tur­ent­schei­dungen in Zusam­menhang mit Skalier­barkeit ergeben^[3].

Abbildung 2: Architekturentscheidungen-Skalierbarkeit

You can´t manage what you don´t measure

In allen genannten Handlungs­feldern ist die Expertise von Softwarearchitekt:innen gefragt. Für tragfähige Entschei­dungen braucht es jedoch belastbare Daten. Messung und Monitoring von CO₂-Emmis­sionen ist eine zentrale Aufgabe, ohne die jede Art der Optimierung fragwürdig ist. Die tatsäch­lichen Emissionen von Software lassen sich jedoch nur schwierig bis unmöglich messen, weil diese von vielen Faktoren abhängig sind, wie bspw.: Strommix vor Ort, Tageszeit, Wetter.

Deshalb kommen häufig Proxy-Metriken zum Einsatz, deren Werte mit den CO₂-Emissionen korre­lieren. Beispiele für Messgrößen sind Energie­ver­brauch von Systemen oder Kosten, weil

diese bspw. in der Cloud niedriger sind, wenn weniger Ressourcen verbraucht werden. Kenntnis und Umgang mit von den Cloud-Anbietern angebo­tenen Möglich­keiten für die eigenen Systeme muss daher eine Kernkom­petenz von Softwarearchitekt:innen werden – ebenso der Umgang mit Werkzeugen, die Energie­ver­brauch von Workloads messen^[4] oder die CO₂-Emissions-Effizienz abschätzen^[5] können.

Softwarearchitekt:innen als Multi­pli­kator für Green IT

Durch ihre zentrale Rolle sind Softwarearchitekt:innen Multi­pli­ka­toren im Projekt und im Unter­nehmen. Sie können das Thema Green IT auf die Agenda bringen und alle Betei­ligten mitreißen – für die Entwicklung und den Betrieb von energie­ef­fi­zi­enter und CO₂-armer Software.

Die Klima­krise wartet nicht: Es liegt an uns Softwarearchitekt:innen, „in Climate“ zur selbst­ver­ständ­lichen Anfor­derung zu machen.

Quellen:

[1] Roussilhe: Explaining the environ­mental footprint of the digital sector, https://gauthierroussilhe.com/en/articles/explaining-the-environmental-footprint-of-the-digital-sector, 2021

[2] Belkhir, Elmeligi: Assessing ICT global emissions footprint: Trends to 2040 & recom­men­da­tions, Journal of Cleaner Production, Volume 177, 10. März 2018, Seiten 448–463

[3] Wanner, Kutschera: CO2-Emissions-Effizienz trifft auf Quali­täts­modell, ITSpektrum 5/2024

[4] Kuber­netes Efficient Power Level Exporter (Kepler), https://sustainable-computing.io/

[5] Cloud Carbon Footprint, https://www.cloudcarbonfootprint.org/

Autor

Prof. Dr.-Ing. Gerhard Wanner (wanner@hft-stuttgart.de) ist seit mehr als 30 Jahren Berater und Software­ar­chitekt, über 20 Jahre Professor für Infor­matik an der HFT Stuttgart mit den Schwer­punkten Software­en­gi­neering und Software­architektur. Das Thema Green IT ist seine Passion, in der Forschung, als Autor und in der Lehre.