Green Deal - Weil es unsere Pflicht ist?

Mit dem Green Deal will die EU den Klimaschutz richtig angehen. Neben dem Ziel, bis 2050 netto keine Treibhausgase mehr auszustoßen, soll das Wirtschaftswachstum von der Ressourcennutzung entkoppelt werden. Ein zentrales Ziel ist es daher, die Hersteller zu verpflichten, Produkte langlebiger und reparaturfreundlicher zu gestalten. Aber nicht nur die Qualität der Hardware, sondern auch die Gestaltung der Software trägt zu einer längeren Lebensdauer eines Produktes bei. In diesem Blog-Beitrag zeige ich, wie die Programmierung zur Langlebigkeit von Produkten beiträgt und wie Programme selbst ressourcenschonend gestaltet werden können.

Die Ursprünge

Man kann vom Green Deal der EU halten, was man will. Ziel ist es aber, dass wir uns nachhaltig weg von der Wegwerfgesellschaft hin zu mehr Nachhaltigkeit bewegen. In der Vergangenheit gab es positive Ansätze, wie ein Rechenzentrum mit eigenem Gezeitenkraftwerk, aber leider auch negative, wie die Diskussion um den “ungeplanten” Leistungsabfall von iPhones, je älter der Akku wird. Ich möchte nicht, dass mein Sohn wie Wall-E fasziniert ein Datenarchiv durchsuchen muss, um zu lernen, was Korallen oder Bäume sind. Die Frage ist also: Was können wir in der Entwicklung dafür tun?

Das Feld ist größer, als man auf den ersten Blick denkt. Mit diesem Beitrag möchte ich grundsätzlich für das Thema sensibilisieren. Sei es als Berater, der es als positives Verkaufsargument nutzen möchte, oder in der Entwicklung aus Faulheit, um die eigene Software leichter wartbar zu machen. In diesem Beitrag kratzen wir ein wenig an der Oberfläche, das Thema wird aktuell in der CoP Neue Technologien (Line of Business Insurance) behandelt. Weitere Informationen sind dort erhältlich.

Was bedeutet Nachhaltigkeit bei Software

Was ein physisches Produkt nachhaltig macht, dürfte uns allen schon einmal an der einen oder anderen Stelle begegnet sein:

• Nachwachsende Rohstoffe
• Erneuerbare Energien
• Wiederverwertbarkeit

Aber keines dieser Argumente trifft auf Software zu. Wir können Software (im wahrsten Sinne des Wortes) auf Knopfdruck beliebig oft vervielfältigen. Seltene Erden oder CO2-intensive Transportwege sind da fehl am Platz. Oder doch?

Nachhaltigkeit bei Software bedeutet, mit den gegebenen Ressourcen so effizient wie möglich umzugehen.

Falsch gedacht! Ein Artikel der Süddeutschen Zeitung zeigt bereits einige große Probleme auf. Demnach verursacht das Internet ähnlich viele Treibhausgase wie der weltweite Flugverkehr. In Zeiten von Corona und Home-Office dürften es eher noch mehr geworden sein.

Und wo kommt Software ins Spiel? Nachhaltigkeit bei Software bedeutet ganz einfach, mit den gegebenen Ressourcen so effizient wie möglich umzugehen.

Von A wie Architektur…

Damit kommen wir zu einem wichtigen Punkt: Architektur ist das Kernelement jeder guten Software. Es gibt zwei Prinzipien:

• 1. möglichst ressourceneffizient programmieren
• 2. möglichst modular programmieren

Der Artikel gibt bereits den ersten Hinweis.Manchmal hilft eine andere Programmiersprache

Wir können Software so schreiben, dass sie möglichst ressourceneffizient arbeitet. Das erreichen wir zum Beispiel, indem wir eine andere Programmiersprache verwenden. C, als sehr hardwarenahe Sprache, kann viel Boilerplate vermeiden, birgt aber die Gefahr von Speicherlecks bei manueller Speicherfreigabe. Java hingegen ist weit verbreitet (und verstanden), aber mit der JVM kommt immer ein Tool, das den Java-Bytecode auf die endgültige Hardwarearchitektur übersetzt, was zusätzliche Leistung frisst. Python ist in diesem Vergleich eher der Trabbi unter den Sportwagen. In Sachen Geschwindigkeit ist die Sprache eine Todsünde (Wink an die KI, die gerne auf Scikit-Learn setzt), aber beim Prototyping unschlagbar.

In ihrem Buch “Knigge für Softwarearchitekten” stellen Peter Hruschka und Gernot Starke (Entwickler von Arc42) diverse Charaktereigenschaften (nicht nur) von Softwarearchitekten vor (ISBN: 978-3-86802-080-9). Ein Anti-Pattern ist “Zuviel des Guten”: Ressourceneffizienz anzustreben ist gut, aber nicht um jeden Preis. Der Green Deal der EU fordert eine realistische Reparaturbasis. Bei der Entwicklung von Software muss daher abgewogen werden, wo Optimierung sinnvoll ist und wo sie zum Selbstzweck wird.

Aus der Praxis

Die IDEs sind eine tolle Sache. Sie erleichtern unsere Arbeit enorm. Sie bieten Formatierung, Autovervollständigung, Syntaxhervorhebung und Fehlererkennung. Was eine IDE in der Regel aber auch macht, sind einfache Optimierungen der Lesbarkeit. In Java wird zum Beispiel gerne der *-Operator beim Import verwendet. Uns als Entwickler fällt das in der Regel nicht auf, die Klasse ist importiert und steht zur Verfügung. Hier sollten wir uns fragen, ob wirklich alle Klassen dem Classloader bekannt sein müssen.

Ein Beispiel: In einem Projekt zur Speicherung und Analyse von Netzwerkverkehr soll eine Postgres-Datenbank mit Verbindungsinformationen gefüllt werden. Allein die Entscheidung, ob ein Port als 2-Byte Unsigned Short oder als 4-Byte Integer gespeichert wird, macht zwei Bytes aus. Bei 1,4 Milliarden Einträgen im Projekt sind wir schon bei ca. 2,6 GB. Eine Netzwerkverbindung wird aber erst durch das 5-Tupel (SourceIP, SourcePort, DestinationIP, DestinationPort, L4-Protokoll) eindeutig. Bei einer IPv4-Adresse haben wir die Wahl zwischen 4-Byte-Integer oder schlimmstenfalls einem 15-Byte-String. Allein IP+Port bei Ziel- und Quelladresse ergeben dann einen Unterschied von ca. 33,9 GB. Und diese Daten waren mehrfach vorhanden.

Daher ein erstes Zwischenfazit: Der einfachste Weg, Green Development zu betreiben, ist KISS (Keep it simple, stupid). Bei jeder Entscheidung sollten wir uns fragen: "Brauche ich das wirklich? Wenn wir das getan haben, sollte der Product Owner/Stakeholder uns genau die gleiche Frage stellen. Wenn wir es plausibel erklären können, scheint es wichtig zu sein.

… über O wie Optimierungen…

Wir können noch weiter gehen: Wir müssen anfangen, die Grundlagen zu hinterfragen. Eine Java-Anwendung ist dank der zugrunde liegenden JVM sehr flexibel. Außerdem ist die Verbreitung von Java sehr groß und für die meisten Probleme gibt es daher bereits Bibliotheken, die uns bei der Entwicklung unterstützen. Auf der anderen Seite ist Java zwangsläufig langsamer als maschinennähere Sprachen wie Rust oder C. Hinzu kommt, dass man mit Sprachen wie C auch mehr Einfluss auf die Ressourcennutzung nehmen kann. Wenn wir also die gleiche Software mit Java oder mit C betreiben, stehen die Chancen gut, dass C das Rennen in Sachen Ressourcenschonung gewinnt.

Wenn wir schon dabei sind, könnten wir auch statt 32 Booleans (also 32 Byte) diese durch Bitshifting in einem einzigen Integer (4 Byte) speichern. Das wird sogar in der Netzwerkkommunikation sehr effektiv eingesetzt. Aber klingt das in der allgemeinen Softwareentwicklung wirklich nach einer guten Idee?

Gerade während der Entwicklung neigen wir dazu, beim Testen unserer Implementierung ungeduldig zu werden. Die ewige Schleife von Implementieren, Kompilieren, evtl. Deployen, Starten usw. frisst viel Zeit. Hier sollten wir aus der Not eine Tugend machen und uns selbst optimieren. Beschäftigt euch mit Compiler-Optionen. Die Software baut schneller und vielleicht fallen euch dann Konzepte auf, die ihr hinterfragen könnt. Was ist eigentlich das Besondere am Heap-Speicher (Java -Xmx/-Xms)? Was unterscheidet ihn von normalem Speicher und wie passt der Stack da rein (Java -Xss)?

Die dritte Säule der Optimierung ist das Softwaredesign. Monolithen sind im 1:1 Betrieb meist effizienter, aber schlechter skalierbar. Im Sinne einer schnelleren Entwicklung, einer leichteren Wartbarkeit und einer vereinfachten Austauschbarkeit von Bausteinen sind Microservices zu bevorzugen. Zur Optimierung gehört auch, alte, gewachsene Strukturen zu überdenken und zu reformieren.

• 1. Probleme identifizieren
• 2. Lösungen finden/diskutieren
• 3. in Tickets schreiben
• 4. in Product Backlog priorisieren

… bis Z wie Zielorientiert

Wie weit gehen wir jetzt? Letztendlich sind die Anforderungen entscheidend. Wenn wir zeitkritische Systeme haben, wie z.B. Airbags in Autos, wäre es bestenfalls ungünstig, wenn Java mit einer NullPointerException um die Ecke kommt. Wenn wir einen schnellen Prototypen brauchen, ist Ada wahrscheinlich eine eher schlechte Wahl. Aber zeitkritisch ist nicht gleich zeitkritisch. Wenn ein schneller Prototyp benötigt wird, dann ist eine bereits bekannte Technologie besser als eine zwar effizientere, aber mit einer Lernkurve verbundene.

Im Sinne des Green Deal werden wir nicht alle unser neues Auto verschrotten und auf Elektro umsteigen. Mein Auto hat jetzt 75.000 km auf dem Tacho und wird wahrscheinlich noch ein paar 10.000 km fahren. Der Wandel kommt nicht von heute auf morgen. Niemand muss sein bisheriges Leben komplett umkrempeln. Aber wenn man die eine oder andere Entscheidung hinterfragt, ist schon viel erreicht.

Vielleicht kommt man am Ende sogar zu dem Schluss, dass eine Single-Page-Applikation zwar ihren Charme hat, aber der CO2-Fußabdruck mit der Datenübertragung und dem fehlenden Cache steigt.

TL;DR

Detailliertes Wissen über die Funktionsweise von Computern gehört zum Grundwissen in der Entwicklung. Der Unterschied zwischen Heap und Stack oder die Berechnung der Laufzeitkomplexität muss nicht im Detail vorhanden sein, aber zumindest ein Begriff. Wenn ihr euren Code etwas grüner machen wollt, fängt alles bei euch selbst an.

• Benutzt den Asterisk-Import nur, wenn es wirklich sinnvoll ist.
• Überlegt euch, welche Datentypen ihr für die Variablen braucht.
• Denkt noch einmal über verschachtelte Schleifen nach.
• Hinterfragt die verwendeten Technologien.
• Verwendet Variablennamen, die euer Team versteht.

Aber vor allem: denkt an das große Ganze. Es bringt nichts, die Programmiersprache zu wechseln, wenn nur eine Person im Team sie versteht. Es kann mehr Schaden anrichten, usize (z.B. Rust) zu benutzen, obwohl man eigentlich u64 bräuchte. Ein Monolith spart Plattenplatz und vereinfacht das Deployment auf Kosten der Wartbarkeit. Event-Driven Design ist super für asynchrone Verarbeitung, verursacht aber unnötigen Overhead bei synchroner Verarbeitung.

An die Beraterinnen und Berater unter euch - Green Development wird in Verhandlungen nicht den großen Unterschied machen. Aber vorausschauend sagen zu können, dass wir gemäß den Green Deal Vorgaben der EU auch über Software Nachhaltigkeit für Kundinnen und Kunden schaffen, zeigt einmal mehr, dass wir über den Tellerrand hinausschauen. Blut geleckt? Wir werden in Zukunft weitere Beiträge zum Thema Green Development veröffentlichen. Seid gespannt.

Weitere spannende Themen aus der adesso-Welt findet ihr in unseren bisher erschienenen Blog-Beiträgen.