Um Berechnungen durchführen zu können, muss die Software die zugrunde liegende Hardware nutzen und verbraucht daher Energie.

Der Energieverbrauch ist oft nicht einfach zu ermitteln. Wenn Sie CPU-/GPU-intensive Lasten haben, wie beim High Performance Computing oder beim Bitcoin-Mining, ist der Energieverbrauch oft identisch mit der thermischen Leistung Ihres Chips.

Bei der alltäglichen Nutzung von Software ist der Fall jedoch ganz anders. Viele Faktoren tragen zu dem oft verschwenderischen Energieverbrauch von Software bei und sind oft von der reinen Zeit, in der eine Software läuft, entkoppelt:

Boot-Zeit

Moderne Software läuft virtualisiert oder containerisiert. Diese virtuellen Maschinen müssen gebootet werden. Die Kosten für dieses ständige Hoch- und Runterfahren sind für den Benutzer und oft auch für den Entwickler nicht sichtbar.

Infrastruktur

Dieser Punkt ist mit der Boot-Zeit verwoben, hat aber genug Potenzial, um gesondert erwähnt zu werden. Moderne Software wird zumindest in einem Hypervisor virtualisiert, wenn nicht sogar in einer VM oder einem zusätzlichen Container. Diese Technik löst viele Probleme in Bezug auf die Verschwendung von Ressourcen, bringt aber auch Herausforderungen wie Overhead mit sich. Die Infrastruktur ist oft suboptimal gewählt, überdimensioniert oder zu undurchsichtig, um sie zu analysieren.

Hintergrundaktivitäten

Nach der Benutzerinteraktion muss die Software Hintergrundaufgaben erledigen. Sei es Cronjobs, ML-Training, Stream-Verarbeitung usw.

Leerlaufzeit

Auch im Zeitalter der Virtualisierung haben Maschinen oft erhebliche Leerlaufzeiten. In der Benutzerlandschaft wird dies oft mit Schlafmodi kompensiert. In der Server Welt gibt es typischerweise keine Energiesparmodi.

Prozessenergie

Software kann so schnell sein, dass es nicht wahrnehmbar ist, ob die Nutzung 10ms oder 100ms betrug. Dennoch kann der Energieunterschied enorm sein und ist schwer abzuschätzen, wenn er hochskaliert wird.

Unsere Arbeit

Um all diese getrennten Bereiche für die EntwicklerInnen sichtbar zu machen, entwickeln wir Open-Source-Tools, die den Energieverbrauch sichtbar machen.

Für nutzerorientierte Anwendungen in der Desktop-, Web- und mobilen Welt entwickeln wir ein Tool zur Messung des gesamten Anwendungslebenszyklus auf der Grundlage eines eines Standardnutzungsszenarios: Das Green Metrics Tool

Durch die Verknüpfung von der Version des Codes und eines Nutzungsszenarios können wir verschiedene Software miteinander vergleichbar machen.

In Cloud-Umgebungen mit verteilten Architekturen ist die Verwendung eines Benchmarking-Tools sehr umständlich und nicht wirklich sinnvoll.

Hier werden Inline-Messungen benötigt, die in bereits existierende Beobachtungslösungen exportiert werden können, und auch vorausschauende Schätzungen, die architektonische Optimierungen vorantreiben können (z. B. welcher Dienst zu verwenden ist oder ob ein Wechsel zu Serverless von Vorteil ist).

Anhand von Fallstudien wollen wir auch die Overhead-Kosten der Virtualisierung aufzeigen und Metriken bereitstellen, um fundierte Entscheidungen zu treffen, welches Architekturmodell am besten in eine energiebewusste Unternehmenskultur passt.

Sehen Sie sich auch unsere Projekte

Netzübertragungen rücken als einer der Hauptverursacher von Software-Emissionen immer mehr in Focus als einer der Hauptverursacher der CO2 Emmisonen von Software zu sein.

Großartige Tools wie Websitecarbon.com ermöglichen die Sichtbarkeit der Kosten für eine typische Website-Anfrage.

Heutzutage wird dies in der Regel durch das Herunterbrechen der Komplexität in eine sehr fehleranfällige Formel erreicht. Siehe unseren Artikel über CO2-Formeln für weitere Einzelheiten.

Die Problematik der Netzwerkemissionen liegt nicht in ihrer Existenz, sondern in ihrer Unsichtbarkeit.

In der Anfangszeit des Internets wurde die Netzübertragung sehr genau gemessen, da danach abgerchnet wurde. Durch die Einführung von Flatrates konnte das Internet seine Akzeptanz erhöht und wurde allgegenwärtig.

Flatrates haben jedoch zu einer Abkopplung vom Netzwerkverkehr und den Emmissonen geführt. Dies führt zu einer Entkopplung und dem Missverständnis, dass jede Nutzung des Netzes irgendwann zu einem bestimmten Zeitpunkt zu einem Anstieg der Kohlenstoffemissionen führt. Manchmal linear, manchmal in Stufen. (Siehe Gigabytes zu kWh)

Da Sie Ihren Verbrauch nicht sehen, wie zum Beispiel bei Ihrer Telefonrechnung, gehen Sie das Risko die Resource nicht mehr zu beachten. Das Gleiche gilt für das Essen am Buffet, wo Reste die Regel sind.

Die Lösung liegt unserer Meinung nach darin, diese Ressource sichtbarer zu machen und einen nachhaltigeren Umgang mit ihr zu finden.

Unsere Arbeit

Wir befassen uns derzeit mit diesem Thema, indem wir Entwickler durch Meetups und durch Vorträge auf Konferenzen oder Coding Bootcamps wie WBS Coding School

Auf der technischen Seite heben wir die Netzwerkemissionen in unserem Green Metrics Tool hervor und zeigen Empfehlungen wie:

• Verlagerung von Mobilfunk- zu Festnetzanschlüssen
• Demand Shifting, um Netzwerkanfragen zu CO2 freundlichen Zeiten zu erledigen
• Verwendung von Kompressionstechniken
• Änderung von Verbindungsformaten wie HTTP -> HTTP2
• NICHT liefern von Inhalten, die keinen großen Nutzen haben
• Verringerung der Aktualisierungszyklen und Abfrageintervalle