Für IT-Spezialisten und Softwarearchitektinnen ist Nachhaltigkeit ein wichtiger Aspekt ihrer Arbeit und das entscheidende Stichwort dabei lautet: Energieverbrauch. Diesen beschreibt das Borderstep Institut in Bezug auf Deutschland 2024 wie folgt:

„Zwischen 2010 und 2024 ist der Stromverbrauch der Rechenzentren und kleineren IT-Installationen um über 90 % auf knapp 20 Mrd. kWh im Jahr angestiegen. […] Das beschleunigte Wachstum der RZ-Branche wird zwangsläufig zu einem weiteren Anstieg des Energiebedarfs führen. Bis zum Jahr 2030 wird erwartet, dass Rechenzentren in Deutschland etwas mehr als 30 Milliarden Kilowattstunden Strom pro Jahr verbrauchen. Diese Prognose berücksichtigt die Anforderungen des Energieeffizienzgesetzes und geht von einer erheblichen Verbesserung der Effizienz der Gebäudetechnik aus […] Die durch den Stromverbrauch der Rechenzentren erzeugten Treibhausgasemissionen werden in Deutschland deutlich abnehmen, weil die Stromversorgung zunehmend auf erneuerbare Energien umgebaut wird. Bis zum Jahr 2030 werden sie voraussichtlich um 30 % sinken“.

Die Rolle der Software bei der CO₂-Ersparnis

Nachhaltigkeit hat viele Facetten, wie etwa ein Blick auf die UN-Nachhaltigkeitsziele zeigt. Auch die Definition des Bitkom (2021) im Umfeld „Ressourceneffiziente Programmierung“ fasst den Begriff sehr weit, wie der folgende Auszug aus der Begriffserklärung zeigt:

„Dauerhafte Entwicklung, die die Bedürfnisse der Gegenwart befriedigt, ohne zu riskieren, dass künftige Generationen ihre eigenen Bedürfnisse nicht befriedigen können […].“

Die entscheidende Frage ist allerdings: Wo gibt es bei der Entwicklung von Software direkte Einflussmöglichkeiten? Der naheliegendste Aspekt ist eindeutig der Energieverbrauch der IT, der im täglichen Betrieb immer präsent ist. Warum ist das so wichtig? Bei Software geht es im Allgemeinen nicht um den Selbstzweck, sondern um die Unterstützung bei Aufgaben und Problemen im täglichen Leben. So kann es passieren, dass eine für sich genommen lapidare Tätigkeit eines Menschen in Summe einen sehr hohen Energieverbrauch erzeugt. Nehmen wir als Beispiel eine Google-Suchanfrage. Sie hat im Schnitt einen Strombedarf von 0,3 Watt. Je nachdem, welchen Modellen gefolgt wird, entsteht bei einem durchschnittlichen Volumen von 75.000 Suchanfragen pro Sekunde im Jahr ein Strombedarf von ca. 720 GWh. Dies entspricht ca. 400.000 Single-Haushalten in Deutschland. Mit dem Einzug von KI-gestützten Systemen hat sich der Verbrauch verzehnfacht.

Zwar wird die Hardware immer effizienter im Verbrauch, aber das Benutzerverhalten (Beispiel: „Wie viele Streamingdienste habe ich abonniert?“) und das Softwareangebot fressen die Einsparungen oft wieder auf. So ist immer mehr Hardware nötig, um mit dem stetig wachsenden Softwareangebot mithalten zu können. Im Resultat steigt der Energieverbrauch unaufhörlich.

Grundlast einer Softwarearchitektur

Beim Blick auf die tägliche Arbeit von Softwarearchitekten drängt sich schnell der Gedanke auf, dass der Energieverbrauch der jeweiligen Architektur einfach zu ermitteln sein sollte. Dafür wäre die Einführung eines Energielabels eine geeignete Maßnahme, die einer Software ein CO₂-Preisschild umhängen würde. Leider lässt es sich nicht so einfach bewerkstelligen, denn die Softwarearchitektur ist eine wichtige, aber nicht die einzige Komponente, die einen Einfluss auf den Energieverbrauch hat.

Zu den weiteren Faktoren gehören die Umsetzung der Softwarearchitektur und die Verwendung der Software durch den Benutzer. Schaut man in die Vergangenheit, zeigt sich immer wieder, dass Applikationen zweckentfremdet wurden. Der Klassiker für umfangreiche Nutzung außerhalb des ursprünglich gedachten Nutzungszwecks ist Microsoft Excel. Das System wird mittlerweile für viele Use Cases eingesetzt, was auf der einen Seite Kreativität im Umgang mit Systemen zeigt, aber, wie schon angesprochen, die Kontrolle unmöglich macht.

Bei der Umsetzung der Softwarearchitektur kann es schon mal passieren, dass sich unnötig komplizierte Codezeilen einschleichen. Um den Qualitätsanforderungen dennoch zu entsprechen, ist im Softwarebetrieb letztlich mehr Hardware nötig als geplant.

Diese Beispiele zeigen, wie komplex das Thema Energieverbrauch von Software ist. Es gibt eine Reihe Faktoren, um darauf Einfluss zu nehmen und auch die Softwarearchitektur hat ihren Anteil daran. Woran lässt sich festmachen, was gutes oder schlechtes Softwaredesign im Sinne von Nachhaltigkeit ausmacht? Sind zwei Microservices nachhaltiger als einer? Ist ein Monolith ineffizienter als Microservices? Entwicklungsteams und das Management erwarten Antworten auf diese Fragen.

Was hat Einfluss auf den Energieverbrauch?

Angesichts der komplexen Gemengelage liegt die Frage nahe: Gibt es einen Ansatz, um für weniger Energiehunger bei einer Software zu sorgen? Vielen Softwareherstellern ist das Thema mittlerweile wichtig und dementsprechend geben sie Empfehlungen oder Handlungsanweisungen heraus. Aber auch hier gilt: Was bei dem einen funktioniert, muss bei einem anderen noch lange nicht zum Erfolg führen. Markus Eisele von Red Hat hat eine Reihenfolge formuliert, der wir gerne folgen:

• Datendesign, -nutzung und -speicherung: Weniger ist hier mehr! Entwicklerinnen und Entwickler neigen dazu, zukunftssicher zu arbeiten: „Es kann ja mal sein, dass dies benötigt wird.“ So kommt es häufig zu Überprovisionierung, sodass beispielsweise mehr Daten als notwendig über die Netzwerke verteilt werden. Oder viele Zugriffe werden bis zur Datenhaltung weitergeleitet, auch wenn das nicht notwendig ist. Entwicklerinnen und Entwickler sollten einmal prüfen, welchen Stromverbrauch ein Speichern oder echtes Löschen auf einer Festplatte generiert.
• Anwendungsdesign: Das Internet hat es geschafft, dass Software immer erreichbar ist. Dieses „Always on“ hat die gleichen Auswirkungen wie der Stand-by-Modus bei Haushaltsgeräten. Dabei kommen die bereitgestellten Ressourcen nicht wirklich zum Einsatz. Die meisten Applikationen arbeiten immer noch synchron, obwohl sich viele ihrer Prozesse parallelisieren ließen.
• Plattformbereitstellung, -nutzung und -skalierung: Bei diesem Punkt zeigt sich eine direkte Auswirkung von Softwarearchitekturen. Provisionierungskonfigurationen können dazu führen, dass zusätzliche Hardware notwendig ist. Obwohl das zumeist nicht der wesentliche Punkt im Sinne der Nachhaltigkeit ist (Entwickler betrachten nur den Applikationskontext), kann das im schlechtesten Fall einen Dominoeffekt auslösen: Markus Eisele hat recht, wenn er bemerkt, dass man die Konfiguration unter Umständen in ihrer Gesamtheit betrachten muss.
• Codeeffizienz: Auch wenn Entwickler und Entwicklerinnen es nicht gerne hören: Der effizienteste Code ist kein Code. Wenn sie Code schreiben, sollten sie bereits beim Design auf den Workload achten.
• Betrieb: Cloudsysteme bieten eine hohe Rechendichte für ihre gemanagten Serviceangebote. Anwenderinnen und Anwender können im Vergleich zu selbst virtualisierten Applikationsservern in der Cloud mehr Software auf weniger Hardware betreiben. Das sollte man unbedingt nutzen.