Grüne Software für Gebäude

Kapitel 4. Operative Effizienz

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

Widerstand ist zwecklos!

Die Borg

In Wirklichkeit ist der Widerstand nicht zwecklos. Es ist viel schlimmer als das.

Der Kampf gegen die Maschinen

Eines Tages werden supraleitende Server, die in unterkühlten Rechenzentren laufen, den Widerstand eliminieren und unsere Rechenzentren werden mit einem Bruchteil des heutigen Stroms betrieben. Vielleicht arbeiten unsere zukünftigen Herren der künstlichen Intelligenz (AGI) schon jetzt daran. Leider können wir mickrigen Menschen aber nicht warten.

Wenn wir heute Maschinen in Rechenzentren mit Strom versorgen, erhitzen sie sich. Diese Energie - die allzu oft zu erheblichen Klimakosten erzeugt wird - ist dann für immer verloren. Der Kampf gegen den Widerstand ist es, was die Leute tun, wenn sie daran arbeiten, die Stromverbrauchseffizienz (PUE) in Rechenzentren zu verbessern (wie wir in Kapitel 2 besprochen haben). Das ist auch das Motiv hinter dem Konzept der Betriebseffizienz, über das wir in diesem Kapitel sprechen werden.

Hinweis

Diese supraleitenden Gleichstromanlagen könnten im Weltraum stehen, denn das könnte das Kälteproblem lösen (Supraleiter müssen sehr, sehr kalt sein - kalt im Weltraum, nicht kalt in der Weste). Supraleitende DCs außerhalb des Planeten sind allerdings noch ein Jahrhundert entfernt. Zu spät, um unsere unmittelbaren Probleme zu lösen.

In den letzten drei Jahrzehnten haben wir die Stromverschwendung in den Rechenzentren mit Hilfe von Entwicklungen im CPU-Design und anderen Verbesserungen der Hardwareeffizienz bekämpft. Diese haben es Entwicklern ermöglicht, die gleiche Leistung mit immer weniger Maschinen und weniger Strom zu erzielen. Diese Verbesserungen nach dem Mooreschen Gesetz reichen jedoch nicht mehr aus, damit wir uns darauf verlassen können. Das Mooresche Gesetz verlangsamt sich. Es könnte sogar aufhören (obwohl es das wahrscheinlich nicht wird).

Glücklicherweise ist die Hardware-Effizienz aber nicht die einzige Waffe, die wir im Kampf gegen den Widerstand haben. Betriebliche Effizienz ist die Art und Weise, wie grüne DevOps- oder SRE-Leute wie Sarah die Stromverschwendung in ihren Rechenzentren reduzieren. Aber was ist betriebliche Effizienz?

Die Entwicklung der Heizung

Sieht man einmal von der Supraleitung ab, ist die Erwärmung durch den Widerstand das wichtigste unerwünschte physikalische Nebenprodukt der Stromnutzung. Außerhalb eines Heizkörpers ist das eine schlechte Sache, und davon gibt es in einem modernen Rechenzentrum nicht viele.

In einem Heizelement ist der Widerstand nicht unerwünscht. Er ist der Mechanismus, mit dem elektrische Heizkörper funktionieren, und er ist 100% effizient bei der Wärmeerzeugung. Früher waren 100 % Wirkungsgrad eine ganze Menge. Wie sich die Zeiten geändert haben. Heute brauchen wir viel mehr Leistung für unser Watt. Wärmepumpen, die durch den cleveren Einsatz von Kältemitteln einen Wirkungsgrad von über 400% (!) erreichen, haben unsere Erwartungen hochgeschraubt. Wärmepumpen sind fantastisch. Leider sind sie auch viel komplizierter zu entwerfen, herzustellen und zu betreiben als einfache Heizkörper und enthalten viel mehr gebundenen Kohlenstoff.

Wir gehen davon aus, dass die Herstellung und der Betrieb von Wärmepumpen mit zunehmender Verbreitung besser werden, aber das wird nicht von heute auf morgen geschehen. Vielmehr sind sie ein gutes Beispiel für die Vorlaufkosten und Kompromisse, die bei der Umstellung auf eine neue, effizientere Technologie anfallen.

Es wurden enorme Investitionen in Wärmepumpen getätigt, und es werden noch mehr nötig sein. Sie zeigen, dass es nur wenige triviale Lösungen für den Klimawandel gibt - bei den meisten ist noch viel Arbeit nötig, um sie marktfähig zu machen. Das heißt, wir müssen sie alle hundert- bis tausendmal effizienter bauen, einbauen und in großem Maßstab betreiben. Dinge, die nicht standardisiert werden können, werden die Energiewende wahrscheinlich nicht überleben.

Tipp

Beachte auch, dass die Wärme, die durch den elektrischen Widerstand aller elektrischen Geräte auf der Welt freigesetzt wird, keinen wesentlichen Beitrag zur globalen Erwärmung leistet. Es ist unsere Sonne, die in Kombination mit den physikalischen Eigenschaften der Treibhausgase für die tatsächliche Erwärmung des Klimas sorgt. Außerdem ist es die Sonne, die die Wärmepumpen mit einem Wirkungsgrad von über 100 % liefert. Die Elektrizität hilft den Wärmepumpen lediglich dabei, die Sonnenenergie zu nutzen.

In ferner Zukunft, wenn wir fast unbegrenzt Energie aus der Kernfusion oder aus weltraumgestützten Solaranlagen gewinnen, müssen wir uns vielleicht Sorgen um die direkte Erwärmung machen. Aber das ist ein Problem für ein anderes Jahrhundert. Es wird ein ausgezeichnetes sein, wenn wir es erreichen. Es wird bedeuten, dass die Menschheit diese Runde überlebt hat.

Heißes Zeug

Bei der Betriebseffizienz geht es darum, mit weniger Hardwareressourcen wie Servern, Festplatten und CPUs dasselbe funktionale Ergebnis für dieselbe Anwendung oder denselben Dienst zu erzielen, einschließlich Leistung und Ausfallsicherheit. Das bedeutet, dass weniger Strom benötigt wird, der in Form von Wärme abgeleitet wird, dass weniger Kühlung benötigt wird, um diese Wärme zu bewältigen, und dass weniger Kohlenstoff bei der Herstellung und Entsorgung der Geräte ausgestoßen wird.

Betriebliche Effizienz ist vielleicht nicht die glamouröseste Option. Sie hat vielleicht auch nicht das größte theoretische Potenzial, um Energieverschwendung zu reduzieren. In diesem Kapitel wollen wir dich jedoch davon überzeugen, dass dies ein praktischer und realisierbarer Schritt ist, den fast jeder machen kann, um umweltfreundlichere Software zu entwickeln. Und nicht nur das, wir werden auch argumentieren, dass sie in vielerlei Hinsicht den Alternativen in den Hintern tritt.

Techniken

Wie in der Einleitung erwähnt, geht AWS davon aus, dass eine gute Betriebseffizienz die Kohlenstoffemissionen von Systemen um das Fünffache bis Zehnfache reduzieren kann. Das ist nicht zu verachten.

"Moment mal! Hast du nicht gesagt, dass die Effizienz des Codes um das Hundertfache reduzieren könnte! Das ist zehnmal besser!"

Das stimmt. Das Problem mit der Code-Effizienz ist jedoch, dass sie mit etwas kollidieren kann, das den meisten Unternehmen sehr am Herzen liegt: die Produktivität der Entwickler. Und es ist richtig, dass ihnen das am Herzen liegt.

Wir stimmen zu, dass die betriebliche Effizienz weniger effektiv ist als die Code-Effizienz, aber sie hat für die meisten Unternehmen einen erheblichen Vorteil. Mit vergleichsweise geringem Aufwand und dem Einsatz von Standardwerkzeugen kannst du hier große Verbesserungen erzielen. Das ist das niedrig hängende Obst, mit dem die meisten von uns anfangen müssen.

Die Code-Effizienz ist erstaunlich, aber der Nachteil ist, dass sie auch sehr aufwändig und zu oft sehr individuell ist (das wird hoffentlich in Angriff genommen, aber so weit sind wir noch nicht). Das solltest du nur tun, wenn du eine große Anzahl von Nutzern haben wirst. Und selbst dann musst du erst experimentieren, um deine Anforderungen zu verstehen.

Hinweis

Du wirst feststellen, dass wir mit 10-fachen betrieblichen Verbesserungen und 100-facher Code-Effizienz das 1000-fache erreichen, das wir eigentlich wollen. Innerhalb von fünf Jahren brauchen wir beides durch Standardwerkzeuge und -dienste - also grüne Plattformen.

Im Gegensatz dazu ist eine bessere betriebliche Effizienz bereits durch standardisierte Bibliotheken und Commodity-Dienste möglich. Daher können wir in diesem Kapitel weithin anwendbare Beispiele für gute Praktiken aufführen, die wir im vorherigen Kapitel nicht aufführen konnten.

Aber bevor wir damit anfangen, sollten wir einen Schritt zurückgehen. Wenn wir über moderne betriebliche Effizienz sprechen, auf welche übergeordneten Konzepte stützen wir uns dann?

Wir glauben, dass es auf einen einzigen grundlegenden Begriff hinausläuft: Maschinenauslastung.

Maschinenauslastung

Maschinenauslastung, Serverdichte oder Müllverdichtung. Es gibt viele Bezeichnungen für diese Idee, und wir haben wahrscheinlich einige übersehen, aber das Motiv dahinter ist dasselbe. Bei der Arbeitsspeicherauslastung geht es darum, die Arbeit auf einem einzelnen Rechner oder einem Cluster so zu verteilen, dass die physischen Ressourcen wie CPU, Arbeitsspeicher, Netzwerkbandbreite, Festplatten-E/A und Strom optimal genutzt werden.

Eine gute Maschinenauslastung ist mindestens genauso wichtig für die Umweltfreundlichkeit wie die Code-Effizienz.

Nehmen wir an, du schreibst deine Anwendung in C um und reduzierst ihren CPU-Bedarf um 99%. Hurra! Das war mühsam und hat Monate gedauert. Angenommen, du lässt sie jetzt auf genau demselben Server laufen wie vorher. Leider hättest du durch den ganzen Aufwand des Umschreibens nicht so viel Strom gespart. Wie wir in Kapitel 6 erläutern werden, verbraucht ein teilweise genutzter Rechner einen Großteil des Stroms eines voll ausgelasteten Rechners, und die Kohlenstoffbelastung durch die Hardware ist dieselbe.

Kurz gesagt: Wenn du deinen Rechner nicht gleichzeitig mit deiner Anwendung verkleinerst (sogenanntes Rightsizing), sind die meisten deiner Bemühungen zur Codeoptimierung umsonst gewesen. Das Problem ist, dass das Rightsizing schwierig sein kann.

Rightsizing

Eine der umweltfreundlichsten Maßnahmen, die du ergreifen kannst, ist es, deine Systeme nicht zu überlasten. Das bedeutet, dass du Maschinen, die größer als nötig sind, verkleinern solltest. Wie wir bereits gesagt haben (aber es lohnt sich, es zu wiederholen), bedeutet eine höhere Maschinenauslastung, dass der Strom effizienter genutzt wird und der Kohlenstoffverbrauch reduziert wird. Rightsizing-Techniken können sowohl vor Ort als auch in der Cloud angewendet werden.

Leider gibt es Probleme, wenn du sicherstellen willst, dass deine Anwendungen auf Maschinen laufen, die weder zu groß noch zu klein sind (nennen wir es die DevOps-Goldlöckchen-Zone): Überprovisionierung wird oft aus guten Gründen betrieben.

Überprovisionierung ist eine gängige und erfolgreiche Risikomanagementtechnik. Es ist oft schwer vorherzusagen, wie sich ein neuer Dienst verhält oder welche Anforderungen an ihn gestellt werden. Deshalb ist es sinnvoll, ihn auf einem Servercluster zu installieren, der viel größer ist, als du glaubst, dass er benötigt. Das sollte zumindest sicherstellen, dass er nicht an Ressourcengrenzen stößt. Außerdem wird so die Wahrscheinlichkeit von schwer zu debuggenden Wettlaufsituationen verringert. Das kostet zwar etwas mehr Geld, aber dafür ist die Wahrscheinlichkeit geringer, dass dein Dienst zusammenbricht, und für die meisten Unternehmen ist dieser Kompromiss unschlagbar. Wir alle haben vor, unsere VMs zu einem späteren Zeitpunkt zu verkleinern, aber das tun wir nur selten, denn das zweite Problem beim Rightsizing ist, dass man nie Zeit dafür hat.

Die naheliegende Lösung ist die automatische Skalierung. Wie wir gleich sehen werden, ist auch das leider nicht perfekt.

Autoskalierung

Autoscaling ist eine Technik, die häufig in der Cloud eingesetzt wird, aber auch vor Ort möglich ist. Die Idee dahinter ist, die einem System zugewiesenen Ressourcen automatisch an den aktuellen Bedarf anzupassen. Alle Cloud-Provider bieten Autoscaling-Dienste an, und auch in Kubernetes ist diese Technik enthalten. Theoretisch ist das eine tolle Sache.

Das Problem ist, dass die automatische Skalierung in der Praxis auf ähnliche Probleme stoßen kann wie das manuelle Overprovisioning. Die Skalierung bis zum Maximum ist in Ordnung, aber die Skalierung nach unten ist viel riskanter und beängstigender, deshalb wird sie manchmal nicht automatisch durchgeführt. Du kannst manuell wieder herunter skalieren, aber wer hat schon die Zeit, alles manuell zu machen? Das war der Grund, warum du Autoscaling überhaupt benutzt hast. Daher löst die Autoskalierung nicht immer das Problem der Unterauslastung.

Zum Glück gibt es in öffentlichen Clouds eine andere mögliche Lösung. Burstable Instances bieten einen Kompromiss zwischen Ausfallsicherheit und Umweltfreundlichkeit. Sie sind für Workloads gedacht, die keine konstant hohe CPU-Leistung benötigen, aber gelegentlich eine hohe CPU-Leistung brauchen, um das lästige Umkippen zu vermeiden.

Burstable-Instanzen verfügen über eine Basis-CPU-Leistung, können aber, wenn die Arbeitslast es erfordert, für einen begrenzten Zeitraum auf eine höhere Leistung "hochschnellen". Wie lange die Instanz den "Burst" aufrechterhalten kann, hängt von den angesammelten CPU-Guthaben ab, über die sie verfügt. Wenn sich die Arbeitslast wieder normalisiert, kehrt die Instanz auf ihr Basisleistungsniveau zurück und sammelt wieder CPU-Guthaben an.

Burstable Instances haben mehrere Vorteile:

• Sie sind billiger (sprich: maschineneffizienter für Cloud-Provider) als Instanztypen, die eine konstant hohe CPU-Leistung bieten.

• Sie sind umweltfreundlicher und ermöglichen es deinen Systemen, gelegentliche Nachfragespitzen zu bewältigen, ohne dass du im Voraus mehr Ressourcen bereitstellen musst, als du normalerweise brauchst. Außerdem werden sie automatisch heruntergefahren.

• Das Beste daran ist, dass sie die Verwaltung der Serverdichte zum Problem deines Cloud-Providers machen und nicht zu deinem.

Natürlich gibt es immer auch Negatives:

• Die Zeit, die deine Instanz auf ein höheres Leistungsniveau hochschnellen kann, ist durch die CPU-Credits begrenzt, die du hast. Du kannst immer noch umfallen, wenn du keine mehr hast.

• Wenn deine Arbeitslast eine konstant hohe CPU-Leistung erfordert, wäre es günstiger, einen großen Instanztyp zu verwenden.

• Es ist nicht so sicher wie die Wahl einer übergroßen Instanz. Die Leistung von Burstable Instances kann schwanken, so dass es schwierig ist, das genaue Niveau vorherzusagen. Wenn die Nachfrage groß genug ist, wird sich die Leistung mit der Zeit hoffentlich verbessern, da die Hyperscaler weiter investieren, um sie zu verbessern.

• Die Verwaltung von CPU-Guthaben macht dein System komplexer. Du musst die angesammelten Guthaben im Auge behalten und für Ausbrüche planen.

Das Ergebnis ist, dass Rightsizing großartig ist, aber es gibt keinen einfachen Weg, es zu tun. Energie effizient zu nutzen, indem man nicht zu viel bereitstellt, erfordert im Vorfeld Investitionen in Zeit und neue Fähigkeiten - selbst bei automatischer Skalierung oder Burstable Instances.

Wieder und wieder hat Kermit der Frosch recht behalten. Nichts ist einfach, wenn es darum geht, grün zu sein, sonst würden wir es schon längst tun. Aber es ist nicht nur nachhaltiger, sondern spart auch eine Menge Geld, wenn du eine Überdimensionierung vermeidest - es lohnt sich also, darüber nachzudenken. Vielleicht ist die Bewältigung der Schwierigkeiten beim Rightsizing ein Grund, ein Infrastructure-as-Code- oder GitOps-Projekt zu starten...

Infrastruktur als Code

Infrastructure as Code (IaC) ist das Prinzip, dass du die Infrastruktur mithilfe von Code definierst, konfigurierst und bereitstellst, anstatt dies manuell zu tun. Die Idee dahinter ist eine bessere Automatisierung, Wiederholbarkeit und Versionskontrolle. Mithilfe von domänenspezifischen Sprachen und Konfigurationsdateien beschreibst du, wie du deine Server, Netzwerke und Speicherung haben möchtest. Diese codebasierte Darstellung wird dann zur einzigen Version der Wahrheit für deine Infrastruktur.

GitOps ist eine Version von IaC, die Git als Versionskontrolle nutzt. Alle Änderungen, auch solche, die die Bereitstellung betreffen, wie z.B. die Autoskalierung, werden über Git verwaltet, und deine aktuelle Infrastruktur wird kontinuierlich mit dem gewünschten Zustand, der in deinem Repository definiert ist, abgeglichen. Das Ziel ist es, einen Prüfpfad für alle Infrastrukturänderungen zu erstellen, der es dir ermöglicht, diese nachzuverfolgen, zu überprüfen und zurückzusetzen.

Die gute Nachricht ist, dass die IaC- und GitOps-Gemeinschaft begonnen hat, über grüne Betriebsabläufe nachzudenken, und die sogenannte GreenOps ist bereits ein Ziel der Cloud Native Computing Foundation (CNCF) Environmental Sustainability Group. Die Stiftung verbindet das Konzept mit Kostensenkungstechniken (auch bekannt als FinOps, über die wir in Kapitel 11 über die Nebeneffekte grüner Systeme sprechen werden), und die Stiftung hat Recht (siehe Abbildung 4-1). Im Betrieb ist grüner billiger.

Abbildung 4-1. CNCF-Definition von GreenOps als GitOps + FinOps

Wir denken, dass hier impliziert, dass du an der Spitze des Dreiecks beginnst und dich nach unten durcharbeitest, was vernünftig erscheint, weil die Dinge am unteren Ende sicherlich schwieriger sind.

Alles, was Rightsizing- und Autoscaling-Aufgaben automatisiert , macht sie wahrscheinlicher, und das legt nahe, dass IaC und GitOps eine gute Sache für Green sind. Dass es eine CNCF IaC-Community gibt, die GreenOps vorantreibt, ist ebenfalls ein gutes Zeichen.

Zum Zeitpunkt der Erstellung dieses Artikels sprachen die Autoren mit Alexis Richardson, CEO von Weaveworks, und einigen Mitgliedern des Teams. Weaveworks hat 2017 den Begriff GitOps geprägt und die wichtigsten Prinzipien zusammen mit FluxCD, einer Kubernetes-freundlichen Implementierung, dargelegt. Das Unternehmen sieht die nächste große Herausforderung für GreenOps in der automatischen Verfolgung von Treibhausgasemissionen. Dem stimmen wir zu, und dieses Problem werden wir in Kapitel 10 erörtern.

Zeitplanungsprogramm für Cluster

Standardtechniken wie Rightsizing und Autoscaling sind schön und gut, aber wenn du die Maschinenauslastung wirklich clever gestalten willst, solltest du dich auch mit dem radikaleren Konzept des Cluster-Schedulings befassen.

Die Idee hinter dem Cluster-Scheduling ist, dass unterschiedlich geformte Arbeitslasten programmatisch auf die Server gepackt werden können, wie Teile in einem DevOps-Tetris-Spiel (siehe Abbildung 4-2). Das Ziel ist es, die gleiche Menge an Arbeit auf der kleinstmöglichen Gruppe von Maschinen auszuführen. Das ist vielleicht das Nonplusultra an automatisierter Betriebseffizienz und stellt eine große Veränderung gegenüber der Art und Weise dar, wie wir früher Systeme bereitgestellt haben. Bisher hatte jede Anwendung ihre eigene physische Maschine oder VM. Beim Cluster Scheduling werden diese Maschinen von den Anwendungen gemeinsam genutzt.

Abbildung 4-2. DevOps Tetris

Stell dir zum Beispiel vor, du hast eine Anwendung mit einem hohen Bedarf an E/A und einem geringen Bedarf an einer CPU. Ein Zeitplannungsprogramm könnte deinen Job auf demselben Server platzieren wie eine Anwendung, die zwar prozessorintensiv ist, aber nicht viel E/A benötigt. Ziel des Zeitplannungsprogramms ist es immer, die lokalen Ressourcen so effizient wie möglich zu nutzen und gleichzeitig zu gewährleisten, dass deine Aufträge innerhalb des erforderlichen Zeitrahmens und in der gewünschten Qualität und Verfügbarkeit erledigt werden.

Die gute Nachricht ist, dass es viele Zeitplannungsprogramme und -dienste für Cluster gibt - in der Regel als Teil von Orchestrierungsplattformen. Das populärste ist eine Komponente der Open-Source-Plattform Kubernetes und eine stark vereinfachte Version des internen Zeitplannungsprogramms von Google, das Borg heißt. Wie in der Einleitung erwähnt, wird Borg bei Google schon seit fast zwei Jahrzehnten eingesetzt.

Um die Cluster-Planung auszuprobieren, kannst du das Zeitplannungsprogramm von Kubernetes oder ein anderes Programm wie Nomad von HashiCorp in deinem On-Prem-DC verwenden. Alternativ kannst du auch einen verwalteten Kubernetes-Cloud-Service wie EKS, GKS oder AKS (von AWS, Google bzw. Azure) oder eine Nicht-Kubernetes-Option wie den AWS Container Service (ECS) nutzen. Die meisten Zeitplannungsprogramme bieten ähnliche Funktionen, daher ist es wahrscheinlich, dass du das Zeitplannungsprogramm verwendest, das mit der von dir gewählten Betriebsplattform geliefert wird - es ist unwahrscheinlich, dass du dich für eine bestimmte Plattform entscheidest. Das Fehlen einer solchen Funktion zur Maschinenauslastung könnte jedoch darauf hindeuten, dass die Plattform, auf der du dich befindest, nicht grün genug ist.

Das Zeitplanungsprogramm für Cluster hört sich toll an und ist es auch, denn es kann bis zu 80% Maschinenauslastung bringen. Wenn du mit diesen Tools kein Geld und keinen Kohlenstoff sparst, setzt du sie wahrscheinlich nicht richtig ein. Allerdings gibt es noch ein großes Problem.

Informationsüberlastung

Damit diese Zeitplannungsprogramme Aufträge von Maschine zu Maschine verschieben können, um eine optimale Packung zu erreichen, benötigen sie drei Dinge:

1. Die Aufträge müssen mit all ihren vorausgesetzten Bibliotheken gekapselt werden, damit sie für ein maximales Packen verschoben werden können, ohne dass sie plötzlich aufhören zu funktionieren, weil ihnen eine wichtige Abhängigkeit fehlt.

2. Das Kapselungswerkzeug muss eine schnelle Instanziierung unterstützen (d.h. der gekapselte Auftrag muss schnell auf einer Maschine ausgeschaltet und auf einer anderen wieder eingeschaltet werden können). Wenn das eine Stunde (oder sogar ein paar Minuten) dauert, funktioniert das Cluster Scheduling nicht - der Dienst wäre zu lange nicht verfügbar.

3. Die gekapselten Aufträge müssen gekennzeichnet werden, damit das Zeitplannungsprogramm weiß, was es mit ihnen tun soll (z. B. ob sie Hochverfügbarkeitsanforderungen haben).

Die Kapselung und die schnelle Instanziierung können durch die Einbettung in einen Container wie Docker oder Containerd erreicht werden, und diese Technologie ist jetzt weithin verfügbar. Hurra!

Hinweis

Intern verwenden viele der AWS-Services leichtgewichtige VMs als Hülle für Aufträge und keine Container. Das ist in Ordnung. Das Konzept bleibt dasselbe.

Doch all diese clevere Technik stößt immer noch auf den Bedarf an Informationen. Wenn ein Zeitplannungsprogramm die zu planenden Arbeitslasten kennt, kann es die Ressourcen effektiver nutzen. Wenn er im Dunkeln tappt, kann er keine gute Arbeit leisten.

Bei Kubernetes kann das Zeitplannungsprogramm auf der Grundlage der in der Pod-Definition des Workloads festgelegten Einschränkungen handeln, insbesondere der CPU- und Speicheranforderungen (Minima) und der Limits (Maxima), aber das bedeutet, dass du sie angeben musst. Das Problem ist, dass das schwierig sein kann.

Ross Fairbanks, langjähriger GreenOps-Praktiker, meint: "Das Problem bei der automatischen Skalierung und der Definition von Beschränkungen ist, dass es schwierig ist, diese Beschränkungen festzulegen. Zum Glück gibt es jetzt einige Tools, die es einfacher machen. Fairbanks meint: "Der Kubernetes Vertical Pod Autoscaler kann eine Hilfe sein. Er hat einen Empfehlungsmodus, damit du dich an die Bedienung gewöhnen kannst, und einen automatischen Modus. Er ist ein guter Startpunkt, wenn du Kubernetes verwendest und die Maschinenauslastung verbessern willst."¹

Was ist mit der Cloud?

Wenn deine Systeme in der Cloud gehostet werden, profitierst du in der Regel von einem Zeitplannungsprogramm, da die Cloud-Provider ihre eigenen Zeitplannungsprogramme betreiben, auch wenn du keinen Container-Orchestrator wie Kubernetes einsetzt.

Du kannst die Merkmale deines Arbeitsaufkommens mitteilen, indem du den richtigen Cloud-Instance-Typ auswählst, und die Zeitplannungsprogramme der Cloud werden deine Wahl nutzen, um ihre Maschinenauslastung zu optimieren. Deshalb solltest du aus grüner Sicht deine Ressourcen- oder Verfügbarkeitsanforderungen nicht zu hoch ansetzen (z. B. indem du eine dedizierte Instanz verlangst, obwohl eine Burstable-Instanz oder sogar eine nicht dedizierte Instanz ausreichen würde).

Auch hier sind Überlegung, Planung und Beobachtung gefragt. Die öffentlichen Clouds sind recht gut darin, zu erkennen, wenn du zu viele Ressourcen zur Verfügung stellst und diese heimlich für andere Nutzer nutzt (auch bekannt als Überbelegung), aber die effizienteste Art, eine Plattform zu nutzen, ist immer die, für die sie gedacht ist. Wenn du eine Burstable Instance brauchst, ist die effizienteste Art, die Cloud zu nutzen, diese zu wählen.

Gemischte Arbeitsbelastungen

Das Zeitplanungsprogramm für Cluster ist am effektivsten (du kannst eine wirklich dichte Packung erreichen), wenn es eine große Anzahl verschiedener, gut beschrifteter Aufgaben auf vielen großen physischen Maschinen planen kann. Leider bedeutet dies, dass es weniger effektiv - oder sogar völlig ineffektiv - ist, wenn es sich um kleinere Systeme handelt, wie z.B. Kubernetes on prem für eine Handvoll Knoten oder für ein paar dedizierte VMs in der Cloud.

Für Hyperscaler kann es jedoch großartig sein. Sie müssen mit einer Vielzahl von Aufträgen jonglieren, um eine optimale Auslastung zu erreichen, und das erklärt zum Teil die hohe Serverauslastung, die sie angeben. Die Auslastungsraten, die AWS angibt, implizieren, dass AWS weniger als ein Viertel der Hardware benötigt, die du für die gleiche Arbeit vor Ort einsetzen würdest. Genaue Zahlen sind schwer zu ermitteln, aber die von AWS genannte Zahl ist mehr als plausibel (wahrscheinlich unterschätzt sie das Einsparpotenzial von AWS).

Eine geringere Anzahl von Servern bedeutet, dass viel weniger Strom verbraucht und Kohlenstoff gebunden wird. Der einfachste Schritt in Sachen Nachhaltigkeit ist daher oft, deine Systeme in die Cloud zu verlagern und die dortigen Dienste zu nutzen, einschließlich der gesamten Bandbreite an Instanztypen. Nur wenn du die optimierten Dienste und Zeitplanungsprogramme nutzt, kannst du diese Zahlen erreichen. Wenn du deine Systeme auf dedizierte Server verlagerst, kannst du nicht erwarten, dass sie besonders umweltfreundlich sind, selbst wenn du Kubernetes wie ein Profi einsetzt.

Wie wir bereits gesagt haben, gehen Skalierung und Effizienz Hand in Hand. Hyperscaler können den enormen technischen Aufwand investieren, um hypereffizient zu sein, weil das ihr Hauptgeschäft ist. Wenn dein Unternehmen Versicherungen verkauft, wirst du nie den finanziellen Anreiz haben, einen hypereffizienten On-Premise-Serverraum zu bauen, selbst wenn das möglich wäre. Du würdest sogar nicht in deinem eigenen Interesse handeln, weil es kein Unterscheidungsmerkmal wäre.

Zeitverschiebung und Spot-Instanzen

Die bereits erwähnten Zeitplannungsprogramme erhalten eine zusätzliche Dimension der Flexibilität, wenn wir die Zeit in den Mix einbeziehen. Architekturen, die Aufträge mit niedriger Priorität oder verzögerbaren Aufträgen erkennen und verwalten können, sind besonders bei hoher Maschinenauslastung einsatzfähig, und wie wir im nächsten Kapitel erläutern werden, sind diese Architekturen für das Umweltbewusstsein von entscheidender Bedeutung. Der GreenTech-Experte Paul Johnston ( ) sagt: "Always on is unsustainable.

Das bringt uns zu einer interessanten Variante der Cluster-Planung: dem Cloud-Konzept der Spot-Instances (wie sie bei AWS und Azure genannt werden; bei GCP heißen sie Preemptible Instances).

Spot-Instances werden von Public Cloud-Providern genutzt, um eine noch bessere Maschinenauslastung zu erreichen, indem sie freie Kapazitäten nutzen. Du kannst deinen Auftrag in eine Spot-Instanz geben und er wird vielleicht erledigt, vielleicht aber auch nicht. Wenn du es immer wieder versuchst, wird er wahrscheinlich irgendwann erledigt, aber es gibt keine Garantie für den Zeitpunkt. Mit anderen Worten: Die Aufträge müssen sehr zeitlich verschiebbar sein. Im Gegenzug für diesen Laissez-faire-Ansatz bei der Zeitplanung erhalten die Nutzer/innen 90% Rabatt auf den Standardpreis für das Hosting.

Eine Spot-Instanz kombiniert mehrere der gerade besprochenen intelligenten Zeitplanungskonzepte. Es ist ein Weg, um:

• Deinen Auftrag in einer VM verpacken

• Als zeitlich unsensibel abstempeln

• Lass deinen Cloud-Provider planen, wann und wo er will

Potenziell (d.h. abhängig von den Faktoren, die in die Planungsentscheidungen der Cloud einfließen) könnte die Nutzung von Spot-Instanzen eine der grünsten Möglichkeiten sein, ein System zu betreiben. Wir würden es gerne sehen, wenn Hyperscaler die Kohlenstoffintensität des lokalen Netzes bei der Planung von Spot-Instance-Workloads berücksichtigen würden, und wir erwarten, dass dies bis 2025 der Fall sein wird. Google spricht bereits über solche Schritte.

Fallstudie: Chaos Engineering

Skyscanner ist ein Flugbuchungsdienst in Großbritannien, der vor einigen Jahren den Großteil seines Betriebs auf AWS-Spot-Instanzen umstellte. Seltsamerweise ging es dem Unternehmen nicht in erster Linie darum, umweltfreundlicher zu werden oder Geld zu sparen, obwohl Skyscanner, wie die meisten von uns, viel Wert auf diese beiden Dinge legt. Das Unternehmen hat es getan, weil es ein Fan des Konzepts des Chaos Engineering ist.

Chaos-Engineering ist die Idee, dass du bei deinen Ingenieuren eine Denkweise schaffen kannst, die dazu führt, dass deine Systeme robuster werden, indem du sicherstellst, dass deine Produktionsplattform unzuverlässig ist.

Das ist kontraintuitiv, oder? Aber es funktioniert. Es erzwingt die Umsetzung von Resilienzstrategien.

Spot-Instances passen perfekt in das Chaos-Engineering-Modell. Spot-Instanzen können deinen laufenden Aufträgen jederzeit den Boden unter den Füßen wegziehen, da es keinerlei Verfügbarkeitsgarantien gibt. Spot-Instanzen halfen Skyscanner, die gewünschte hohe Systemrobustheit zu erreichen, und - als angenehmer Nebeneffekt - sparten sie dem Unternehmen eine Menge Geld bei den Hosting-Rechnungen und verringerten seine Kohlenstoffemissionen massiv. Stuart Davidson, Director of Engineering, sagt: "Es ist ein gutes Gefühl, wenn man seine Systeme robuster macht, die Hosting-Rechnungen senkt und gleichzeitig den Kohlendioxidausstoß reduziert."²

Dies ist ein gutes Beispiel dafür, dass die Entscheidung für eine grüne Architektur oft nützliche Vorteile mit sich bringt. In diesem Fall: Widerstandsfähigkeit und Kosteneinsparungen. In Kapitel 11 werden wir mehr über die zusätzlichen Vorteile einer grünen Architektur sprechen.

Multitenancy

In einem Kapitel über betriebliche Effizienz wäre es ein Hohn, wenn wir das Konzept der Mandantenfähigkeit nicht erwähnen würden.

Multitenancy bedeutet, dass eine einzelne Instanz eines Servers von mehreren Nutzern gemeinsam genutzt wird, und ist für eine wirklich hohe Rechnerauslastung unerlässlich. Grundsätzlich gilt: Je mehr verschiedene Nutzer (auch Tenants genannt) du hast, desto besser ist die Auslastung.

Warum ist das so? Betrachten wir doch mal das Gegenteil. Wenn alle deine Mieter/innen E-Commerce-Händler/innen wären, würden sie alle am Black Friday und in der Vorweihnachtszeit mehr Ressourcen benötigen. Sie würden auch abends und mittags (Haupteinkaufszeit) mehr Anfragen bearbeiten wollen. Eine derartig korrelierte Nachfrage ist schlecht für die Auslastung.

Du willst nicht genug Maschinen für Weihnachten bereitstellen und sie dann den Rest des Jahres ungenutzt stehen lassen. Das ist nicht sehr umweltfreundlich. Es wäre maschineneffizienter, wenn der Einzelhändler seine Hardwareressourcen mit jemandem teilen könnte, der viel Arbeit zu erledigen hat, die weniger zeitkritisch ist als das Einkaufen (z. B. ML-Training). Noch optimaler wäre es, diese Ressourcen mit jemandem zu teilen, der an verschiedenen Tagen oder zu verschiedenen Tageszeiten Bedarf hat. Eine breite Mischung von Kunden ist ein weiterer Grund für die hohe Auslastung der öffentlichen Clouds.

Serverlose Dienste

Serverlose Dienste wie AWS Lambda, Azure Functions und Google Cloud Functions sind multitenant. Sie haben auch gekapselte Aufträge, achten auf eine schnelle Instanziierung und führen Aufträge aus, die kurz und einfach genug sind, dass ein Zeitplannungsprogramm weiß, was es mit ihnen tun soll (sie so schnell wie möglich ausführen und dann vergessen). Außerdem sind sie so groß, dass es sich für Public Cloud-Provider lohnt, sie zu optimieren.

Serverlose Dienste haben daher ein großes Potenzial, billig und grün zu sein. Sie machen das schon ganz gut, aber wir glauben, dass sie noch viel besser werden können. Je mehr Leute sie nutzen, desto effizienter werden sie wahrscheinlich werden.

Hyperscaler und Gewinn

Es gibt kein magisches Geheimnis, wie man in der Technik grün wird. Es geht vor allem darum, viel effizienter und weniger verschwenderisch zu sein, was den Wünschen aller entspricht, die ihre Hostingkosten im Griff haben wollen.

Adam Jackson, ehemaliger Azure DevRel, meint: "Das nicht ganz so schmutzige Geheimnis der Public Cloud-Anbieter ist, dass die Gewinnspanne umso höher ist, je billiger ein Dienst ist. Die Cloud-Provider wollen, dass du dich für die billigste Option entscheidest, denn damit verdienen sie am meisten Geld."

Diese Dienstleistungen sind billig, weil sie effizient sind und in großem Maßstab erbracht werden. Wie der Ökonom Adam Smith im 17. Jahrhundert feststellte: "Wir erwarten unser Essen nicht vom Wohlwollen des Metzgers, des Brauers oder des Bäckers, sondern von der Rücksichtnahme auf ihre eigenen Interessen." In gleicher Weise machen die Hypercloud-Anbieter ihre Systeme zu ihrem eigenen Vorteil effizient. In diesem Fall ist es aber auch zu unserem Vorteil, denn wir wissen, dass Effizienz zwar kein genauer Indikator für Umweltfreundlichkeit ist, aber auch nicht schlecht.

Wenn du deine Hosting-Rechnungen reduzierst, indem du die billigsten, effizientesten und standardisierten Dienste nutzt, die du finden kannst, liegt das nicht nur in deinem Interesse und dem des Planeten, sondern auch im Interesse deines Anbieters. Er wird dadurch mehr Geld verdienen, und das ist eine gute Sache. Geld zu verdienen ist nicht verkehrt. Mitten in einer energiebedingten Klimakrise ineffizient zu sein, schon. Das macht auch deutlich, warum betriebliche Effizienz die beste Form der Effizienz ist: Sie kann den Betreibern von Verteilzentren eine Menge Geld einbringen. Sie entspricht ihren Interessen, und du solltest dich für diejenigen entscheiden, die das erkennen und das nötige Kapital dafür aufbringen können.

Hinweis

Der serverlose Dienst AWS Lambda ist ein hervorragendes Beispiel dafür, wie die Effizienz eines Dienstes verbessert werden kann, wenn klar wird, dass es genug Nachfrage gibt, damit sich das lohnt. Als Lambda zum ersten Mal eingeführt wurde, verbrauchte es eine Menge Ressourcen. Er war definitiv nicht grün. Als sich jedoch die latente Nachfrage abzeichnete, investierte AWS und baute die Open-Source-Plattform Firecracker auf, die leichtere VMs für die Isolierung von Aufträgen verwendet und auch die Instanziierungszeiten und die Planung verbessert. Solange es eine ungenutzte Nachfrage gibt, wird diese Kommodifizierung wahrscheinlich weitergehen. Dadurch wird AWS nicht nur billiger und umweltfreundlicher , sondern auch profitabler.

SRE-Praktiken

Site Reliability Engineering (SRE) ist ein Konzept, das ursprünglich von einem anderen effizienzbesessenen Hyperscaler stammt: Google. SREs sind dafür verantwortlich, zuverlässige und robuste Systeme zu entwerfen, zu bauen und zu warten, die einen hohen Datenverkehr bewältigen können und trotzdem reibungslos funktionieren. Die gute Nachricht ist, dass grüne Betriebsabläufe mit den SRE-Prinzipien übereinstimmen, und wenn du eine SRE-Organisation hast, sollte es einfacher sein, grün zu sein.

SREs praktizieren:

• Überwachung (die auch Kohlenstoffemissionen umfassen sollte; siehe Kapitel 9 für unsere Ansichten zur Messung von Kohlenstoffemissionen und Kapitel 10 für unsere Ansichten zur Verwendung dieser Messungen)

• Kontinuierliche Integration und Auslieferung (was dabei helfen kann, die Emissionsreduzierung schneller und sicherer zu erreichen und zu testen)

• Automatisierung (z. B. IaC, hilft bei der Verkleinerung)

• Containerisierung und Microservices (die besser automatisierbar sind und bedeuten, dass dein gesamtes System nicht gezwungen ist, auf Abruf zu arbeiten, und mehr Kohlenstoffbewusstsein haben kann)

Dies ist kein Buch über die bewährten Methoden und Prinzipien von SRE, daher werden wir nicht im Detail auf sie eingehen, obwohl wir sie in Kapitel 11 näher erläutern. Es gibt jedoch zahlreiche Bücher von O'Reilly, die diese Themen hervorragend und detailliert behandeln.

LightSwitchOps

Das meiste, worüber wir bisher gesprochen haben, war cleveres Hightech-Zeug. Es gibt jedoch einige einfache Ideen zur betrieblichen Effizienz, die jeder umsetzen kann. Eine der klügsten Ideen stammt von Holly Cummins von Red Hat. Sie heißt LightSwitchOps (siehe Abbildung 4-3).

Abbildung 4-3. LightSwitchOps wie von Holly dargestellt

Das Schließen von Zombie-Workloads (Cummins' Begriff für Anwendungen und Dienste, die nichts mehr tun) sollte ein Selbstläufer sein, um Energie zu sparen.

In einem kürzlich durchgeführten Praxisexperiment stellte ein großer VM-Anbieter, der einen seiner Rechenzentren verlegt hatte, fest, dass auf zwei Dritteln seiner Server Anwendungen liefen, die kaum noch genutzt wurden. Es handelte sich also um Zombie-Workloads.

Martin Lippert, Spring Tools Lead & Sustainability Ambassador bei VMware, erklärt: "2019 hat VMware ein Rechenzentrum in Singapur konsolidiert. Das Team wollte das gesamte Rechenzentrum umziehen und untersuchte deshalb, was genau migriert werden musste. Das Ergebnis war etwas schockierend: 66% aller Host-Maschinen waren Zombies."³

Diese Art von Verschwendung bietet ein riesiges Potenzial für Kohlenstoffeinsparungen. Die traurige Realität ist, dass auf vielen deiner Maschinen auch Anwendungen und Dienste laufen, die keinen Mehrwert mehr bringen.

Das Problem ist nur, welche sind das genau?

Es gibt verschiedene Möglichkeiten, um herauszufinden, ob ein Dienst für jemanden noch wichtig ist. Die effektivste ist der so genannte Schreittest. Wir überlassen es dem Leser, herauszufinden, wie das funktioniert. Eine andere Möglichkeit ist, dass Ressourcen eine bestimmte Lebensdauer haben. Du könntest z. B. versuchen, nur noch Instanzen bereitzustellen, die sich nach sechs Monaten selbst abschalten, es sei denn, jemand verlangt aktiv, dass sie weiterlaufen.

Das sind großartige Ideen, aber es gibt einen Grund, warum die Leute beides nicht tun. Sie machen sich Sorgen, dass es nicht so einfach sein könnte, eine Maschine wieder einzuschalten, wenn sie sie ausschalten.

Für einen umweltfreundlichen Betrieb ist es wichtig, dass du die Maschinen so sicher ausschalten kannst wie das Licht in deinem Flur - d.h. in dem Wissen, dass sie es tun, wenn du den Schalter umlegst, um sie wieder einzuschalten. Holly Cummins rät dir, sicherzustellen, dass du in der Lage bist, alles auszuschalten. Wenn du das nicht tust, ist dein Server zwar heute noch nicht Teil der Armee der wandelnden Toten, aber du kannst sicher sein, dass er es eines Tages sein wird.

GreenOps-Praktiker Ross Fairbanks schlägt vor, dass ein guter Einstieg in LightSwitchOps darin besteht, deine Test- und Entwicklungssysteme über Nacht und am Wochenende automatisch abzuschalten.

Zombie-Apokalypse

Neben dem Einsparen von Kohlendioxid gibt es auch Sicherheitsgründe für das Abschalten dieser Zombie-Server. Ed Harrison, ehemaliger Leiter der Sicherheitsabteilung bei Metaswitch Networks (jetzt Teil von Microsoft), sagte uns: "Einige der größten Cybersicherheitsvorfälle der letzten Zeit gehen auf Systeme zurück, von denen niemand wusste und die niemals hätten eingeschaltet werden dürfen." Er fuhr fort: "Sicherheitsteams versuchen immer, die Angriffsfläche zu verringern. Das Nachhaltigkeitsteam ist ihr bester Freund, wenn es sich darauf konzentriert, Systeme abzuschalten, die nicht mehr gebraucht werden."⁴

Standort, Standort, Standort

Es gibt noch eine unglaublich wichtige Sache, über die wir sprechen müssen. Es handelt sich um einen Schritt, der möglicherweise noch einfacher ist als LightSwitchOps, und es könnte der richtige Ort für dich sein, damit anzufangen - vor allem, wenn du in ein neues Rechenzentrum umziehst.

Du musst den richtigen Host und die richtige Region auswählen.

Die Realität ist, dass es in manchen Regionen einfacher ist, Gleichstrom mit kohlenstoffarmem Strom zu erzeugen als in anderen. Frankreich hat zum Beispiel eine riesige Atomflotte und Skandinavien hat Wind- und Wasserkraft. Gleichstromanlagen in diesen Gebieten sind sauberer.

Wir sagen noch einmal: Wähle deine Regionen mit Bedacht. Wenn du Zweifel hast, frag deinen Gastgeber.

Hinweis

Die globale Online-Wirtschaftszeitung Financial Times ist ein gutes Beispiel dafür, wie ein Standortwechsel zu einer grüneren Infrastruktur führt. Das Technikteam der Financial Timeshat den größten Teil eines Jahrzehnts damit verbracht, von Rechenzentren vor Ort, die keine Nachhaltigkeitsziele hatten, in überwiegend nachhaltige EU-Regionen in der Cloud zu wechseln.

Anne sprach 2018 mit der Financial Times (als das Unternehmen die Umstellung zu 75 % vollzogen hatte) über die Auswirkungen auf die eigenen betrieblichen Nachhaltigkeitsziele. Zu diesem Zeitpunkt waren bereits 67 % der Infrastruktur auf "klimaneutralen" Servern installiert, und das Unternehmen rechnete damit, dass dieser Anteil bei der Umstellung auf die Cloud im Jahr 2020 auf fast 90 % steigen würde (was auch geschah).

Die Formulierung "klimaneutral" wurde zwar von allen fallen gelassen, aber die Financial Times übernimmt nun das Ziel von AWS, seinen Betrieb bis 2025 zu 100 % mit erneuerbaren Energien zu versorgen, was großartig ist. Die Lehre daraus ist, dass die Wahl von Anbietern mit soliden Nachhaltigkeitszielen, zu denen sie sich verpflichtet fühlen (z. B. grüne Plattformen), dir die harte Arbeit abnimmt - es wird einfach unter deinen Füßen passieren.

Oh nein! Der Widerstand wehrt sich!

Leider standen Effizienz und Belastbarkeit schon immer in einem ungünstigen Verhältnis zueinander. Effizienz erhöht die Komplexität und damit die Anfälligkeit eines Systems, und das ist ein Problem.

Effizienz versus Widerstandsfähigkeit

In den meisten Fällen kannst du einen Dienst nicht effizienter machen, ohne gleichzeitig daran zu arbeiten, ihn widerstandsfähiger zu machen, sonst fällt er dir um. Leider bringt das die Effizienz wieder in Konflikt mit der Produktivität der Entwickler.

Zum Beispiel:

• Zeitplannungsprogramme sind komplizierte Programme, die schwierig einzurichten und erfolgreich zu nutzen sein können.

• Multitenancy birgt viele Fehlerquellen: Datenschutz und Sicherheit werden zum Problem, und es besteht immer das Risiko, dass ein Problem eines anderen Tenants auf deinem Rechner auf deine eigenen Systeme übergreift.

• Auch das Ausschalten von Dingen ist nicht ohne Risiko. Der Schrei-Test, über den wir vorhin gesprochen haben, tut genau das, was auf der Verpackung steht.

• Hinzu kommt, dass Overprovisioning eine bewährte Methode ist, um ein System kostengünstig robuster zu machen ( ). Das geht zwar auf Kosten der Hosting-Rechnungen, aber die meisten Leute nehmen diesen Kompromiss gerne in Kauf.

Um es auf den Punkt zu bringen: Effizienz ist eine Herausforderung für Resilienz.

Es gibt einige Gegenargumente. Ein Zeitplannungsprogramm ist zwar gut für die betriebliche Effizienz, aber es hat auch Vorteile für die Ausfallsicherheit. Einer der Hauptgründe für den Einsatz eines Zeitplannungsprogramms ist der automatische Neustart von Diensten bei Knoten-, Hardware- oder Netzwerkausfällen. Wenn ein Knoten ausfällt oder aus irgendeinem Grund nicht mehr verfügbar ist, kann ein Zeitplannungsprogramm die betroffenen Arbeitslasten automatisch auf andere Knoten im Cluster verlagern. Dadurch werden nicht nur die Ressourcen effizienter genutzt, sondern auch die Verfügbarkeit erhöht - vorausgesetzt, das Zeitplannungsprogramm hat den Ausfall nicht verschuldet.

Die Realität sieht jedoch so aus, dass mehr Effizienz eine riskante Angelegenheit sein kann. Die Handhabung der komplexeren Systeme erfordert neue Fähigkeiten. Als Microsoft während der COVID-Pandemie die Effizienz von Teams verbesserte, konnte das Unternehmen nicht nur die Effizienz ändern. Es musste auch seine Testverfahren verbessern, indem es Chaos-Engineering-Techniken in der Produktion einsetzte, um die Fehler in seinem neuen System zu beseitigen.

Wenn du wie Microsoft selbst direkte Effizienzverbesserungen vornimmst, wirst du wahrscheinlich mehr Tests und Korrekturen durchführen müssen. Im Beispiel von Skyscanner hat der Einsatz von Spot-Instances die Ausfallsicherheit der Systeme erhöht, die Hosting-Rechnungen gesenkt und die Umweltfreundlichkeit erhöht, aber die Hauptmotivation des Unternehmens für die Einführung von Spot-Instances war es, zusätzliche Ausfallsicherheitstests zu erzwingen.

Effizienz geht in der Regel Hand in Hand mit Spezialisierung und ist am effektivsten bei hoher Skalierung, aber Skalierung birgt auch Gefahren. Die Europäische Union befürchtet, dass wir all unsere Computer-Eier in die Körbe einiger weniger US-amerikanischer Hyperscaler legen, was zu einer fragilen Welt führen könnte. Die EU hat Recht und hat die Sustainable Digital Infrastructure Alliance(SDIA) gegründet, um dieses Risiko zu bekämpfen.

Auf der anderen Seite wissen wir, dass die gleiche Konzentration zu weniger Maschinen und weniger Stromverbrauch führen wird. Für die kleineren Anbieter, aus denen sich die SDIA zusammensetzt, wird es schwer sein, die Skaleneffizienz der Hyperscaler zu erreichen, selbst wenn sie sich, wie von der SDIA empfohlen, für eine vernünftige Open-Source-Hosting-Technologie entscheiden.

Die riesigen Rechenzentren, die derzeit von Amazon, Google, Microsoft und Alibaba gebaut werden, mögen uns vielleicht nicht gefallen, aber sie werden mit ziemlicher Sicherheit viel effizienter sein als tausend kleinere Rechenzentren, selbst wenn diese nur ein paar Instagram-taugliche städtische Schwimmbäder oder Stadtteile erwärmen, wie es die EU derzeit fordert.

Beachte, dass wir die neuen EU-Vorgaben zur Emissionstransparenz lieben. Wir machen uns nicht über die EU lustig, auch wenn aus dem einen oder anderen Grund keiner von uns mehr in ihr lebt. Nichtsdestotrotz würden wir es vorziehen, wenn Gleichstromanlagen in der Nähe von Windturbinen oder Solarparks angesiedelt wären, wo sie den unerwarteten Stromüberschuss nutzen könnten, anstatt mit den Haushalten in den städtischen Netzgebieten um kostbaren Strom zu konkurrieren.

Grüne betriebliche Instrumente und Techniken

Schauen wir uns die wichtigsten Schritte an, die du zur Verbesserung der betrieblichen Effizienz unternehmen kannst. Einige sind schwierig, aber die gute Nachricht ist, dass viele davon ganz einfach sind, vor allem im Vergleich zur Code-Effizienz. Erinnere dich: Es geht um die Maschinenauslastung.

• Schalte Dinge aus, wenn sie kaum benutzt werden oder wenn sie nicht gebraucht werden, wie z.B. Testsysteme am Wochenende (Holly Cummins' LightSwitchOps).

• Stelle nicht zu viele Instanzen bereit (verwende Rightsizing und Autoscaling, burstable Instances in der Cloud). Erinnere dich daran, dass die Autoskalierung sowohl nach unten als auch nach oben funktioniert, sonst ist sie nur beim ersten Mal nützlich!

• Reduziere deine Hosting-Rechnungen so weit wie möglich, indem du z. B. den AWS Cost Explorer oder die Kostenanalyse von Azure nutzt oder einen nicht-hyperskalierenden Dienst wie CloudZero, ControlPlane oder Harness. Mit einem einfachen Audit lassen sich oft auch Zombie-Dienste identifizieren. Billiger ist fast immer grüner.

• Containerisierte Microservice-Architekturen, die Aufgaben mit niedriger Priorität und/oder verzögerbaren Aufgaben erkennen, können mit einer höheren Maschinenauslastung betrieben werden. Beachte jedoch, dass eine Erhöhung der architektonischen Komplexität durch eine übermäßige Anzahl von Microservices auch zu einer Überversorgung führen kann. Du musst trotzdem die bewährten Methoden für das Design von Microservices befolgen, also lies zum Beispiel Building Microservices (O'Reilly) von Sam Newman.

• Wenn du in der Cloud arbeitest, haben dedizierte Instance-Typen kein Kohlenstoffbewusstsein und eine geringe Maschinenauslastung. Wenn du dich für Instance-Typen entscheidest, die dem Host mehr Flexibilität bieten, kannst du die Auslastung erhöhen und die Kohlenstoffemissionen und Kosten senken.

• Nutze die Mandantenfähigkeit von gemeinsam genutzten VMs bis hin zu verwalteten Container-Plattformen.

• Nutze effiziente, hochskalierte, voroptimierte Cloud-Dienste und Instanztypen (wie Burstable Instances, verwaltete Datenbanken und serverlose Dienste). Oder verwende gleichwertige Open-Source-Produkte, die sich zu umweltfreundlichen oder effizienten Praktiken verpflichten, eine tatkräftige Community haben, die sie an diese Verpflichtungen bindet, und über die nötige Größe verfügen, um sie realistisch zu erfüllen.

• Erinnere dich daran, dass Spot-Instances auf AWS oder Azure (preemptible Instances auf GCP) großartig sind - billig, effizient, umweltfreundlich und eine Plattform, die deine Systeme dazu ermutigt, widerstandsfähig zu sein.

• Das alles ist nicht einfach, aber die SRE-Prinzipien können helfen: CI/CD, Überwachung und Automatisierung.

Leider ist das alles nicht ohne Arbeit. Selbst wenn du weniger verbrauchst oder Dinge ausschaltest, musst du Zeit und Aufmerksamkeit investieren. Das Schöne daran, umweltbewusst zu handeln, ist jedoch, dass du dadurch zumindest Geld sparen kannst. Das erste System, das du unter dem Gesichtspunkt der Umweltfreundlichkeit ins Visier nimmst, sollte also auch das sein, von dem du deinen Vorgesetzten am leichtesten überzeugen kannst: dein teuerstes System.

Allerdings ist alles, was nicht arbeitsfrei ist, auch wenn es eine Menge Geld spart, schwer zu verkaufen. Es wird einfacher sein, die Investition zu bekommen, wenn du deine Umstellung auf umweltfreundliche Betriebsabläufe mit einer schnelleren Lieferung oder einer Zeitersparnis bei der Entwicklung oder im Betrieb verknüpfen kannst, denn diese Ideen sind für Unternehmen attraktiv.

Das heißt, die effektivsten der vorgeschlagenen Schritte sind die letzten fünf. Schau dir die SRE-Prinzipien, Multitenancy, Managed Services, grüne Open-Source-Bibliotheken und Spot-Instances an. Sie sind alle darauf ausgelegt, langfristig Entwicklungs- und Betriebszeit zu sparen, und sie sind billig und grün, weil sie standardisiert und skalierbar sind. Kämpfe nicht gegen die Maschine. Um grün zu werden, ohne die Produktivität von Entwicklern zu zerstören, musst du grüne Plattformen wählen.

Um die Energiewende zu überleben, müssen wir davon ausgehen, dass alles tausendmal kohlenstoffeffizienter werden muss, und zwar durch eine Kombination aus Betriebseffizienz, Nachfrageverlagerung und schließlich Code-Effizienz, die alle durch grüne Plattformen erreicht werden. So ehrgeizig es auch klingt, das sollte machbar sein. Es geht darum, die erhöhten Hardwarekapazitäten, die wir in den letzten 30 Jahren für die Entwicklerproduktivität genutzt haben, freizugeben und gleichzeitig die Produktivität der Entwickler zu erhalten.

Es könnte ein Jahrzehnt dauern, aber es wird passieren. Deine Aufgabe ist es, sicherzustellen, dass alle deine Plattformanbieter, egal ob Public Cloud, Open Source oder Closed Source, eine glaubwürdige Strategie haben, um diese Art von Umweltfreundlichkeit zu erreichen. Das ist die Frage, die du dir ständig stellen musst: "Ist dies eine grüne Plattform?"

¹ Ross Fairbanks, persönliche Mitteilung.

² Stuart Davidson, persönliche Mitteilung.

³ Martin Lippert, persönliche Mitteilung.

⁴ Ed Harrison, persönliche Mitteilung.