Unser Buildsystem ist in den letzten Jahren stark verbessert worden und baut unsere monolithische Legacy-Software in wenigen Minuten mit gradle, Caching und allen möglichen anderen Verbesserungsmöglichkeiten. Zurzeit können wir leider mit dem Build-Slaves des Jenkins nicht ohne großen Aufwand in unseren Kubernetes-Cluster und haben daher sieben sehr performante Server extra dafür laufen.
Einen Großteil der Zeit sind diese Server nicht ausgelastet und laufen im Leerlauf. Trotzdem verbrauchen sie Strom. Je nach Servergeneration sprechen wir von einem Minimum von 150 Watt pro Stunde bis maximal 220 Watt pro Stunde. Dies ist ein Aspekt, der sowohl die Kosten für Strom, Klimaanlage etc. betrifft, als auch ökologisch gesehen die CO2-Emission erhöht.
CO2 Ausstoß senken im Buildprozess
Strom-Flatrate führt nicht zum Sparen
Betriebswirtschaftlich haben wir durch unsere Verträge im Rechenzentrum keine Argumente finanzieller Art, um an das Thema „Kosteneinsparungen“ heranzugehen. Stichwort „Strom-Flatrate“: Sie deckelt die Kosten nach oben, aber eben auch nach unten. So eine Flatrate gibt so gesehen natürlich keine Anreize, Stromkosten generell zu senken. Aber die Abrechnung ist immerhin simpel.
CO2-Ausstoß und Leerlaufbetrieb von Servern
Ökologisch gesehen bleibt der zu betrachtende CO2-Ausstoß. Lege ich einen Anteil von 75 % Leerlauf der Server mit dem Minimumstromverbrauch 150 Watt pro Stunde zugrunde sowie einer durchschnittlichen CO2-Emission von 485 Gramm Kilowatt pro Stunde für ’normalen‘ Nicht-Ökostrom (UBA-Daten für 2021) im Energiemix, werden daraus 3,3 Tonnen CO2 für den Leerlauf-Betrieb der sieben Server pro Jahr! Autsch, das hat mich negativ überrascht.
Ok, unter dieser Menge kann ich mir als Normalbürger wenig vorstellen. Daher suche ich mir eine Äquvalenzberechnung, um diese Menge CO2 etwas griffiger zu bekommen, z. B. im Vergleich zu einem einfachen Flug von Hamburg nach München in der Economy Class einer großen deutschen Fluggesellschaft. Deren CO2-Rechner besagt, dass pro Flug 161 Kilogramm CO2 entstehen. Da wir am Standort Hamburg gern mal zu unserer Muttergesellschaft nach München fliegen, kann sich jeder Mitarbeiter gut etwas darunter vorstellen.
Bei 3,3 Tonnen CO2 pro Jahr entspricht dies knapp 21 Einzelflügen von Hamburg nach München für den Leerlaufbetrieb der Server in einem Jahr ohne einen wirklichen Nutzen. Und ja, da sind die Kosten bzw. CO2-Emissionen durch die Klimaanlage in dem Rechenzentrum nicht einmal enthalten. Da bekomme ich ein arg schlechtes Gewissen und denke über Lösungen nach.
Lösungen, die vielleicht keine sind
Eine Lösung wäre, die Server nur dann hochzufahren, wenn sie benötigt werden und gegebenenfalls nur einen Build-Slave aktiv zu belassen, sodass die Nutzer des Buildsystems diese Änderung gar nicht mitbekommen. Bei Bedarf immer einen Server zu starten bzw. bei geringer werdender Last wieder runterzufahren, sodass die interne Änderung nach Außen nicht sichtbar wird. Dürfte nicht schwer sein, dies zu realisieren. Magicpackets für ‚Wake on LAN‚ gibt es schon länger und ist ein Industriestandardprotokoll. Leider konnte ich im Kontext des verwendeten Jenkins nichts als Plug-in für solch eine Funktionalität finden, außer einem Plugin namens „Smart-Jenkins“ von 2011 mit aktuell unter 10 Downloads pro Monat. Da hatte ich mehr erwartet. Scheinbar ist dies aktuell noch kein Thema.
Gegen diese Lösung spricht der Ansatz, Server nicht ständig rauf und runter zufahren, denn an und für sich sind diese ja für den Dauerbetrieb ausgelegt. Und natürlich das Paradigma ’never change a running system‘. In meinen Augen eine Glaubensfrage, ähnlich wie die, nach der besten IDE (Entwicklungsumgebung) oder so.
Ökostrom – Greenwashing?
Eine Alternative wäre der Umstieg auf nachhaltig erzeugten Ökostrom. Aber an und für sich ist der erste Schritt bei Nachhaltigkeit, den Verbrauch signifikant zu senken und nicht noch mehr Windparks, Solarfelder etc. in die Landschaft zu setzen, um unnötig genutzten Strom nachhaltig zu erzeugen. Das wäre mehr als widersprüchlich, beruhigt aber bei manch anderem vielleicht das Gewissen.
Umzug in die Cloud – der legacy Monolith sperrt sich
Gut wäre es, die Server durch gegebenenfalls andere Applikationen mit zu nutzen, im Sinne von Hardware-Sharing. Dafür ist genau genommen Kubernetes und Co. gedacht. Nur ist dies mit unserer monolithischen legacy-Software nicht trivial und erfordert Aufwände, die nicht schnell realisiert werden können.
Als Hinderungsgründe für den Umzug in die Cloud sind die monolithische Struktur der Software und die Größe zu nennen und damit einhergehend der Umfang an Buildmenge und -dauer. Ein Buildlauf kann im schlechtesten Fall 1,5 Stunden dauern und das ist alles andere als zustandslos und widerspricht dem Kubenetes-Ansatz, gegebenenfalls Pods im Cluster einfach zu verschieben. Es gäbe sofort Build-Abbrüche. Gleichfalls wäre die Last auf der jeweiligen Node im Cluster so groß, dass da kaum ein anderer Pod Rechenzeit bekäme und die Cloud arg instabil würde. Den Monolithen in größere Broken zu teilen, wäre dabei hilfreich.
Kurzum, mein schlechtes Gewissen bleibt erst einmal und eine schnelle Lösung ist nicht in Sicht. Irgendwie unbefriedigend und diskussionswürdig. Vielleicht geht da ja doch noch etwas, um in Zukunft besser zu werden? Ich würde eine Diskussion nicht scheuen, gerne auch bei einem unserer nächsten Meetups.
