Corinna John 24. September 2024

Nachhaltigkeit in der Software-Architektur

Heute schon für morgen entwickeln

Mit den vorhandenen Tools gibt es keine Ausrede mehr, um Nachhaltigkeit in der Architektur oder der Entwicklung zu vernachlässigen. © Adobe: DarkinStudio / stock.adobe.com / 931592136 / Generiert mit KI — © Adobe: DarkinStudio / Generiert mit KI

Jede Software-Architektur soll sicher und effizient sein. Um Nachhaltigkeitskriterien zu erfüllen, muss sie auch energiesparend und wartbar werden. Einige quelloffene Projekte entwickeln Lösungspakete, mit denen der Energieverbrauch einer Software abgeschätzt und optimiert wird. Doch wichtiger als der Einsatz immer besserer Werkzeuge ist, schon bei der Planung an langfristige Wartbarkeit zu denken, so dass die Architektur über die Jahre nicht veraltet, sondern mitwächst.

Offene Standards

Nachhaltig ist eine Software-Lösung nur, wenn sie lange genutzt und weiterentwickelt wird. Es lohnt sich, bereits bei der Auswahl verwendeter Technologien den gesamten Lebenszyklus im Blick zu behalten.

Offene Standards für Datenformate und Schnittstellen haben gegenüber produktspezifischen Formaten den Vorteil, dass sie von unterschiedlichen Herstellern unterstützt werden, so dass Programmteile im Laufe der Zeit ausgetauscht werden können. Zum Beispiel liegt es auf den ersten Blick nahe, für eine winzige Routineaufgabe wie das Speichern von Einstellungen schnell selbst eine Funktion zu schreiben, etwa das Konfigurationsobjekt in eine Binärdatei zu serialisieren. Von dieser Funktion sind dann jedoch alle zukünftigen Komponenten abhängig, die mit den Einstellungen arbeiten – einschließlich des Nachfolgeprodukts, das die Konfigurationsdateien in sein eigenes Format konvertieren muss. Von Anfang an auf ein verbreitetes Format zu setzen, je nach Komplexität etwa JSON oder SQLite, spart langfristig viel Arbeit.

Ebenso empfiehlt sich eine gewisse Vorsicht gegenüber sehr neuen Bibliotheken. Wer auf ein modernes Framework setzt, das schon wenige Jahre später nicht mehr gewartet wird, kommt zwar eventuell schneller zu ersten Releases, handelt sich langfristig jedoch Mehrarbeit ein. Ähnlich verhält es sich mit der Kommunikation zwischen Services: Wer etablierte Protokolle wie AMQP und REST einsetzt, kann später einzelne Services austauschen, ohne die übrigen anzupassen.

Arbeit verschieben

Viele Cloud-Hoster bieten eine Auswahl regionaler Rechenzentren an, in denen ein Kundenprojekt laufen soll. So darf man etwa wählen, ob dabei Data Centers in den USA oder in Europa verwendet werden. Natürlich zählt dabei zuerst der Rechtsraum, denn manche Daten dürfen nur in Deutschland oder nur in der EU verarbeitet werden.

Auch in diesem Rahmen lässt sich der CO2-Fußabdruck senken: In der Cloud betriebene Software sollte in Regionen mit dem höchsten Anteil regenerativer Energiequellen ausgeführt werden. Wenn eine stabile Wetterlage einem Land besonders viel Sonne oder Wind beschert, lohnt es sich eventuell, die Software dorthin zu verlagern und damit den Stromüberschuss abzufangen.

Die Website "Electricity Map" hilft dabei [1]. Auf einer Weltkarte zeigt sie den Strommix und die CO2-Emissionen vieler Regionen, dazu die aktuellen Stromimporte und -exporte. Um eine Anwendung automatisch ins aktuell umweltfreundlichste Rechenzentrum zu verschieben, steht auch eine kommerzielle API zur Verfügung.

Muss man ein Machine-Learning-Modell in einer windstillen Nacht trainieren?

Zeitintensive sowie unkritische Rechenprozesse sollten auf Tageszeiten verschoben werden, in denen genug Ökostrom oder sogar Überschuss verfügbar ist. Muss man ein Machine-Learning-Modell in einer windstillen Nacht trainieren, wenn der Wetterbericht einen stürmischen Tag vorhersagt? Dynamische Stromtarife mit rechtzeitigen Preisvorwarnungen können das "Time Shifting" in naher Zukunft vereinfachen.

Daten minimieren

Netzwerk- und Rechenlast gehen Hand in Hand, denn alle übertragenen Daten müssen verarbeitet werden und alle verarbeiteten Daten werden anschließend abgeholt. Besonders für Web-Oberflächen sollte es selbstverständlich sein, dass Daten nur auf dem Server verarbeitet werden. An den Browser wird genau das geschickt, was angezeigt werden soll – natürlich komprimiert und in angemessener Auflösung. Das entlastet die Endgeräte, so dass die Anwendung auch auf alten und günstigen Geräten flüssig läuft.

Auf dem Rückweg zum Server kann durch Bündelung der HTTP-Requests viel Netzwerklast eingespart werden. Statt jeden Klick sofort zu melden, sollte das Frontend einfach warten, bis man auf "Fertig" klickt. Zum Beispiel war es bei einer typischen Suchfunktion lange modern, nach jedem Tastendruck sofort ein Zwischenergebnis anzuzeigen. Das nützte den Benutzenden wenig, erzeugte jedoch viel überflüssige Last. Einen User ausreden, also in Ruhe alle Suchfilter eintippen zu lassen, und diese nach dem Klick auf "Suchen" am Stück zu übertragen, spart gleichermaßen Nerven, Netzwerklast und Rechenzeit.

Der Speicherplatz auf dem Server muss nicht unnötig vollgepackt werden. Services in einem Docker-Container benötigen gewöhnlich nur einen Bruchteil der Standardprogramme, die das Base Image mitliefert. Dazu entsteht Datenmüll, wenn beim Aufbau eines Images mehrere Base Images verkettet werden. Deshalb sollten Docker Images vor dem Hochladen optimiert werden, etwa mit Hilfe des "Slim Toolkit" [2]. Die Open-Source-Werkzeugsammlung analysiert Images und verkleinert sie dann, indem sie alles Unnötige entfernt. Dadurch wird das Image nicht nur kompakter. Nebenbei verringert sich auch die Angriffsfläche, da mit den gelöschten Paketen auch deren Sicherheitslücken verschwinden.

Effizient codieren

Entwickler wissen, dass es unendlich viele Wege gibt, um dasselbe Problem zu lösen. Doch welche davon benötigen am wenigsten Energie? An einen effizienten Algorithmus tastet man sich am besten aus zwei Richtungen heran: Zur Entwicklungszeit kann statische Code-Analyse typische Fehler finden, die zu erhöhtem Rechenaufwand führen. Zur Laufzeit lassen sich der Prozess und seine Umgebung überwachen, so dass Stellen entdeckt werden, an denen zu viel Strom verbraucht wird.

Für die Analyse des Quellcodes hat sich "SonarQube" etabliert [3]. In die Build-Pipeline eingebettet, überprüft das Tool die Einhaltung von Qualitätsregeln und warnt vor schlechtem Code, bevor er ins Release gerät. Das Projekt "EcoCode" sammelt Code-Analyzer, die typische Strukturen erkennen, welche zu erhöhtem Bedarf an Ressourcen und Energie führen [4]. Sie werden als Plugin für SonarQube installiert, um die Einhaltung eines nachhaltigen Programmierstils automatisch zu überprüfen. Wie sich eine Software zur Laufzeit verhält, muss letzten Endes im laufenden Betrieb gemessen werden. Sowohl für Docker-Cluster als auch für Kubernetes gibt es fertige Werkzeugkästen.

Das "Green Metrics Tool" von Green Coding ist ein Open-Source-Framework zur Messung des Energieverbrauchs eines Docker-Szenarios [5]. Lokal betrieben, kann es Docker-Compose-Dateien ausführen und den Energieverbrauch der gestarteten Container beobachten. Alternativ bietet Green Coding auch die Analyse von Projekten auf GitHub an.

Der Energieverbrauch eines Softwaresystems, das in Kubernetes läuft, kann noch genauer mit dem Open-Source-Projekt "Kepler" (Kubernetes Efficient Power Level Exporter) abgeschätzt werden [6]. Ähnlich wie das Green Metrics Tool verfolgt auch Kepler die für den Stromverbrauch relevanten Systemstatistiken. Daraus ermittelt es den Energiehunger des laufenden Systems. Bemerkenswert ist, dass Kepler die Messwerte in Form von Metriken für den beliebten Monitoring-Universalisten "Prometheus" ausgibt. So kann der Stromverbrauch von ausgewählten Nodes und Pods mit den Mitteln protokolliert werden, die in einem modernen Cloud-Projekt bereits vorhanden sind.

Wenn die Systemstatistiken des Rechners nicht direkt nutzbar sind – etwa in einer virtuellen Maschine – kann Kepler stattdessen ein zuvor per Machine Learning trainiertes Modell verwenden. Der Stromverbrauch wird dann anhand vorhandener Variablen vorhergesagt. Besonders interessant wird dies, wenn man Kubernetes in einer Testumgebung direkt auf der Maschine installieren kann, aber im Produktivbetrieb auf eine VM oder Cloud angewiesen ist. Dann kann Kepler auf dem Testrechner ein Modell des Energieverbrauchs lernen und exportieren. In der Produktion wird dann dieses Modell abgefragt, um den aktuellen Energiebedarf der Cloud-Anwendung zu schätzen.

Endgeräte entlasten

Während sich die serverseitigen Ressourcen gut messen lassen, darf man bei Web-Anwendungen die andere Seite nicht außer Acht lassen. Die Oberfläche wird im Browser aufgebaut und darf die Ressourcen des unbekannten Endgeräts nicht übermäßig belasten.

Der "WebPageTest" von Catchpoint – schon seit langem beliebt zum Testen der Performance von Webseiten – enthält unter dem Namen "Carbon Control" eine Sammlung von Nachhaltigkeitstests [7]. Unter anderem schätzt es den CO2-Fußabdruck und prüft, ob die Seite selbst sowie nachgeladene Inhalte von Drittanbietern von umweltfreundlichen Rechenzentren ausgeliefert werden. Wer es genau wissen möchte, kann Teile dieser Tests auch selbst durchführen. Denn im Hintergrund verwenden sie die NodeJS-Bibliothek "CO2.JS" von der Green Web Foundation, die sich in jedes Javascript-Projekt einbauen lässt [8].

Das Gemeinschaftsprojekt CO2.JS greift auf offene Stromnetzdaten von Ember und von der UNFCCC (United Nations Framework Convention on Climate Change) zu [9;10]. Die Informationen darüber, welche Domains umweltfreundlich gehostet werden, stammen aus offenen Datensätzen der Green Web Foundation.

Im einfachsten Anwendungsfall nimmt CO2.JS einen Messwert an, zum Beispiel die Anzahl übertragener Bytes und schätzt die dadurch verursachten Emissionen. Dafür wendet es das Sustainable-Web-Design-Modell an, optional auch das OneByte-Modell. Beides sind alternative Modelle für die Gesamtemissionen einer Transaktion, inklusive Transport übers Netz, Datenverarbeitung und die anteiligen Kosten der beteiligten Hardware.

Barrierefreiheit

Eine aufgeräumte, sparsame Benutzeroberfläche enthält fast automatisch weniger Barrieren. So fällt es leichter, das Barrierefreiheitsstärkungsgesetz umzusetzen, das digitale Angebote ab nächstem Jahr zur Barrierefreiheit verpflichtet [11].

Damit rückt auch ein weiteres von den 17 Nachhaltigkeitszielen der Vereinten Nationen näher: Inklusive Gesellschaften und Institutionen [12]. Im digitalen Zeitalter funktionieren sie erst, wenn ihre Software niemanden systematisch ausgrenzt.

Ausblick

Abb. 1: Ein Projekt, das in Standards wurzelt und auf durchdachten Strukturen steht, wächst nachhaltig in die Cloud. Quelle: Eigene Darstellung

Mit Ressourcen sparsam umzugehen, lohnt sich in jedem Fall. Man spart Energie, kommt mit günstiger Hardware aus und sogar die User Experience verbessert sich. Fast nebenbei schont es die Umwelt und entlastet das Stromnetz. Wer bereit ist, etwas Zeit in die Einarbeitung zu investieren, kommt mit Open Source und offenen Daten aus. Projekte wie Kepler und die Green Web Foundation haben hervorragende Vorarbeit geleistet. Natürlich hat auch der Markt das Thema entdeckt. Kommerzielle APIs, wie "Climatiq" und andere, liefern schnelle Emissionsschätzungen auf Anfrage.

Mit den vorhandenen Tools gibt es keine Ausrede mehr, um Nachhaltigkeit in der Architektur oder der Entwicklung zu vernachlässigen. Egal ob man eine neue Software entwirft oder ein bereits produktives System überarbeitet – vom Quellcode bis zum Betrieb sollte man den Ressourcenbedarf im Blick behalten. Nur so wird ein System, das in offenen Standards wurzelt und auf effizienten Datenstrukturen steht, viele Modetrends überleben und mit den Anforderungen der Zukunft mitwachsen (Abb. 1).

Quellen