Grüne Software für Gebäude

Kapitel 1. Einführung in Grüne Software

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Du würdest mich nicht mögen, wenn ich wütend bin.

Dr. Bruce Banner, grüner Wissenschaftler

Wir können verstehen, warum die Aktivisten wütend sind. Nur wenige Branchen haben sich schnell genug bewegt, um die Energiewende zu unterstützen, und das gilt auch für den Tech-Sektor.

Aber wir beginnen uns zu verändern.

Was bedeutet es, in der IT grün zu sein?

Laut der Green Software Foundation (GSF) ist grüne Software (oder nachhaltige Software) eine Software, die beim Betrieb nur minimale Kohlenstoffemissionen verursacht. Mit anderen Worten:

• Grüne Software ist so konzipiert, dass sie pro Arbeitseinheit weniger Strom und Hardware benötigt. Dies wird als Kohlendioxid-Effizienz bezeichnet, da sowohl die Stromerzeugung als auch der Bau der Hardware zu Kohlendioxid-Emissionen führen.

• Grüne Software versucht auch, ihren Betrieb und damit ihren Stromverbrauch auf Zeiten und Orte zu verlagern, an denen der verfügbare Strom aus kohlenstoffarmen Quellen wie Wind, Sonne, Erdwärme, Wasserkraft oder Kernkraft stammt. Oder er versucht, zu Zeiten, in denen der verfügbare Netzstrom kohlenstoffintensiv ist, weniger zu tun. So könnte er zum Beispiel mitten in einer windstillen Nacht, in der der einzige verfügbare Strom aus Kohle erzeugt wird, die Qualität seiner Dienstleistungen reduzieren. Das nennt man Kohlenstoffbewusstsein.

Energie- und Hardware-Effizienz sowie Kohlenstoffbewusstsein sind die grundlegenden Prinzipien des Green Computing (siehe Abbildung 1-1).

Abbildung 1-1. Die Definition von grüner Software der Green Software Foundation

Jetzt, wo wir wissen, was grüne Software ist, wie können wir sie erstellen?

Was wir vermuten

Dieses Buch besteht aus 13 technischen Kapiteln:

1. Einführung in Grüne Software

2. Bauklötze

3. Code-Effizienz

4. Operative Effizienz

5. Kohlenstoff-Bewusstsein

6. Hardware-Effizienz

7. Networking

8. Grüneres maschinelles Lernen, KI und LLMs

9. Messung

10. Überwachung

11. Co-Benefits

12. Die Green Software Maturity Matrix

13. Wie geht es jetzt weiter?

Wir werden nun jedes der kommenden Kapitel durchgehen und dir die wichtigsten Erkenntnisse mit auf den Weg geben.

Kapitel 2: Bausteine

Bevor wir eintauchen, gibt es eine Sache, von der jeder in der Tech-Branche weiß, dass sie bei jedem neuen Problem wichtig ist: der Fachjargon.

In Kapitel 2, "Bausteine", erklären wir, was das ganze Gerede über das Klima eigentlich bedeutet, angefangen mit Kohlenstoff. In diesem Buch verwenden wir den Begriff Kohlenstoff als Abkürzung für alle Treibhausgase, also alle Gase in der Atmosphäre, die Wärme binden. Die meisten dieser Gase kommen in der Natur vor, aber ihr Übermaß durch menschliche Aktivitäten führt dazu, dass wir den globalen Temperaturanstieg bekämpfen müssen, um diese lästigen Klimakatastrophen zu vermeiden.

Als Nächstes befassen wir uns mit . Hier findest du Wissen, das du in deiner Tasche haben solltest, um Freunde und Kollegen von der Wichtigkeit von Klimaschutzlösungen zu überzeugen. Wir erläutern den Unterschied zwischen Klima und Wetter, den Unterschied zwischen globaler Erwärmung und Klimawandel und wie die internationale Gemeinschaft das alles überwacht. Außerdem werden wir uns ansehen, wie die Treibhausgasprotokolle (d.h. Scope 1-, 2- und 3-Emissionen) auf Softwaresysteme angewendet werden.

Der nächste Baustein, den wir behandeln werden, ist die Elektrizität. Die meisten von uns haben in der Schule Elektrizität gelernt, und wenn du dich noch daran erinnerst, kannst du diesen Abschnitt überspringen. Für alle anderen, die eine Auffrischung brauchen (wie die Autorinnen und Autoren), werden wir die grundlegenden Konzepte von Elektrizität und Energie wiederholen und wie sie mit Software zusammenhängen. Wir werden auch kurz auf die Energieerzeugung eingehen und kohlenstoffreiche und kohlenstoffarme Energiequellen vergleichen.

Der letzte Baustein, den wir besprechen werden, ist die Hardware. Du fragst dich wahrscheinlich, warum du - sagen wir mal als Webentwickler - etwas über Hardware lernen musst. TL;DR. Aber das musst du.

Hardware ist für Software unverzichtbar, und jede Hardware ist mit Kohlenstoff verbunden, noch bevor sie deine Anwendung ausführt. Eingebetteter Kohlenstoff, der oft auch als "embodied carbon" bezeichnet wird, ist der Kohlenstoff, der bei der Herstellung und eventuellen Zerstörung eines Geräts ausgestoßen wird.

Im Jahr 2019 berichtete Apple, dass 85 % der mit einem iPhone verbundenen Kohlenstoffemissionen während der Produktions- und Entsorgungsphase des Geräts anfallen. Diese Zahl müssen wir alle bedenken, wenn wir Software entwerfen, entwickeln und einsetzen. Wir müssen dafür sorgen, dass diese Kohlenstoffinvestition besser funktioniert, und deshalb ist die Langlebigkeit der Geräte wichtig.

Aber was ist mit anderen Geräten, wie Servern? Worauf sollten wir achten, wenn wir eine Anwendung in einem Rechenzentrum vor Ort oder in der Cloud bereitstellen? Die gute Nachricht ist, dass in professionell betriebenen Rechenzentren die Serverhardware strenger verwaltet wird und weitaus mehr arbeitet als die Geräte der Nutzer. Als DC-Nutzer müssen wir uns um den Strom kümmern.

Kapitel 3: Kodex-Effizienz

In Kapitel 3, "Code-Effizienz", beschreiben wir, dass der Stromverbrauch einer Anwendung ungefähr davon abhängt, wie viel CPU/GPU sie nutzt oder indirekt verursacht. Die Verringerung der Verarbeitungsanforderungen einer Software ist daher der Schlüssel zur Senkung des Energieverbrauchs und der Kohlenstoffemissionen. Eine Möglichkeit, dies zu erreichen, ist die Verbesserung der Code-Effizienz.

Die Frage, die wir uns stellen müssen, lautet jedoch: Bringt die Code-Effizienz den grünen Dreh tatsächlich voran oder ist sie eine schmerzhafte Ablenkung? Ist sie sogar das umstrittenste Konzept der grünen Software?

Code-Effizienz ist knifflig

Das Problem mit ist, dass die Senkung der CPU/GPU-Nutzung zwar potenziell einen großen Einfluss auf die Kohlendioxidemissionen haben kann und gut bekannt ist - dieselben Techniken werden seit vielen Jahrzehnten im Hochleistungsrechnen (HPC) eingesetzt -, aber für Ingenieure einen hohen Aufwand bedeutet.

Wenn du zum Beispiel von Python auf eine viel effizientere Sprache wie Rust umsteigst, kannst du die Kohlendioxidemissionen um das Hundertfache reduzieren, aber das hat seinen Preis in der Produktivität.

Entwickler/innen liefern tatsächlich viel schneller, wenn sie Sprachen mit geringerer Maschineneffizienz wie Python verwenden. Daher ist das Schreiben von effizientem Code für Unternehmen unattraktiv, denn sie wollen ihre Entwicklerzeit auf die Entwicklung neuer Funktionen verwenden und nicht auf das Schreiben von effizienterem Code. Das kann es unmöglich machen, sie zu verkaufen.

Zum Glück gibt es Code-Effizienz-Optionen, die mit den Unternehmenszielen für Geschwindigkeit übereinstimmen. Dazu gehören:

• Verwaltete Dienste nutzen

• Bessere Tools, Bibliotheken oder Plattformen verwenden

• Einfach schlanker sein und weniger tun

Verwaltete Dienste nutzen

Später in diesem Buch werden wir die echten Vorteile der betrieblichen Effizienz von verwalteten Cloud- und Online-Diensten erörtern. Solche Dienste können ihre Plattform und Ressourcen mit Millionen von Nutzern teilen und eine extrem hohe Hardware- und Energienutzung erreichen. Wir vermuten jedoch, dass ihr größter potenzieller Gewinn in der Code-Effizienz liegt.

Die kommerzielle Prämisse hinter einem Managed Service ist einfach: Ein Unternehmen, das die nötige Größe und Nachfrage hat, um ihn zu rechtfertigen, tätigt die enormen Investitionen, die erforderlich sind, um den Betrieb und den Code effizient zu gestalten. Irritierenderweise verdient dieses Unternehmen dann eine Menge Geld mit dem Dienst, weil er billiger zu betreiben ist. Du hingegen bekommst die Code-Effizienz, ohne selbst in sie investieren zu müssen.

Machen wir uns nichts vor: Das ist ein attraktives Angebot.

Die Auswahl der richtigen Tools, Bibliotheken und Plattformen

Die effizienteste Alternative zu einem Managed Service vor Ort sollte eine gut optimierte Open-Source-Bibliothek oder ein Produkt sein. Das Problem ist nur, dass die meisten Anbieter bisher keinen Wert auf Energieeffizienz gelegt haben. Als Open-Source-Kunden müssen wir anfangen, dies zu fordern.

Weniger zu tun

Der effizienteste Code ist gar kein Code.

Wenn du das Guthaben eines Hyperscalers nicht durch die Nutzung eines seiner voroptimierten Dienste aufbessern willst, ist eine attraktive Alternative, weniger zu tun. Adrian Cockcroft, ehemaliger VP of Sustainable Architecture bei AWS, meint: "Der größte Gewinn ist oft die Änderung von Anforderungen oder SLAs [Service Level Agreements]. Reduziere die Aufbewahrungszeit für Logdateien. Lockere überspezifizierte Ziele."¹

Der beste Zeitpunkt, um unnötige Arbeit zu erkennen, ist früh im Produktentwicklungsprozess, denn sobald du jemandem ein SLA oder eine Funktion versprochen hast, ist es schwieriger, sie zurückzunehmen. Manchmal sind überspezifizierte Ziele (z. B. Vorschriften, die eingehalten werden müssen) unvermeidlich, aber oft sind sie eher intern getrieben als eine Reaktion auf externen Druck oder echte Nutzerbedürfnisse. Wenn das in deinem Unternehmen der Fall ist, solltest du deinen Produktmanager bitten, sie so lange zurückzustellen, bis du weißt, dass du sie brauchst.

Was ist, wenn du es wirklich nicht kaufen oder fallen lassen kannst und es selbst bauen musst?

Wenn du es wirklich selbst machen musst, gibt es mehrere Optionen für CPU-lastige Aufträge, die zu Zeiten mit hoher Kohlenstoffintensität laufen müssen:

• Ersetze ineffizienten eigenen Code durch effiziente Dienste oder Bibliotheken.

• Ersetze ineffiziente Dienste oder Bibliotheken durch bessere.

• Schreibe den Code um, um eine leichtere Plattform, ein Framework oder eine Sprache zu verwenden. Es ist bekannt, dass der Wechsel von Python zu Rust die CPU-Anforderungen um das Hundertfache senken kann, und Rust hat Sicherheitsvorteile gegenüber den klassischen Code-Effizienzoptionen von C oder C++.

• Schau dir neue Sprachalternativen wie Cython oder Mojo an, die darauf abzielen, C-ähnliche Geschwindigkeit mit besserer Benutzerfreundlichkeit zu kombinieren.

• Ziehe in Erwägung, die Arbeit auf Client-Geräte zu verlagern, bei denen die lokale Batterie eine gewisse Hoffnung hat, wieder aufgeladen zu werden. (Allerdings ist das nicht ganz einfach. Wenn es darum geht, eine Menge zusätzlicher Daten zu übertragen, oder wenn es den Nutzer dazu ermutigt, sein Gerät aufzurüsten, oder wenn die Arbeit etwas ist, das dein Rechenzentrum mit seiner Hardware effizienter erledigen kann, dann kann es schlechter sein, sie auf ein Gerät zu übertragen. Wie immer muss das Design durchdacht werden, und wahrscheinlich muss das Produktmanagement mit einbezogen werden).

• Achte darauf, dass deine Richtlinien zur Speicherung von Daten sparsam sind. Datenbanken sollten optimiert werden (die gespeicherten Daten sollten minimiert und die Abfragen optimiert werden).

• Vermeide die übermäßige Verwendung von Ebenen. Die Verwendung einiger Servicemeshes kann zum Beispiel so aussehen, als würde man Bitcoin auf seinen Servern schürfen.

Berücksichtige den Kontext

Die Bereitstellung energieeffizienter Software ist eine Menge Arbeit. Konzentriere dich deshalb auf die Anwendungen, die wichtig sind, weil sie viel genutzt werden und immer eingeschaltet sein muss.

"Der Umfang ist entscheidend", sagt Paul Johnston von der Klimakampagne . "Wenn du einen großen Cloud-Dienst aufbaust, dann hole alles aus deiner Programmiersprache heraus, was du kannst. Wenn du ein internes Tool entwickelst, das von vier Leuten und dem Bürohund genutzt wird, ist es irrelevant, ob es 10 MWh Strom verbraucht."²

Grün durch Design

Softwaresysteme können so gestaltet werden, dass sie kohlenstoffbewusster, energieeffizienter oder hardwareeffizienter sind, und die Auswirkungen eines besseren Designs überwiegen oft die Auswirkungen des Codes. Das alles gibt es jedoch nicht umsonst.

Grün zu sein bedeutet, dass du ständig über dein Design nachdenkst und es überarbeitest, anstatt es einfach weiterzuentwickeln. Es ist also an der Zeit, das Whiteboard zu entstauben und den grünen Stift hervorzuholen, der zum Glück der einzige ist, der noch Tinte hat.

Kapitel 4: Betriebliche Effizienz

Wir behandeln die betriebliche Effizienz in Kapitel 4, "Betriebliche Effizienz", das wohl das wichtigste Kapitel des Buches ist.

Bei derbetrieblichen Effizienz geht es darum, mit weniger Maschinen und Ressourcen die gleiche Leistung zu erzielen. Dies kann die Kohlendioxidemissionen um das Fünf- bis Zehnfache senken und ist vergleichsweise einfach, denn wie wir später noch erläutern werden, gibt es bereits Dienste und Tools, die die betriebliche Effizienz unterstützen, insbesondere in der Cloud.

Fühle dich aber nicht ausgeschlossen, wenn du ein On-Premise-Hosting betreibst. Viele der Techniken, wie z. B. eine hohe Maschinenauslastung, gute Betriebsverfahren und Multitenancy, können auch bei dir funktionieren.

Hohe Maschinenauslastung

Der wichtigste Weg, um die Emissionen pro Einheit nützlicher Arbeit zu reduzieren, ist die Verringerung des Leerlaufs. Wir müssen Systeme mit einer höheren Auslastung von Prozessoren, Arbeitsspeicher, Festplattenplatz und Netzwerk betreiben. Dies wird auch als Betrieb mit hoher Serverdichte bezeichnet und verbessert sowohl die Energie- als auch die Hardwareeffizienz.

Ein gutes Beispiel dafür ist die Arbeit, die Google in den letzten 15 Jahren geleistet hat, um seine interne Systemauslastung zu verbessern. Durch die Kapselung von Aufträgen in Containern, die detaillierte Kennzeichnung von Aufgaben und ein Zeitplannungsprogramm, das sogenannte Cluster Scheduler, packt Google seine verschiedenen Arbeitslasten wie Tetris-Spielsteine auf die Server. Das Ergebnis ist, dass Google viel weniger Hardware und Strom verbraucht (möglicherweise weniger als ein Drittel als sonst).

Hinweis

Du kannst alles über Googles Arbeit in einem faszinierenden Artikel nachlesen, der vor einem Jahrzehnt veröffentlicht wurde. Die Autoren gaben dem Zeitplannungsprogramm auch einen tollen Namen: Borg. Die Lektüre des Google Borg-Papiers hat Annes Leben verändert und sie auf eine Reise in die Welt der effizienten Technologien geschickt, also sei gewarnt.

Übrigens: Aus Borg ist schließlich Kubernetes entstanden.

Multitenancy

Alle Public Cloud-Provider investieren stark in die betriebliche Effizienz. Daher kann der beste nachhaltige Schritt, den du heute machen kannst, darin bestehen, deine Systeme in die Cloud zu verlagern und ihre Dienste zu nutzen.

Der hohe Grad an Mandantenfähigkeit, d.h. die gemeinsame Nutzung von Rechnern durch mehrere Nutzerinnen und Nutzer, ermöglicht es, dass die Auslastung der Rechner in der Cloud deutlich höher ist als in der Cloud. Möglicherweise erreichen sie eine Auslastung von mehr als 65 % im Vergleich zu durchschnittlich 10-20 % in der Cloud (wenn du allerdings nur "lift and shift" auf dedizierte Cloud-Server machst, wirst du von diesem Vorteil nicht viel haben).

Die Hyperscaler erreichen dies, indem sie ihre verschiedenen Workloads auf große Server packen und dabei ihre eigenen intelligenten Orchestratoren und Zeitplannungsprogramme einsetzen, sofern sie dazu in der Lage sind (d.h. wenn du sie nicht durch die Angabe von dedizierten Servern in die Schranken weist).

Wenn du eine gut durchdachte Microservices-Architektur verwendest, kann die Auslastung mit einem Zeitplannungsprogramm für Consumer-Cluster deutlich erhöht werden - zum Beispiel mit dem Kubernetes-Zeitplannungsprogramm oder Nomad von HashiCorp.

Die Zeitplannungsprogramme, die für die Maschinenauslastung optimiert sind, benötigen gekapselte Aufträge (in der Regel Aufträge, die in einer VM, einem Container oder einer serverlosen Funktion verpackt sind), die auf einer Orchestrationsschicht laufen, die sie starten oder stoppen oder von Maschine zu Maschine verschieben kann.

Um gut packen zu können, ist es außerdem wichtig, dass Orchestratoren und Zeitplanungsprogramme genug wissen, um intelligente Entscheidungen über die Platzierung von Aufträgen zu treffen. Je mehr ein Zeitplannungsprogramm über die Aufträge weiß, die es plant, desto besser kann es die Ressourcen nutzen. In Clouds kannst du die Eigenschaften deiner Workloads durch die Wahl der richtigen Instanztypen kommunizieren und solltest vermeiden, deine Ressourcen- oder Verfügbarkeitsanforderungen zu hoch zu spezifizieren (z. B. indem du eine dedizierte Instanz verlangst, obwohl eine Burstable-Instanz ausreichen würde).

Hochgradig mandantenfähige Serverless-Lösungen wie Lambda-Funktionen auf AWS, Azure-Funktionen oder Google Serverless können ebenfalls hilfreich sein, um den Hardware-Footprint zu minimieren. Serverlose Lösungen bieten auch andere betriebliche Effizienzfunktionen wie automatische Skalierung (Hardware-Ressourcen werden nur dann aktiviert, wenn sie benötigt werden) und automatische Rechtevergabe.

Es ist zwar möglich, diese Art von cleveren Betriebsabläufen auf deinem eigenen On-Premise-System zu realisieren, aber es kostet dich viel Zeit und Geld, um das gleiche Ergebnis zu erzielen. Für Cloud-Provider ist das ihr Hauptgeschäft und daher die Zeit und das Geld wert. Gilt das auch für dich?

Gute betriebliche Praxis

Einfachere Beispiele für betriebliche Effizienz sind das Vermeiden einer Überbelegung von Systemen (z. B. das manuelle Verkleinern von Maschinen, die größer als nötig sind) oder die Verwendung von Autoscaling, um eine Belegung zu vermeiden, bevor sie benötigt wird.

Noch einfacher ist es, Anwendungen und Dienste, die nichts mehr tun, zu schließen. Die Nachhaltigkeitsexpertin Holly Cummins, Ingenieurin bei Red Hat, bezeichnet sie als "Zombie-Workloads". Lass sie nicht "nur für den Fall der Fälle" herumhängen.

Wenn du dir nicht die Mühe machen kannst, das Starten und Stoppen eines Servers zu automatisieren, ist das ein Zeichen dafür, dass er nicht mehr wertvoll ist. Nicht gewartete Zombie-Workloads sind nicht nur ein Sicherheitsrisiko, sondern auch schlecht für die Umwelt. Schalte sie ab.

Grüne betriebliche Instrumente und Techniken

Selbst wenn du deine Workloads in einer Cloud laufen lässt (d.h. von jemand anderem betrieben wird), gibt es immer noch Konfigurationen für die betriebliche Effizienz, die du unterkontrollieren kannst:

• Spot-Instances auf AWS oder Azure (preemptible Instances auf GCP) sind ein wesentlicher Bestandteil der hohen Auslastung der öffentlichen Clouds. Sie geben Orchestrierern und Zeitplannungsprogrammen die Möglichkeit zu entscheiden, wann Aufträge ausgeführt werden, und helfen so, sie auf Maschinen zu packen. Kurzfristig wird die Verwendung von Spot-Instanzen überall dort, wo es möglich ist, deine Systeme hardware- und stromeffizienter und viel billiger machen. Längerfristig werden deine Systeme dadurch klimabewusster, denn Spot-Instanzen ermöglichen es einem Cloud-Provider, Arbeitslasten in Zeiten zu verlagern, in denen der Strom im lokalen Stromnetz weniger kohlenstoffintensiv ist (wie Google in seinem kürzlich erschienenen Papier zum kohlenstoffbewussten Betrieb von Rechenzentren beschreibt).

• Eine Überbelegung verringert die Effizienz von Hardware und Energie. Maschinen können z. B. mit dem AWS Cost Explorer oder der Kostenanalyse von Azure angepasst werden, und eine einfache Prüfung kann oft Zombie-Dienste identifizieren, die abgeschaltet werden müssen.

• Eine übermäßige Redundanz kann auch die Effizienz der Hardware verringern. Oft verlangen Organisationen eine Duplizierung über Regionen hinweg für Hot Failover, obwohl ein Cold Failover plus GitOps gut genug wäre.

• Autoscaling minimiert die Anzahl der Maschinen, die benötigt werden, um ein System ausfallsicher zu betreiben. Sie kann an die CPU-Auslastung oder den Netzwerkverkehr gekoppelt werden und lässt sich sogar vorausschauend konfigurieren. Erinnere dich daran, dass die Autoskalierung sowohl nach unten als auch nach oben funktioniert, sonst ist sie nur beim ersten Mal nützlich! AWS bietet eine hervorragende Einführung in die Autoskalierbarkeit von Microservices. Wenn die Komplexität der Architektur durch eine zu große Anzahl von Microservices zunimmt, kann dies jedoch zu einer Überversorgung führen. Hier gibt es ein Gleichgewicht. Versuche, es trotzdem einfach zu halten. Lies das Buch Building Microservices von Sam Newman, um dich über bewährte Methoden zu informieren.

• Always-on oder dedizierte Instance-Typen sind nicht umweltfreundlich. Wenn du dich für Instance-Typen entscheidest, die dem Hoster mehr Flexibilität und vor allem mehr Informationen über deine Arbeitslast geben, kannst du die Maschinenauslastung erhöhen und die CO2-Emissionen und Kosten senken. AWS T3-Instanzen, Azure B-Series und Google Shared-Core-Maschinentypen bieten zum Beispiel interessante Bursting-Funktionen, die eine einfachere Alternative zur automatischen Skalierung darstellen können.

Es ist erwähnenswert, dass Architekturen, die Aufgaben mit niedriger Priorität und/oder verzögerbaren Aufgaben erkennen, bei hoher Maschinenauslastung leichter zu betreiben sind. In Zukunft werden dieselben Architekturen besser in der Lage sein, Kohlenstoff zu erkennen. Dazu gehören serverlose, Microservice- und andere asynchrone (ereignisgesteuerte) Architekturen.

Laut Paul Johnston von , dem Evangelisten für grüne Technologien, ist "Always on" unhaltbar. Das könnte der Todesstoß für einige schwergewichtige Legacy-Monolithen sein.

Reporting Tools

Die Hosting-Kosten waren schon immer ein Indikator für die Kohlenstoffemissionen. Sie werden in Zukunft wahrscheinlich noch stärker miteinander korrelieren, da die Cloud immer mehr zur Massenware wird, Strom ein wichtiger Kostenfaktor bleibt und schmutziger Strom durch dynamische Preise teurer wird. Inzwischen gibt es auch gezieltere Tools zur Berichterstattung über den CO2-Fußabdruck. Sie sind rudimentär, aber besser als nichts, und wenn sie genutzt werden, werden sie auch verbessert. Also nutze sie.

Kapitel 5: Carbon Awareness

In Kapitel 5, "Carbon Awareness", werden wir die Merkmale eines starken Designs aus der Perspektive des Carbon Awareness behandeln:

• Wenig oder nichts ist "immer an".

• Aufträge, die nicht zeitkritisch sind (z. B. maschinelles Lernen oder Batch-Aufträge), werden aufgeteilt und asynchron berechnet, damit sie zu Zeiten ausgeführt werden können, in denen die Kohlenstoffintensität des Stroms im lokalen Netz niedrig ist (z. B. wenn die Sonne scheint und das Netz nicht bereits stark belastet ist). Diese Technik wird oft als Nachfrageverschiebung bezeichnet, und wie wir bereits erwähnt haben, eignen sich Spot- oder Preemptible-Instanzen besonders gut dafür.

• Das Angebot deiner Dienste ändert sich je nach Kohlenstoffintensität des lokalen Netzes. Das nennt man Demand Shaping. In Zeiten kohlenstoffarmer Stromerzeugung wird zum Beispiel die volle Funktionalität angeboten, aber in Zeiten kohlenstoffreichen Stroms wird dein Dienst schrittweise heruntergefahren. Viele Anwendungen gehen ähnlich vor, um mit Schwankungen in der Bandbreitenverfügbarkeit umzugehen, z. B. indem sie die Bildqualität vorübergehend herabsetzen.

• Wirklich zeitkritische, immer aktive Aufgaben, die unweigerlich Strom mit hoher Kohlenstoffintensität benötigen, werden so effizient geschrieben, dass sie so wenig wie möglich davon verbrauchen.

• Aufträge werden nicht mit höherer Dringlichkeit als nötig ausgeführt, wenn sie also auf sauberen Strom warten können, werden sie es tun.

• Wo es möglich ist, werden die Berechnungen auf Endnutzergeräte und die Kanten verlagert, um den Netzwerkverkehr zu minimieren, den Bedarf an On-Demand-Prozessen in Rechenzentren zu reduzieren und die in den Gerätebatterien gespeicherte Energie voll auszunutzen. Es gibt noch weitere Vorteile: P2P, offline-first Anwendungen machen zentrale Dienste mit einem hohen Prozentsatz an Betriebszeit überflüssig und erhöhen die Widerstandsfähigkeit der Anwendungen gegenüber Netzwerkproblemen und sinkenden Latenzzeiten.

• Algorithmische Vorberechnungen und Pre-Caching werden verwendet: CPU- oder GPU-intensive Berechnungen werden durchgeführt und gespeichert, bevor sie benötigt werden. Das mag manchmal ineffizient erscheinen (Berechnungen können weggeworfen oder überflüssig werden, bevor sie gebraucht werden), aber eine intelligente Vorberechnung kann nicht nur die Reaktionszeiten beschleunigen, sondern auch die Hardwareeffizienz erhöhen und dazu beitragen, die Arbeit auf Zeiten zu verlagern, in denen weniger Strom verbraucht wird.

Diese Marker basieren oft auf einer Microservices- oder einer verteilten Systemarchitektur, aber das ist nicht zu 100% erforderlich.

Kapitel 6: Hardware-Effizienz

In Kapitel 6, "Hardware-Effizienz", stellen wir fest, dass bei Software, die auf Benutzergeräten und nicht auf Servern läuft, der Kohlenstoffausstoß bei der Herstellung dieser Geräte massiv höher ist als der Ausstoß bei ihrer Nutzung (siehe Abbildung 1-2).

Abbildung 1-2. Direkte Auswirkungen der_{CO2-Emissionen} pro IKT-Endnutzergerät (basierend auf Daten der Universität Zürich)

Hinweis

Nein, wir wissen auch nicht, was ein FTP-Fernseher ist. Wir vermuten, dass es ein Smart TV ist. Die Treibhausgasemissionen dieses Geräts scheinen problematischer zu sein, als wir es uns vorgestellt haben.

Deshalb müssen die Geräte der Nutzer/innen in einer CO2-freien Welt in Zukunft sehr viel länger halten. Das liegt zum Teil am Design und der Herstellung, aber auch an der Vermeidung von softwarebedingter Veralterung, die durch Betriebssysteme und Anwendungen verursacht wird, die keine Sicherheits-Patches mehr bereitstellen oder von neuer Hardware oder Funktionen abhängen.

Im Laufe der Zeit bedeuten das Mooresche Gesetz ( ) und andere Formen des Fortschritts, dass die Anzahl der Transistoren auf einem Mikrochip alle zwei Jahre verdoppelt wird, dass die Geräte immer neue Funktionen erhalten, die Entwickler/innen in ihren neuen Apps nutzen wollen. Mobiltelefone sind zum Beispiel schneller geworden, haben spezielle Grafikprozessoren und Chips für maschinelles Lernen bekommen und verfügen über mehr Speicher. Apps machen sich diesen Fortschritt zunutze, und das ist gut so. Allerdings ist es wichtig, dass diese Apps auch auf älteren Handys ohne die neuen Funktionen funktionieren, damit sie nicht zu einer vermeidbaren, softwarebedingten Veralterung beitragen.

Damit die Nutzer/innen nicht dazu ermutigt werden, funktionierende Technik wegzuwerfen, ist es unerlässlich, dass die Entwickler/innen neue Software entwickeln, die mit bestehenden Geräten abwärtskompatibel ist. Telefon-Betriebssysteme stellen zwar einige Informationen und Tools zur Verfügung, die dabei helfen, aber in der Regel müssen die Entwickler selbst aktiv werden.

Im Moment könnte Apple das große Unternehmen sein, das am besten verhindern kann, dass Software die Geräte zerstört. Das neue iOS 15 unterstützt Telefone, die bis zu sechs Jahre alt sind. Aber alle Anbieter müssen sich verbessern. Die Lebenserwartung der Geräte muss viel länger sein als sechs Jahre. Fairphone, ein Nischenanbieter, bietet bereits Sicherheitspatches für das Betriebssystem für acht Jahre an und hat sich zehn Jahre zum Ziel gesetzt, was beweist, dass es möglich ist.

Alle aktuellen Handys werden in Sachen Langlebigkeit von den meisten Spielkonsolen übertroffen. Die Xbox One zum Beispiel wurde für eine Lebensdauer von 10 Jahren konzipiert, und dieses Versprechen scheint sich zu bewahrheiten. Das Geschäftsmodell für Spielkonsolen beinhaltet nicht so viel geplante Verfügbarkeit des Produkts wie das Geschäftsmodell für Telefone. Das zeigt, dass die Geräte länger halten können, wenn die Hersteller es wollen. Wir glauben, dass die Lebenserwartung aller neuen Geräte von nun an mindestens 10 Jahre betragen sollte.

Kapitel 7: Networking

In Kapitel 7, "Vernetzung", sprechen wir über die Auswirkungen der Vernetzung und des Internets auf die Kohlendioxidemissionen und erörtern, wie Produkte wie Videokonferenzdienste, die mit schwankenden Bandbreiten umgehen müssen, nützliche Beispiele aus der Praxis für die Verlagerung und Gestaltung der Nachfrage liefern.

Bei Netzwerkwerkzeugen und -geräten wie Glasfaserkabeln, Routern und Switches war die Minimierung der Wattzahl pro übertragenem Bit schon immer ein grundlegendes Ziel. Verglichen mit dem Rest der Branche ist die Netzwerktechnik daher bereits sehr energieoptimiert und macht nur einen kleinen Teil der Stromrechnung und der Kohlenstoffemissionen eines modernen Rechenzentrums aus.

Die Art und Weise, wie die meisten Anwendungen diese Netze nutzen, ist jedoch noch stark verbesserungswürdig. Für sie war Watt/Bit wahrscheinlich kein Entwicklungsziel.

Der aufstrebende Bereich der grünen Software kann eine Menge von der Telekommunikation lernen.

Kapitel 8: Grüneres maschinelles Lernen, KI und LLMs

In Kapitel 8, "Grüneres maschinelles Lernen, KI und LLMs", befassen wir uns mit der neuen Welt der KI und des maschinellen Lernens (ML), die zu einem enormen Anstieg der rechenintensiven Arbeit führt und einen massiven Ausbau der Rechenzentrumskapazität auslöst. Deshalb brauchen wir Strategien für grüne KI.

Wir besprechen Techniken wie das schnellere und effizientere Trainieren von ML-Modellen durch Verkleinerung der Modellgröße, föderiertes Lernen, Pruning, Komprimierung, Destillation und Quantisierung.

ML profitiert auch von den schnellen Fortschritten bei spezieller Hardware und Chips, und wir sollten versuchen, die Hardware zu verwenden, die für die jeweilige Trainingsaufgabe am besten geeignet ist.

Vor allem aber sind ML-Modelle ein gutes Beispiel für Aufträge, die nicht latenzempfindlich sind. Sie müssen nicht mit kohlenstoffintensivem Strom trainiert werden.

Kapitel 9: Messung

Chris Adams von der Green Web Foundation ( ) erklärt: "Das Problem ist nicht nur, dass die Entwickler nicht kohlenstoffeffizient sein wollen, sondern auch, dass sie auf einen Mangel an Daten stoßen, insbesondere bei den großen Cloud-Providern, um zu sehen, was tatsächlich effektiv ist. Die Modellierung basiert daher oft auf Annahmen."³

Kurzfristig ist es besser, eine Vermutung anzustellen als nichts. Allgemeine Maßnahmen wie die Umstellung auf mandantenfähige Umgebungen und die Verringerung der CPU-Intensität von zeitkritischem Code sind effektiv. Längerfristig brauchen die Entwickler jedoch die richtigen Überwachungs-Tools, um den Energieverbrauch zu kontrollieren.

Kapitel 10: Überwachung

Die Überwachung der Emissionen von Softwaresystemen steckt noch in den Kinderschuhen aber es werden immer mehr Tools auf den Markt kommen, und wenn es soweit ist, müssen wir unbedingt von den Fortschritten lernen, die die Tech-Industrie in den letzten zehn Jahren bei der effektiven Systemüberwachung gemacht hat, und sie auf die Umwelt anwenden.

In Kapitel 10 besprechen wir das Site Reliability Engineering (SRE) und wie es bei der Budgetierung deiner Kohlenstoffemissionen angewendet werden kann.

Kapitel 11: Co-Benefits

In Kapitel 11, "Co-Benefits", sprechen wir über die Nebeneffekte eines grünen Software-Ansatzes wie Kosteneinsparungen, erhöhte Sicherheit und bessere Ausfallsicherheit.

Während wir auf bessere Reporting-Tools warten, sind die Kosten ein nützliches Maß für die Kohlenstoffemissionen. Dabei handelt es sich um einen Weg für Teams, ihre Hosting-Kosten zu verwalten, bei dem jeder (über funktionsübergreifende Teams in der IT, Finanzabteilung, Produktabteilung usw.) die Verantwortung für seine Ausgaben übernimmt und von einer zentralen Gruppe für bewährte Methoden unterstützt wird.

Dennoch gibt es einen großen Vorteil, wenn du die Kohlenstoffkosten mit Hilfe von Carbon Footprint Tools und nicht mit FinOps Tools misst. Irgendwann - hoffentlich so bald wie möglich - werden diese Tools auch die Kohlenstoffbelastung des Stroms berücksichtigen, der tatsächlich für den Betrieb deiner Server verwendet wird. Im Moment zahlst du in Regionen mit kohlenstoffarmem Strom wie Frankreich (Atomkraft) oder Skandinavien (Wasser- und Windkraft) oft genauso viel wie in Regionen mit kohlenstoffreichem Strom wie Deutschland. Allerdings sind deine Kohlendioxidemissionen in den erstgenannten Regionen niedriger und in den letzteren höher. Ein Carbon Footprint Tool wird das widerspiegeln. Ein FinOps-Tool nicht.

Kapitel 12: Die Green Software Maturity Matrix

In Kapitel 12, "Die Green Software Maturity Matrix", besprechen wir das Green Software Maturity Matrix (GSMM) Projekt der Green Software Foundation. Die meisten von uns müssen von Stufe 1 auf der Matrix (gerade erst mit effizienten und bedarfsgerechten Systemen begonnen) zu Stufe 5 aufsteigen (Systeme, die rund um die Uhr mit kohlenstofffreiem Strom laufen können).

Die GSMM behauptet, dass wir mit der Verbesserung der betrieblichen Effizienz beginnen und die Code-Effizienz bis zum Schluss aufsparen sollten, wenn wir sie hoffentlich von der Stange kaufen können. Tatsächlich stimmt die GSMM in bemerkenswerter Weise mit unseren eigenen Vorschlägen überein.

Kapitel 13: Wie geht es jetzt weiter?

Im letzten Kapitel werden wir dich vor eine Herausforderung stellen. Wir möchten, dass du deine Hostingkosten (und damit auch deine Kohlenstoffkosten) innerhalb der nächsten 6-12 Monate halbierst und geben dir einige Vorschläge, wie du das schaffen kannst. Das ist kein triviales Ziel, aber es ist erreichbar und ein notwendiger erster Schritt, um in der Green Software Maturity Matrix voranzukommen.

Zum Schluss wollen wir dir sagen, was wir drei beim Schreiben dieses Buches über grüne Software gelernt haben: Sie ist keine Nische. Sie ist das, was jede Software von nun an sein muss.

Grüne Software muss daher alle unsere Bedürfnisse erfüllen. Sie muss für Entwickler produktiv , belastbar , zuverlässig , sicher , leistungsfähig , skalierbar und günstig sein. Zu Beginn dieses Kapitels haben wir gesagt, dass grüne Software CO2-effizient und -bewusst ist, aber das ist nur ein Teil der Geschichte. Grüne Software muss nicht nur kohlenstoffsparend und effizient sein , sondern auch all unsere anderen Bedürfnisse erfüllen. Aber das ist machbar. Es geschieht bereits.

Die Geschichte der grünen Software ist nicht nur düster, sondern auch düster. Unserer Meinung nach ist die Umstellung auf grüne Software die interessanteste und herausforderndste Sache, die es in der Tech-Branche derzeit gibt. Es wird alles verändern und jeden betreffen. Es ist wichtig und es ist lösbar.

Also, viel Glück und viel Spaß dabei, die Welt zu verändern.

¹ Adrian Cockcroft, persönliche Mitteilung.

² Paul Johnston, persönliche Mitteilung.

³ Chris Adams, persönliche Mitteilung.