Warum beschäftigen wir uns damit, ob wir Dinge messen können? Unser Slogan ist zwar “Architecting your Business” aber wir sind doch kein Architekturbüro …
Dinge verbessern zu wollen, liegt uns IT-Menschen im Blut - wenn man nach den Sternen greift, möchte man natürlich am liebsten die Welt verbessern. Mit dieser Idee haben wir als p-sustainabilities auch angefangen - eine Gruppe innerhalb von pentacor, die es sich zur Aufgabe macht, pentacor grüner, nachhaltiger und umweltverträglicher zu gestalten. Nach einer Weile hatten wir alle Low-hanging-Fruits bearbeitet, haben jetzt regionale Getränke im Kühlschrank, Bio-Frühstück auf dem Tisch und gehen vermutlich alle ein bisschen bewusster mit dem Thema Nachhaltigkeit um. Selbstverständlich bleibt auch das Licht abends im Büro so lange wie möglich aus (nicht nur aus Nachhaltigkeitsgründen, ITler mögen ja bekanntlich kein Licht).
Aber irgendwie fühlte sich das alles nicht so richtig nach Weltrettung an. Wo also gibt es Hebel, die wirklich Impact erzielen können? Wir haben für uns identifiziert, dass wir als Unternehmen einen größeren Impact erzielen können, indem wir das Thema Green IT bei unseren Kunden platzieren, für sie relevant machen und ihnen so auch helfen, selbst relevant, wettbewerbsfähig und am Geist der Zeit zu bleiben. Nebenbei tun wir dabei Gutes für unser aller Lebensgrundlage. Gründe genug, Green IT bei pentacor als wichtiges Thema zu betrachten, auch wenn unsere Kunden (bisher) noch nicht direkt danach gefragt haben.
Es reichte uns nicht, diverse Möglichkeiten zu kennen, Code im Sinne von Green IT zu entwickeln, und wir haben weiter überlegt, wie wir mehr Impact erzielen können. Für uns ist eine Voraussetzung, um wirklich etwas bewegen zu können, zu wissen, welche Auswirkungen Änderungen haben. Also haben wir uns gefragt, wie wir den Status Quo und den (zukünftig) erzielten Impact messen und miteinander vergleichen können.
Beschäftigt man sich mit dem Thema Nachhaltigkeit, kommt man relativ schnell an verschiedenen Messgrößen wie Stromverbrauch, Wasserverbrauch und CO2-Ausstoß vorbei. Taucht man tiefer in das Thema ein, wird schnell deutlich, dass alle Messgrößen durch den CO2-Fußabdruck zusammengefasst werden können. Wie also können wir den CO2-Fußabdruck unserer Softwaresysteme bestimmen und vielleicht sogar über die Zeit überwachen und die Entwicklung verfolgen?
Auf der Suche nach möglicherweise schon vorhandenen Herangehensweisen sind wir bei der Green Software Foundation (GSF) vorbeigekommen. Das ist zurzeit die Anlaufstelle, wenn es um Nachhaltigkeit im IT-Bereich geht. Wir haben dort eine Vielzahl von Informationen, weiterführenden Links, Referenzen und einen Newsletter, der immer die aktuellsten Entwicklungen und Erkenntnisse zum Themenbereich Green IT zusammenfasst, gefunden. Weiterhin haben wir die SCI (Software Carbon Intensity) Specification kennengelernt, einen Standard zur Nachhaltigkeitsbewertung von Softwaresystemen. Das war bereits im Herbst 2023, als der SCI noch kein offizieller Standard war - somit ist uns erst im Laufe der Zeit klar geworden, dass Standard an dieser Stelle wirklich mit einer DIN-Norm vergleichbar ist. Der SCI ist damit nicht zur direkten Anwendung, sondern als Grundlage für die Umsetzung durch geeignete Tools gedacht.
Da uns das zu diesem Zeitpunkt noch nicht bewusst war, haben wir versucht, die SCI-Specification direkt anzuwenden, um den CO2-Fußabdruck von Softwaresystemen zu ermitteln. Im Rahmen eines Fokustages haben wir einen kleinen, genau abgegrenzten Teil eines unserer Kundenprojekte betrachtet. Schon bei diesem kleinen Softwaresystem war es sehr zeitaufwendig, die benötigten Daten zusammenzutragen. Für einige Werte mussten wir Schätzungen verwenden, da die geteilte Laufzeitumgebung des Projektes teilweise keine genauen Aussagen zuließ oder wir einfach keine genauen Angaben finden konnten. Die benötigten Werte mussten (und müssen) aus einer Vielzahl von Quellen zusammengetragen werden, wobei es eine eigene Herausforderung ist, an Daten der großen Cloud-Provider zu kommen. Nachdem wir einen ganzen Tag gebraucht haben, um den CO2-Ausstoß eines API-Requests zu berechnen und uns über die Validität des Ergebnisses sehr unsicher waren, haben wir uns gefragt, ob es da nicht schon was von Ratiopharm gibt.
Dabei sind wir wieder auf das uns zu dem Zeitpunkt bereits bekannte, aber viel zu kompliziert erscheinende Impact Framework (IF) der GSF zurückgekommen. Nach den Erfahrungen mit der SCI-Specification konnte uns die anfangs wahrgenommene Komplexität des IF nicht mehr erschrecken. Zumal das IF nach eigener Aussage den Umwelteinfluss von Software schnell und einfach ermittelbar und teilbar machen möchte.
Das Impact Framework ermöglicht die flexible Berechnung des CO2-Fußabdruckes von Softwaresystemen zu verschiedenen Zeitpunkten in ihren Lebenszyklen. Um das IF zu verwenden, reicht eine Idee der Systemarchitektur aus. Im Gegensatz zu anderen Tools (wie zum Beispiel dem Cloud Carbon Footprint Tool), ist es nicht notwendig, dass die Komponenten bereits umgesetzt und in ihrer Zielumgebung deployed (und unter Last) sind. Das macht das IF ideal für Variantenbetrachtungen vor Cloud-Anbieter-Wechseln, zur Abschätzung von Neusystemen sowie zur Modellierung von Architekturideen neuer Systeme.
Das IF untersucht den CO2-Fußabdruck eines Systems auf Grundlage der (voraussichtlich) verwendeten Ressourcen in der Zielumgebung. Die feingranulare Betrachtung auf Codeebene (wie zum Beispiel mit Hilfe von EcoSonar möglich), bleibt dabei außen vor.
Das IF ermöglicht die variable Modellierung von Softwaresystemen mit Hilfe einer Pipeline, die aus den Phasen Observe (Daten sammeln), Regroup (gruppieren und sortieren der gesammelten Daten) und Compute (Impact-Berechnung auf der vorher bereitgestellten Datengrundlage) besteht. Die einzelnen Phasen werden jeweils durch eines oder mehrere Plugins implementiert. Diese stellen Daten aus statischen oder dynamischen Quellen zur Verfügung, transformieren diese Daten und berechnen den Impact des Systems. Die einzelnen Phasen können alle zusammen oder jeweils einzeln ausgeführt werden. So kann zum Beispiel das in der Regel zeit- und ressourcenaufwendige Datensammeln nur nach Bedarf ausgeführt werden und anschließend können verschiedene Varianten auf Grundlage bereits gesammelter Daten betrachtet werden.
Das zu untersuchende System wird innerhalb einer manifest genannten yaml-Datei modelliert. Diese beinhaltet allgemeine Informationen zum System (context), die Modellierung des Systems (tree) und die Definition der Pipeline (pipeline) mit ihren drei Phasen. Die einzelnen Phasen werden jeweils mithilfe von Plugins beschrieben und sofern vom Plugin erfordert, können Eingabewerte (inputs) definiert werden. Das manifest wird anschließend mit der Impact-Engine über die Kommandozeile ausgeführt. Dabei kann definiert werden, welche Phasen der Pipeline ausgeführt werden sollen. Dabei wird das Ergebnis (output) in der zuvor definierten Art ausgegeben (zum Beispiel als yaml-Datei oder auf der Kommandozeile). Das Ergebnis besteht aus dem manifest, welches um weiterführende Informationen zu den einzelnen Plugins (explain) sowie den Zwischen- und Endergebnissen der Berechnung (outputs) ergänzt wird.
Damit ist es stark von den verwendeten Plugins abhängig, welche Werte mit einer IF-Pipeline ermittelt werden. Zur Zeit stehen vor allem Plugins zur Ermittlung des CO2-Fußabdrucks zur Verfügung. Bei Verwendung der passenden Plugins ist es aber auch denkbar, andere Größen zu ermitteln, wie zum Beispiel den Wasserverbrauch.
Die Plugins werden in builtin und community-owned Plugins unterteilt. Builtin Plugins werden von der GSF selbst entwickelt und maintained und sind, wie das Framework selbst, unter der MIT License opensource zur Verfügung gestellt. Momentan sind die builtin Plugins in Anzahl und Funktionsumfang noch begrenzt, es findet jedoch sehr aktive Entwicklungsarbeit statt. Community-owned Plugins sind Community-Projekte, die stark von den Bedürfnissen und der Aktivität der Community abhängen. Mithilfe von community-owned Plugins kann individuell benötigte Funktionalität umgesetzt und veröffentlicht werden. Damit kann eine Vielzahl verschiedener Anwendungsbereiche abgedeckt werden.
Um uns mit dem IF vertraut zu machen, haben wir zuerst das in der Dokumentation verwendete Beispiel nachgestellt und anschließend unser bereits genanntes Beispiel aus der Untersuchung der SCI-Specification im IF modelliert und berechnet. Wir haben erfreut festgestellt, dass wir mit beiden Methoden sehr ähnliche Ergebnisse erzielen konnten. Anschließend haben wir begonnen, ein komplexes, prototypisches Beispiel auf Basis unserer Projekt-Erfahrungen zu entwerfen und zu modellieren. An dieser Stelle mussten wir dann etwas unangenehme Bekanntschaft mit den Nachteilen machen, die ein Projekt im Incubation-Status mit sich bringen kann. So wurden wir von Breaking Changes überrascht, die uns letztendlich dazu brachten, unser Beispiel nicht fertig zu modellieren, sondern an anderen Stellen weiterzuarbeiten.
Aktuell arbeiten wir an Möglichkeiten, das IF besser und vor allem automatisiert nutzbar zu machen. Unser Ziel ist es, p-lugins (Plugins the pentacor way) innerhalb der observe-Phase zu entwickeln, die Daten dynamisch aus Systemen wie beispielsweise Datadog sammeln. Perspektivisch wollen wir einen Workflow entwickeln, der es ermöglicht, den CO2-Fußabdruck eines Systems automatisiert in CI/CD-Pipelines zu ermitteln und so Systeme in ihrer Entwicklung über ihre Lebensdauer zu überwachen. Im nächsten Schritt eröffnet dies Möglichkeiten, zeitnah zu erkennen, wenn sich der CO2-Fußabdruck eines Systems über die Zeit verändert. Mithilfe eines solchen Monitorings können dann zielgerichtete Maßnahmen ergriffen werden, um zum Beispiel stetiges Wachsen des CO2-Fußabdrucks eines Systems zu vermeiden.
Im vergangenen Jahr konnten wir viel Wissen aufbauen und Erkenntnisse erlangen, wie der Umwelteinfluss von Softwaresystemen bestimmt werden kann. Dabei haben wir festgestellt, dass es bereits jetzt möglich ist, den CO2-Fußabdruck von Software zu ermitteln, und dies zukünftig möglicherweise auch automatisiert getan werden kann. Aktuell ist die praktische Nutzbarkeit des IF noch eingeschränkt, da die Anzahl verfügbarer Plugins klein ist und nur Systeme bestimmter Anbieter unterstützt werden. Aus unserer Sicht ist noch einiges Entwicklung notwendig bis eine produktive Nutzung gut möglich ist. Der grundlegende Ansatz des IF wirkt für uns jedoch vielversprechend und wir wollen ihn weiter im Auge behalten, verfolgen und möglicherweise auch mitgestalten.
Zudem haben wir festgestellt, dass Themen rund um Green IT und Nachhaltigkeit in der Softwareentwicklung gute Gesprächsthemen sind, mit denen wir auf Konferenzen und Meetups Kontakte knüpfen und inspirierende Gespräche führen konnten. Gleichzeitig ist es ein riesiger Themenkomplex, von dem aktuell vor allem einige wenige, immer gleiche Aspekte beleuchtet und diskutiert werden. Mit dem Messen des CO2-Fußabdrucks wollen wir ein weiteres Themenfeld erkunden und bekannter machen.
In diesem Sinne, stay tuned!
