Green Software Patterns

Die Green Software Foundation hat begonnen, an Green Software Patterns zu arbeiten.

Da wir sehr stark mit den Zielen der Green Software Foundation übereinstimmen, wollten wir einige dieser Muster, angewendet im Kontext von DownToZero.Cloud, in den Fokus jeder Person rücken.

• Green Software Patterns

Artificial Intelligence (AI)

https://patterns.greensoftware.foundation/catalog/ai/

Da wir keine KI-bezogenen Dienste anbieten, überspringen wir diesen Abschnitt des Katalogs.

Cloud

https://patterns.greensoftware.foundation/catalog/cloud/

Cache static data

Aus energieeffizienztechnischer Sicht ist es besser, den Netzwerkverkehr zu reduzieren, indem die Daten lokal über einen Cache gelesen werden, anstatt sie remote über das Netzwerk abzurufen.

Wir cachen bei vielen Instanzen während der Anfrageverarbeitung, z. B. cacht unsere asynchrone Job-Laufzeit lokal Docker-Images, sodass wir nicht bei jeder Ausführung einen kompletten Pull benötigen.

Wir verwenden außerdem Image-Hashes für Container-Images so weit wie möglich, um die Echtzeitbelastung beim Starten neuer Container zu verringern.

Choose the region that is closest to users

Aus energieeffizienztechnischer Sicht ist es besser, die Entfernung, die ein Netzwerkpaket zurücklegt, zu verkürzen, damit weniger Energie für die Übertragung benötigt wird. Ebenso gilt aus Sicht des eingebetteten Kohlenstoffs: Wenn ein Netzwerkpaket weniger Hardware passiert, sind wir mit der Hardware effizienter.

Da wir nicht multi-region sind oder die regionale Struktur unserer Infrastruktur nicht direkt offenlegen, kann dies nicht vom Nutzer beeinflusst werden. Intern versuchen wir, so gut wie möglich regional zu optimieren, ohne Haltbarkeit und Verfügbarkeit zu beeinträchtigen.

Compress stored data

Die Speicherung von zu vielen unkomprimierten Daten kann zu Bandbreitenverschwendung führen und die Anforderungen an die Speicherkapazität erhöhen.

Wir verpflichten uns, nur komprimierte Daten zu speichern.

Sowohl Objectstore als auch Container Registry unterstützen Kompression auf Speicherebene. Dies ist in beiden Diensten integriert. Der Observability-Service verfügt über einen internen tiering-Mechanismus, der Daten nach einer festen Aufbewahrungsfrist von einer heißen Speicherstufe in ein kälteres, besser komprimiertes Format verschiebt.

Compress transmitted data

Aus energieeffizienztechnischer Sicht ist es besser, die Größe der übertragenen Daten zu minimieren, damit weniger Energie verbraucht wird, da der Netzwerkverkehr reduziert wird.

Containerize your workloads

Container ermöglichen eine flexiblere Ressourcennutzung, da Workloads einfach zwischen Maschinen verschoben werden können. Container erlauben das Bin-Packing und benötigen weniger Rechenressourcen als virtuelle Maschinen, was eine Reduzierung unnötiger Ressourcenzuweisungen und eine Steigerung der Auslastung der Rechenressourcen bedeutet.

Wir unterstützen ausschließlich containerisierte Workloads. Die Möglichkeit, Workloads zwischen Standorten zu verschieben, ist für DownToZero zentral, um Workloads bei Bedarf in effizientere Ausführungsumgebungen zu verlagern.

Delete unused storage resources

Aus Sicht des eingebetteten Kohlenstoffs ist es besser, nicht genutzte Speicherressourcen zu löschen, damit wir hardwareeffizient sind und die Speicherschicht für die Aufgabe optimiert ist.

Unser Object Store unterstützt Ablaufzeiten für Objekte, sodass jede Entität bereinigt werden kann, sobald sie nicht mehr verwendet wird. Unsere Container Registry führt ebenfalls konfigurierbare Aufräum-Jobs aus, um die Anzahl der gespeicherten Objekte zu reduzieren.

Encrypt what is necessary

Datenschutz durch Verschlüsselung ist ein entscheidender Aspekt unserer Sicherheitsmaßnahmen. Der Verschlüsselungsprozess kann jedoch auf mehreren Ebenen ressourcenintensiv sein. Erstens variiert der für die Verschlüsselung benötigte CPU-Aufwand je nach gewähltem Algorithmus, und komplexere Algorithmen erfordern tendenziell höhere Rechenleistung. Zudem kann Verschlüsselung den Speicherbedarf erhöhen, da die Größe der gespeicherten Daten durch zusätzliche Metadaten und Padding vergrößert wird, was besonders bei kleineren Dateien auffällt. Außerdem ist Verschlüsselung eine repetitive Aufgabe, die bei jedem Datenabruf oder Update durchgeführt werden muss. Diese Wiederholung kann zu erhöhtem Energieverbrauch führen, insbesondere in Systemen mit hoher Durchsatzrate.

Evaluate other CPU architectures

Anwendungen werden mit einer Software-Architektur entwickelt, die am besten zu den geschäftlichen Anforderungen passt. Cloud-Anbieter ermöglichen die einfache Bewertung anderer CPU-Typen wie x86-64, die zusammen mit vielen kosteneffizienten Alternativen mit gutem Leistungs-Watt-Verhältnis in die Bewertung einbezogen werden können.

Derzeit unterstützen wir nur eine CPU-Architektur, X86. Momentan verfügen wir nicht über die Ressourcen, um verschiedene Architekturen zu evaluieren.

Use a service mesh only if needed

Ein Service Mesh setzt zusätzliche Container für die Kommunikation ein, typischerweise im Sidecar-Muster, um erweiterte Betriebsmöglichkeiten zu bieten. Dies kann zu einer Erhöhung der CPU-Auslastung und des Netzwerkverkehrs führen, ermöglicht jedoch die Entkopplung der Anwendung von diesen Funktionen, indem sie von der Anwendungsschicht auf die Infrastrukturebene verschoben werden.

Da unser Netzwerk nicht auf Kubernetes-Abstraktionen basiert, haben wir auch keinen Nutzen für ein Service Mesh.

Terminate TLS at border gateway

Transport Layer Security (TLS) stellt sicher, dass alle Daten zwischen Webserver und Webbrowser privat und verschlüsselt bleiben. Das Beenden und erneute Herstellen von TLS erhöht jedoch den CPU-Verbrauch und kann in bestimmten Architekturen unnötig sein.

Implement stateless design

Status eines Dienstes bezieht sich auf die im Speicher oder auf der Festplatte gespeicherten Daten, die ein Dienst benötigt, um zu funktionieren. Der Status umfasst die Datenstrukturen und Mitglieder, die der Dienst liest und schreibt. Je nach Architektur des Dienstes kann der Status auch Dateien oder andere Ressourcen auf der Festplatte enthalten.

Unsere bestehenden Dienste, wie Container Services und Container Jobs, basieren auf stateless Design und bieten diese Möglichkeiten auch unseren Nutzern.

Match your service level objectives to business needs

Wenn Serviceausfälle akzeptabel sind, ist es besser, nicht auf höchste Verfügbarkeit zu setzen, sondern die Lösung entsprechend den realen Geschäftsbedürfnissen zu gestalten. Niedrigere Verfügbarkeitsgarantien können helfen, den Energieverbrauch zu senken, indem weniger Infrastrukturkomponenten genutzt werden.

Unser SLO ist es, den bestmöglichen Service zu bieten, ohne dabei Effizienz und Nachhaltigkeit zu vernachlässigen. Daher hängen unsere Dienste stark von automatischer Skalierung ab, um stets ein angemessenes Servicelevel mit minimalem Overhead bereitzustellen.

Match utilization requirements of virtual machines (VMs)

Es ist besser, eine VM mit hoher Auslastung laufen zu lassen, als zwei mit niedriger Auslastung – nicht nur hinsichtlich der Energieproportionalität, sondern auch im Hinblick auf den eingebetteten Kohlenstoff.

Bisher bieten wir keine VM-basierten Dienste an. Alle unsere Infrastrukturangebote basieren auf Containern, um eine optimierte Nutzererfahrung zu gewährleisten.

Match utilization requirements with pre-configured servers

Es ist besser, eine VM mit hoher Auslastung laufen zu lassen, als zwei mit niedriger Auslastung – nicht nur hinsichtlich der Energieproportionalität, sondern auch im Hinblick auf den eingebetteten Kohlenstoff.

Wir streben eine hohe Auslastung unserer Infrastruktur an, jedoch sind diese Komponenten nicht für Endnutzer sichtbar. Der Nutzer sieht nur Container als Abstraktion. Da wir Energieeffizienzmetriken bereitstellen, können diese basierend auf der Auslastung der zugrundeliegenden Infrastruktur variieren.

Minimize the total number of deployed environments

In einer Anwendung kann es notwendig sein, mehrere Umgebungen im Anwendungsworkflow zu nutzen. Typischerweise wird eine Entwicklungsumgebung für regelmäßige Updates verwendet, während Staging- oder Testumgebungen sicherstellen, dass keine Probleme auftreten, bevor Code in die Produktionsumgebung gelangt, auf die Nutzer Zugriff haben.

Optimise storage utilization

Es ist besser, die Speicherauslastung zu maximieren, sodass die Speicherschicht für die Aufgabe optimiert ist, nicht nur hinsichtlich Energieproportionalität, sondern auch des eingebetteten Kohlenstoffs.

Optimize average CPU utilization

CPU-Nutzung und Auslastung variieren im Tagesverlauf, manchmal stark für unterschiedliche Rechenanforderungen. Je größer die Varianz zwischen Durchschnitts- und Spitzen-Auslastung ist, desto mehr Ressourcen müssen im Standby bereitstehen, um Traffic-Spitzen abzufangen.

Optimize impact on customer devices and equipment

Anwendungen laufen auf Kundenhardware oder werden darauf dargestellt. Die vom Kunden genutzte Hardware hat einen Kohlenstoff-Fußabdruck, der durch Produktion und den Stromverbrauch während des Betriebs entsteht. Durch Optimierung des Software-Designs und der Architektur zur Verlängerung der Lebensdauer der Kundenhardware wird die Kohlenstoffintensität der Anwendung reduziert. Idealerweise kann der Kunde die Hardware bis zum Ausfall oder bis zur Obsoleszenz nutzen.

Optimize peak CPU utilization

CPU-Nutzung und Auslastung variieren im Tagesverlauf, manchmal stark für unterschiedliche Rechenanforderungen. Je größer die Varianz zwischen Durchschnitts- und Spitzen-Auslastung ist, desto mehr Ressourcen müssen im Standby bereitstehen, um Traffic-Spitzen abzufangen.

Queue non-urgent processing requests

Alle Systeme haben Zeiten mit Hochauslastung und Niedriglast. Aus hardwareeffizienztechnischer Sicht sind wir effizienter, wenn wir die Auswirkungen von Anfragespitzen minimieren und eine gleichmäßige Auslastung der Komponenten erzielen. Aus energieeffizienztechnischer Sicht sind wir effizienter, wenn wir die Leerlaufressourcen minimieren.

Unser Dienst Container Jobs ist die Umsetzung dieses Ziels als Service innerhalb von DTZ.

Reduce transmitted data

Aus energieeffizienztechnischer Sicht ist es besser, die Größe der übertragenen Daten zu minimieren, damit weniger Energie verbraucht wird, da der Netzwerkverkehr reduziert wird.

Remove unused assets

Überwache und analysiere die Anwendung und die Cloud-Abrechnung, um Ressourcen zu identifizieren, die nicht mehr genutzt werden oder reduziert werden können.

Scale down kubernetes applications when not in use

Um CO2-Emissionen und Kosten zu reduzieren, können Dev&Test Kubernetes Cluster außerhalb der Bürozeiten (z. B. nachts & am Wochenende) Knoten (VMs) abschalten. => Damit wird auf Clusterebene optimiert.

Wir bieten keine Kubernetes-basierten Dienste an.

Scale down applications when not in use

Anwendungen verbrauchen CPU, auch wenn sie nicht aktiv genutzt werden. Zum Beispiel durch Hintergrund-Timer, Müllsammlung, Gesundheitsprüfungen etc. Selbst wenn die Anwendung heruntergefahren ist, verbraucht die zugrundeliegende Hardware Leerlaufstrom. Dies kann auch bei Entwicklungs- und Testanwendungen oder Hardware außerhalb der Bürozeiten passieren.

DownToZero steht, wie der Name sagt, für Skalierung nach unten. Daher streben wir bei allen Diensten an, Skalierungen nach unten zu ermöglichen.

Scale infrastructure with user load

Der Ressourcenbedarf richtet sich nach der Nutzerlast zu einem bestimmten Zeitpunkt. Die meisten Anwendungen berücksichtigen dies jedoch nicht, was zu Unterauslastung und Ineffizienz führt.

Scale Kubernetes workloads based on relevant demand metrics

Standardmäßig skaliert Kubernetes Workloads basierend auf CPU- und RAM-Auslastung. In der Praxis ist es jedoch schwierig, die Nachfrage-Treiber der Anwendung mit CPU- und RAM-Auslastung zu korrelieren.

Wir bieten keine Kubernetes-Dienste an.

Scale logical components independently

Eine Microservice-Architektur kann die benötigten Rechenressourcen reduzieren, da jede unabhängige Komponente entsprechend ihrem eigenen Bedarf skaliert werden kann.

Scan for vulnerabilities

Viele Angriffe auf Cloud-Infrastrukturen zielen darauf ab, bereitgestellte Ressourcen zu missbrauchen, was zu unnötigen Nutzungsspitzen und Kosten führt.

Set storage retention policies

Aus Sicht des eingebetteten Kohlenstoffs ist es besser, einen automatisierten Mechanismus zur Löschung ungenutzter Speicherressourcen zu haben, damit wir hardwareeffizient sind und die Speicherschicht für die Aufgabe optimiert ist.

Shed lower priority traffic

Wenn Ressourcen während stark frequentierter Ereignisse oder bei hoher Kohlenstoffintensität knapp sind, erzeugt Ihr System mehr CO2-Emissionen. Die Hinzufügung weiterer Ressourcen zur Unterstützung erhöhter Anforderungen bringt zusätzlich CO2-Emissionen und Strombedarf mit sich. Weiterhin alle Anfragen bei hoher Kohlenstoffintensität zu verarbeiten, erhöht die Gesamtemissionen. Priorisierte Reduzierung von Verkehr mit niedriger Priorität während dieser Szenarien spart Ressourcen und CO2-Emissionen. Dieser Ansatz erfordert ein Verständnis des Verkehrs, einschließlich der kritischen Aufrufe und derjenigen, die Wiederholungsversuche und Fehler am besten verkraften.

Time-shift Kubernetes cron jobs

Die CO2-Emissionen eines Softwaresystems hängen vom Stromverbrauch und von der Kohlenstoffintensität des Stromnetzes ab. Deshalb kann es ineffizient sein, energieeffiziente Software auf einem kohlenstoffintensiven Netz zu betreiben, um globale Emissionen zu senken.

Obwohl wir keine Kubernetes-Dienste anbieten, ermöglichen unsere Container Jobs ein flexibles Zeitplan-Modell. Weitere Informationen finden Sie in unseren Docs.

Use Asynchronous network calls instead of synchronous

Beim Aufrufen von Datenbanken, Dateisystemen oder REST-APIs über Prozessgrenzen hinweg kann die Verwendung synchroner Aufrufe dazu führen, dass der aufrufende Thread blockiert wird, was die CPU zusätzlich belastet.

Use circuit breaker patterns

Moderne Anwendungen müssen regelmäßig mit anderen Anwendungen kommunizieren. Da diese eigenen Deployment-Plan, Ausfallzeiten und Verfügbarkeit haben, kann die Netzwerkverbindung fehlerhaft sein. Wenn die andere Anwendung nicht erreichbar ist, schlagen alle Anfragen fehl, und zukünftige Anfragen sind zwecklos.

Use cloud native network security tools and controls

Netzwerk- und Webanwendungsfirewalls schützen vor den meisten gängigen Angriffen und reduzieren bösartigen Bot-Traffic. Diese Tools helfen, unnötige Datenübertragung zu vermeiden, die Belastung der Cloud-Infrastruktur zu vermindern und weniger Bandbreite sowie Infrastruktur zu nutzen.

Use DDoS protection

Distributed Denial of Service (DDoS)-Angriffe erhöhen die Serverlast, sodass dieser keine legitimen Anfragen mehr bearbeiten kann. Dies geschieht meist, um dem Betreiber von Service oder Hardware zu schaden. Aufgrund der Angriffsmethode werden viele Umweltressourcen durch sinnlose Anfragen verbraucht.

Use cloud native processor VMs

Cloud-VMs verfügen über verschiedene Eigenschaften, je nach verbautem Prozessor. Virtuelle Maschinen anhand der Effizienz ihrer Prozessoren auszuwählen, wirkt sich auf die Hardwareeffizienz aus und reduziert CO2-Emissionen.

Use serverless cloud services

Serverlose Cloud-Dienste werden vom Cloud-Anbieter für die Anwendung verwaltet. Sie skalieren dynamisch mit der Arbeitslast und wenden Best Practices an, um den Ressourceneinsatz minimal zu halten.

Alle Angebote von DownToZero sind serverlose Cloud-Dienste.

Web

https://patterns.greensoftware.foundation/catalog/web/

Da wir keine Web-bezogenen Dienste anbieten, überspringen wir diesen Abschnitt des Katalogs.