Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

Produktentwicklung

IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Informatik aktuell

In sechs Schritten zu einer nachhaltigen Cloud-Architektur

Artikel von Dennis Breitling bei sysbus.de

<p>Überall wird von der Cloud geschwärmt: Grenzenlose Skalierung und unzählige Features sind bereits „out of the box“ verfügbar. Das alles gibt es zu unschlagbar günstigen Preisen. Das Thema Nachhaltigkeit kommt dabei selten zur Sprache. Rechenzentren verbrauchen heute aber schon ähnlich viel Energie wie Kleinstädte und der Energiebedarf <a href="https://www.sueddeutsche.de/wirtschaft/cloud-energieverbrauch-strom-digitalisierung-1.5529289" target="_blank">steigt immer weiter an</a> . Dabei stellen sich in Bezug auf Nachhaltigkeit andere Fragen, als wir es in der IT normalerweise gewohnt sind: Ist der schnellste Server wirklich notwendig? Wie wirkt sich ein kleineres Modell auf den CO2-Ausstoß aus? Können wir unsere Cloud-Emissionen durch die Nutzung von Serverless-Services optimieren oder behalten wir lieber die Zügel in der Hand?</p><p>Um diese Fragen zu beantworten, müssen wir zunächst eine Idee von unseren aktuellen Cloud-Emissionen bekommen. Erst auf Basis des Ist-Zustands lassen sich mögliche Verbesserungen feststellen und der CO2-Verbrauch optimieren.</p><h2>Cloud-Emissionen-Analyse der drei großen Anbieter im Vergleich</h2><p>Mittlerweile haben die großen Cloud-Provider das Thema Nachhaltigkeit für sich entdeckt und werben mit ambitionierten Nachhaltigkeitszielen – egal ob Amazon Web Services (<a href="https://sustainability.aboutamazon.com/environment/the-cloud" target="_blank">AWS</a> ), <a href="https://azure.microsoft.com/de-de/global-infrastructure/sustainability/#overview" target="_blank">Azure</a>  von Microsoft oder die Google Cloud Platform (<a href="https://cloud.google.com/sustainability?hl=de" target="_blank">GCP</a> ). Im Folgenden werfen wir einen Blick auf die Tools, die Emissionen unserer Cloud-Architektur messen und aufbereiten.</p><h3>Emissionen bei Amazon Web Services messen</h3><p>AWS gibt eigene Best Practices im <i>Well-Architected Framework</i> heraus. Bei der <a href="https://www.youtube.com/watch?v=8_Xs8Ik0h1w&t=5299s" target="_blank">re:Invent 2021</a>  hat das Unternehmen die <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html" target="_blank">Sustainability Pillar</a>  in die Sammlung aufgenommen. Die Dokumentation ist aktuell aber noch ausbaufähig. Handlungsanweisungen beschreibt AWS oft nur oberflächlich, zum Beispiel folgende Empfehlung: „Choose regions near Amazon renewable energy projects“. Die Information, welche Standorte mit erneuerbaren Energien arbeiten, bleibt Amazon aber schuldig. Das müssen wir uns selbst zusammensuchen.</p><p>Stichwort erneuerbare Energien: AWS will bis 2025 alle Services zu 100 % mit erneuerbaren Energien betreiben (<a href="https://sustainability.aboutamazon.com/environment/the-cloud?energyType=true" target="_blank">Quelle</a> ). Aktuell werden allerdings einige Regionen lediglich über Zertifikate ausgeglichen. Dazu zählt auch die für die deutschen Datenschutzanforderungen relevante Region <em>eu-central-1 (Europe / Frankfurt)</em>.</p><p>Mit dem kostenlosen <a href="https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/what-is-ccft.html" target="_blank">Carbon Footprint Tool</a>  bietet AWS eine Übersicht der Emissionen, die genutzte Services verursachen. Das Tool befindet sich in der AWS Management Console unter <i>Billing</i> – <i>Cost & Usage Reports</i>. Es wird die Berechtigung <em>sustainability:GetCarbonFootprintSummary</em> benötigt, um das Dashboard aufrufen zu können.</p><div><img src="https://media.graphassets.com/vaA74v6vQOWUw4iaiDnU" alt="AWS - Carbon Footprint Tool – Verschiedene Diagramme der Emissionen nach Regionen, Services und Zeiträumen" width="1024" height="441" /><p>AWS: Verschiedene Diagramme der Emissionen nach Regionen (Mitte) und Services (Rechts).</p></div><p>Die Angabe der Emissionen erfolgt in Tonnen CO2-Äquivalente (MTCO2e, metric tons of carbon dioxide-equivalent) und wird monatlich aktualisiert. Amazon benötigt bis zu drei Monate, um die Daten zu sammeln und aufzubereiten. Die gesammelten Daten lassen sich nach Service, Region und in unterschiedlichen Zeiträumen darstellen. Welche Services sich aber in der Gruppe „Other“ verstecken, können wir aktuell nur vermuten. Hier wäre ein höherer Detailgrad hilfreich, um die Emissionen gezielt reduzieren zu können.</p><p>Besonders interessant ist außerdem die Ansicht „Weg zu 100 % erneuerbarer Energie“, die eine Schätzung der zukünftigen Emissionen ist. Die Berechnung beruht auf den bisher genutzten Services und Regionen im gesamten AWS-Account.</p><div><img loading="lazy" src="https://media.graphassets.com/ytUHrRzQjO4WjvLXkOEe" alt="AWS - Carbon Footprint Tool – Diagramm, das den Weg zu 100 % erneuerbarer Energie darstellt" width="1024" height="378" /><p>AWS: Diagramm, das die voraussichtlich ausgestoßenen Emissionen darstellt</p></div><p><b>Fazit:</b> AWS hat einen ersten Schritt getan, um die Entwicklungsteams auf dem Weg zu einer nachhaltigeren Cloud-Architektur zu unterstützen. Es ist aktuell aber auch nicht mehr als ein erster Schritt. Das zeigt sich nicht nur am Detailgrad des Sustainability Pillars. Eine nächste, sinnvolle Verbesserung könnte die Übersicht des Strommixes in den Regionen sein. Und auch wenn das Carbon Footprint Tool einen guten Überblick gibt, sind nicht alle Auswertungen detailliert genug.</p><h3>Verfügbare Werkzeuge von Microsoft Azure</h3><p>Auch Microsoft strebt bis 2025 an, alle angebotenen Services ausschließlich durch erneuerbare Energie zu betreiben (<a href="https://azure.microsoft.com/de-de/global-infrastructure/sustainability/#carbon-benefits" target="_blank">Quelle</a> ). Aber auch hier fehlt eine Übersicht des aktuell genutzten Strommixes nach Regionen. Bei der Auswahl müssen sich User auf einzelne Ankündigungen von Azure verlassen, wie die Nachricht der Eröffnung eines <a href="https://news.microsoft.com/europe/2021/11/16/microsoft-opens-its-sustainable-datacenter-region-in-sweden-creating-new-opportunities-for-a-cloud-first-sweden/" target="_blank">neuen Rechenzentrums in Schweden</a> , das Microsoft mit 100 % erneuerbaren Energien betreibt.</p><p>Vergleichbar mit AWS bietet auch Azure ein <a href="https://appsource.microsoft.com/en-us/product/power-bi/coi-sustainability.emissions_impact_dashboard?tab=Overview" target="_blank">Emissions Impact Dashboard</a>  an. Die verursachten Cloud-Emissionen stellt es ebenfalls in Tonnen CO2-Äquivalente dar und Nutzer*innen können sie im zeitlichen Verlauf, nach Regionen und Services analysieren. Da für den Zugriff auf das Dashboard allerdings eine „Power BI Pro“-Lizenz benötigt wird, ist die Analyse nicht kostenlos.</p><div><img loading="lazy" src="https://media.graphassets.com/kc0MPTRVTF6oq6JEZAmF" alt="Azure – Emissions Impact Dashboard – Verschiedene Diagramme der Emissionen nach Services, Regionen und Zeiträumen" width="1024" height="578" /><p>Emissions Impact Dashboard – Verschiedene Diagramme der Emissionen nach Services, Regionen und Zeiträumen (<a href="https://appsource.microsoft.com/en-us/product/power-bi/coi-sustainability.emissions_impact_dashboard?tab=Overview" target="_blank">Quelle</a> )</p></div><p>Eine Prognose in die Zukunft gibt es nicht, dafür lässt sich der Vergleich mit einer ähnlichen Infrastruktur im eigenen Rechenzentrum („On-Premises“) ermitteln. Da hierfür lediglich die Selbsteinschätzung der Effizienz der aktuellen Infrastruktur abgefragt wird, basieren die Ergebnisse nur auf groben Schätzungen.</p><p><b>Fazit</b>: Microsoft hat sich ebenfalls in Bewegung gesetzt und mit dem <i>Emissions Impact Dashboard</i> ein Analyse-Tool zur Verfügung gestellt. Leider kann nicht jedes Team darauf zurückgreifen, da die kostenpflichtige Lizenz eine Einstiegshürde darstellt. Um nach der Analyse des Ist-Zustandes mit der Optimierung unserer Architektur starten zu können, sollte Microsoft Hilfestellungen und Best Practices nachliefern. Aktuell fehlen sie noch.</p><h3>Die Tools der Google Cloud Platform im Überblick</h3><p>Google gibt an, bereits heute CO2-neutral zu sein. Bei genauerem Hinsehen erreichen sie das aktuell allerdings nur über Zertifikate und Emissionsausgleich. Im Gegensatz zu AWS und Azure visiert Google erst das Jahr 2030 an, um 100 % erneuerbare Energien zu nutzen (<a href="https://cloud.google.com/sustainability?hl=de" target="_blank">Quelle</a> ).</p><p>Dennoch lässt sich sagen, dass Google im direkten Vergleich am besten abschneidet: Mit dem <a href="https://cloud.google.com/carbon-footprint?hl=de" target="_blank">Carbon Footprint Reporting</a>  bietet Google eine kostenlose Übersicht der verursachten Emissionen an, die Anwender*innen direkt über den Billing-Account nutzen können. Auch hier lassen sich die Daten nach Ressourcen und Regionen filtern und im zeitlichen Verlauf betrachten.</p><div><img loading="lazy" src="https://media.graphassets.com/0v4BsG5tQv2664YfyaNX" alt="GCP – Carbon Footprint Reporting – Verschiedene Diagramme der Emissionen nach Zeiträumen und Projekten" width="1024" height="434" /><p>GCP: Diagramme der Emissionen nach Monaten (links) und Projekten (rechts)</p></div><p>Im Vergleich zur Konkurrenz bietet GCP aber deutlich mehr Details. Das Dashboard ordnet die Emissionen einzelnen Services und Projekten zu. Damit können die Nutzer*innen die größten CO2-Verursacher einfacher erkennen und optimieren.</p><p>Allerdings stellt Google nicht nur bereits verursachte Emissionen dar. Mit dem <a href="https://cloud.withgoogle.com/region-picker/" target="_blank">Region Picker</a>  bietet das Unternehmen ein Werkzeug an, um die passende Region für das Hosting der genutzten Services auszuwählen. Neben dem Preis und der Latenz können Anwender auch den CO2-Fußabdruck einbeziehen. Die Faktoren fließen auch direkt bei der Auswahl einer Region ein: Regionen mit besonders hohem Anteil an erneuerbaren Energien hebt das Tool mit einem grünen Blatt-Icon hervor und sie sind direkt im Kontext der ausgeführten Aktion ersichtlich. Anders als bei AWS und Azure müssen wir die Informationen nicht selbst suchen.</p><div><img src="https://storage.googleapis.com/gweb-cloudblog-publish/images/Cloud_Run_region_selector.max-700x700.jpg" loading="lazy" alt="Google Cloud – Auswahl der Region mit Indikator für geringe Emissionen" width="700" height="469" /><p>GCP: Auswahl der Region mit Indikator für geringe Emissionen</p></div><p><b>Fazit:</b> Obwohl das Dashboard kostenlos ist, bietet Google viele Details. Außerdem gibt es bereits eine Übersicht der <a href="https://cloud.google.com/architecture/reduce-carbon-footprint?hl=de" target="_blank">Best Practices</a> zur Reduktion der Cloud-Emissionen. Google punktet außerdem mit zusätzlichen Informationen im Kontext der Services (Stichwort: Auswahl der Regionen). Dadurch haben wir die Möglichkeit, uns aktiv für eine nachhaltigere Lösung zu entscheiden.</p><h3>Ausblick</h3><p>Es ist auch heute schon möglich, die Emissionen unserer Cloud-Architektur zu ermitteln, egal welchen der drei großen Cloud-Provider wir nutzen. Im Artikel haben wir die aktuell verfügbaren Tools von AWS, Azure und Google Cloud betrachtet. Wir können aber mit Sicherheit davon ausgehen, dass sie in den nächsten Monaten jede Menge Verbesserungen der Tools und Dokumentationen veröffentlichen.</p><p>Microsoft (Dashboard nicht kostenlos) und Amazon (Dashboard mit wenigen Details) müssen hier nachziehen, um den Anschluss an die GCP nicht zu verlieren. Währenddessen kann sich Google darauf fokussieren, weitere Orientierung direkt im User Interface zu bieten und so beim Aufbau einer nachhaltigeren Architektur zu unterstützen.</p><p>Im nächsten Artikel der Reihe Green Cloud werden wir Möglichkeiten betrachten, um die gemessenen Emissionswerte zu reduzieren. Das Ziel ist, neben der Verfügbarkeit, der Performance und <a href="https://blog.codecentric.de/2020/04/cloud-fruehjahrsputz-aws-kosten/">dem Preis</a>  noch einen weiteren Faktor in unsere Cloud-Strategie einfließen zu lassen: die Nachhaltigkeit unserer Software.</p>

Green Cloud: Emissionen unserer Cloud-Architektur messen

Mit den <a href="https://aws.amazon.com/de/blogs/aws/introducing-cloudfront-functions-run-your-code-at-the-edge-with-low-latency-at-any-scale" target="_blank">CloudFront Functions</a> bietet AWS die Möglichkeit, den Funktionsumfang von CloudFront um kleine JavaScript-Funktionen zu erweitern. AWS führt diese Funktionen direkt an den Edge-Locations aus und ermöglicht es dadurch, alle ankommenden Requests auszuwerten oder zu bearbeiten, bevor sie an die Backend-Systeme weitergesendet werden. 

Das folgende Beispiel zeigt eine einfache *CloudFront Function*, die einen ankommenden Request als `event` übergeben bekommt. Diesem Request wird ein Header hinzugefügt, bevor der Request zur weiteren Verarbeitung wieder an CloudFront übergeben wird.    
```javascript
function handler(event) {
    const request = event.request;
    request.headers['custom-header'] = { value: "some value"};
    return request;
}
```
Da die Funktionen für jeden Request ausgeführt werden, ist es besonders wichtig, dass die Ausführung performant und effizient erfolgt. Ein Grund dafür, dass die CloudFront Functions so performant sind, ist der <a href="https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/functions-javascript-runtime-features.html"  target="_blank">reduzierte JavaScript-Funktionsumfang</a>. Es sind hauptsächlich ES5- und ausgewählte ES6- und ES7-Features verfügbar. Damit fallen auch `import`- und `export`-Statements weg, die genutzt werden, um Code als Node-Module in anderen Dateien wiederzuverwenden.

```javascript
// module.js
export function myExportedFunction(event) {...}

// Im Test kann die exportierte Funktion kann nach dem Import genutzt werden
import { myExportedFunction } from './module.js';
```

Für die Anbindung der Funktion an CloudFront ist der fehlende `export` kein Problem, da lediglich der Pfad zur JavaScript-Datei benötigt wird. Wenn wir die Funktion aber mit Unit-Tests absichern wollen, stoßen wir auf Probleme. Amazon bietet zwar die Möglichkeit, CloudFront Functions manuell in der AWS-Konsole zu testen. Dies kann automatisierte Tests allerdings nicht ersetzen.

![cf_fn_testing.png](https://media.graphassets.com/PUvJ7GRhR8WI6FJbwKZu "Screenshot aus AWS Console: CloudFront Functions können über das CloudFront-UI getestet werden.")

Im Folgenden beschreibe ich zwei Möglichkeiten, die es ermöglichen, unsere CloudFront Functions zu testen, auch wenn wir sie nicht als Node-Module exportieren können.

## Lösung 1: Function
Die JavaScript-Funktion `readFileSync` erlaubt es, Dateien einzulesen und im JavaScript-Code zu nutzen. Anschließend lässt sich der eingelesene Code über den `Function`-Konstruktor initialisieren. Wir können jetzt unsere Tests wie gewohnt schreiben.

```javascript
const code = fs.readFileSync('./cloudfront-function.js');
const handler = new Function(`return ${code.toString()}`)();

// Die Funktion im Folgenden getestet werden
const result = handler(event);
```

Der Vorteil dieser Lösung ist, dass sie ausschließlich JavaScript-Features nutzt. Es ist also keine zusätzliche Dependency notwendig. Auf der anderen Seite müssen wir etwas mehr Code schreiben, um die Datei zu lesen und als Funktion zu initialisieren. Eine Alternative zum `Function`-Konstruktor ist die <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval" target="_blank">eval</a>-Funktion, die ebenfalls JavaScript-Code aus einem String parsen kann.

⚠️ **Achtung!** Beide Lösungen sind mit Vorsicht zu genießen. Das Einlesen von Code aus externen Quellen stellt ein Sicherheitsrisiko dar und sollte nur in einem gesicherten Umfeld stattfinden. In unserem Fall werden die Funktionen aber nur in Tests genutzt und öffnen keine Schwachstellen in unserem Produktivcode.

## Lösung 2: rewire
Die Bibliothek <a href="https://github.com/jhnns/rewire" target="_blank">rewire</a> erlaubt es, auf nicht-exportierte Properties und Funktionen zuzugreifen. Diese können entweder mit `__get__` gelesen oder mit `__set__` geschrieben werden. In unserem Fall reicht die Get-Funktion, der wir den Namen der gesuchten Funktion übergeben. Die Bibliothek gibt uns dann Zugriff auf die eigentlich nicht exportierte Funktion.

```javascript
const handler = rewire('./extract-ids-from-path.js').__get__('handler');
```

Im Vergleich zur ersten Lösung können wir hier also mit weniger Code an die zu testende Funktion kommen. Dafür müssen wir aber eine zusätzliche Dependency zu unserem Projekt hinzufügen.

## Fazit
Auch wenn es auf den ersten Blick ungewohnt ist, gibt es verschiedene Ansätze, um unsere CloudFront Functions zu testen. Je nach Präferenz können wir ausschließlich JavaScript nutzen oder eine zusätzliche Dependency hinzufügen, um etwas Code sparen. Egal für welchen Weg wir uns entscheiden: Unser Code sollte automatisiert getestet werden, um nicht auf manuelle Tests über die AWS-Konsole angewiesen zu sein.

AWS CloudFront Functions testen

Die ökologische Nachhaltigkeit eines Systems ist aktuell häufig noch kein Thema. Nachhaltigkeit bedeutet für mich in diesem Kontext die Reduktion der verursachten Emissionen durch gesenkten Ressourcenverbrauch – egal ob die Emissionen beim Cloudprovider im Rechenzentrum oder beim Datentransport zum User entstehen. Je früher diese Anforderung mitgedacht wird, desto einfacher kann sie schon in die Architektur einfließen.

Im Folgenden möchte ich Ideen für nachhaltige Architekturentscheidungen beschreiben und dabei auch einen Blick auf andere, nicht-funktionale Anforderungen werfen. Häufig können wir durch eine kostengünstigere oder performantere Lösung auch den Stromverbrauch unseres Systems senken. Der Fokus soll hierbei auf der Public Cloud liegen. Falls ihr ein bereits bestehendes System optimieren wollt, ist es sinnvoll, <a href="https://www.codecentric.de/wissens-hub/blog/emissionen-cloud-architektur-messen" target="_blank">zunächst den aktuellen Verbrauch zu analysieren</a>.

## Wahl der Cloud-Region
Die erste Entscheidung vor dem Deployment einer Ressource in die Cloud ist der Standort. Heutzutage bieten alle Cloud-Anbieter ihre Services weltweit in unterschiedlichen *Regions* und *(Availability) Zones* an. Relevante Faktoren für die Wahl eines Standorts sind die Kosten und Ausfallsicherheit. Auch die Entfernung und damit die <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a5.html" target="_blank">Latenz</a> zu den Usern spielt eine Rolle.

Möchte man ein möglichst emissionsarmes Deployment der Anwendung, ist der wichtigste Faktor der <a href="https://cloud.google.com/architecture/reduce-carbon-footprint#choose_the_most_suitable_cloud_regions" target="_blank">Strommix vor Ort</a>. Je nach Land und Region unterscheidet sich der Anteil erneuerbarer Energien im Strom stark. Google bietet mit dem <a href="https://cloud.withgoogle.com/region-picker" target="_blank">Region Picker</a> ein Tool an, um die Faktoren Preis, Latenz und Strommix zu gewichten und den optimalen Standort zu ermitteln. Bei den anderen Anbietern können wir mithilfe <a href="https://aws.amazon.com/de/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals" target="_blank">externer Services herausfinden</a>, in welchen Regionen der Anteil erneuerbarer Energien hoch ist.

Der Strommix sollte aber nicht das einzige Argument für eine Region sein. Jedes Datenpaket gelangt über eine Vielzahl von Systemen von unserem Server zum User und zurück. Je weiter die Strecke, desto mehr Zeit wird benötigt. Aber auch der Stromverbrauch steigt durch die Länge der Strecke an. Wenn unsere Anwendung außerhalb des eigenen Systems Datenverkehr verursacht, ist uns auch dieser Stromverbrauch zuzuschreiben. Hier gilt es also, zwischen dem besseren Strommix einer Region und der Entfernung zu unseren Usern abzuwägen.

## Managed Services
Bei den grundlegenden Compute- und Storage-Services haben wir aber häufig die Wahl zwischen mehreren Alternativen. Eine davon sind <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_hardware_a4.html" target="_blank">Managed Services</a>: Wir können Code ohne Server und Container mit *Google Cloud Functions* ausführen und Datenbanken ohne Updates und Migrationen mit *AWS DynamoDB* betreiben. 

Leider geben Anbieter kaum Informationen über Architektur und Auslastung der Managed Services heraus. Wir können uns an dieser Stelle nur darauf verlassen, dass die Serverless-Angebote auf höchste Auslastung optimiert werden. Dadurch sparen sich AWS, Azure und Co. Stromkosten und steigern ihre Marge. Wir können uns von einer höheren Auslastung weniger betriebene Hardware und damit einen geringeren Stromverbrauch erhoffen.

Generell muss der Service aber immer zuerst <a href="https://cloud.google.com/architecture/reduce-carbon-footprint#choose_the_most_suitable_cloud_services" target="_blank">zum zu lösenden Problem passen</a>. Wenn eine Funktion beispielsweise 24/7 benötigt wird, explodieren die Kosten von FaaS-Angeboten, wie *AWS Lambda* im Vergleich zu einer eigenen Serverinstanz schnell. Mit „As-a-Service“-Angeboten können wir aber die Verantwortung für die Auslastung unseres Systems an die Cloudprovider abgeben. 

## Leerlauf reduzieren
Wir alle kennen Test- und Entwicklungssysteme, die 24/7 betrieben werden – auch wenn niemand mit ihnen arbeitet. Ressourcen, die nicht benötigt werden, sollten alleine schon aus Kostengründen heruntergefahren werden. Dies reduziert auch den Stromverbrauch und damit die ausgestoßenen Emissionen. Dadurch können wir einen großen Einfluss nehmen, da viele Server im <a href="https://www.computerweekly.com/feature/A-waste-of-energy-Dealing-with-idle-servers-in-the-datacentre" target="_blank">Leerlauf auf Arbeit warten</a>.

Verarbeitet unser System nicht zeitkritische Workloads, können wir hier ebenfalls ansetzen. Ein typisches Beispiel sind Batchjobs, die in der Nacht aufwendige Berechnungslogiken durchführen. Wir können diese Workloads zeitlich verlagern und so Kosten sparen, da die Cloudprovider ihre Server günstiger anbieten, wenn die Auslastung gering ist. Ein Beispiel sind die *<a href="https://aws.amazon.com/de/ec2/spot/instance-advisor" target="_blank">EC2-Spot-Instanzen</a>* von AWS. Gleichzeitig erhöhen wir auch die Chancen für einen emissionsärmeren Strommix, wenn wir unsere Arbeit abseits von Industrie und Haushalten ausführen. Um den Strombedarf von Lastspitzen zu decken, muss häufig Strom aus nicht erneuerbaren Quellen hinzugenommen werden. Die Chance dafür können wir mit diesem Vorgehen verringern.

Mit Services wie der <a href="https://www.electricitymaps.com" target="_blank">Electricity Map</a> können wir noch dynamischer auf den aktuellen Strommix einer Region reagieren. Damit lassen sich Ort und Zeit für eine möglichst ressourcensparende Ausführung von Workloads ermitteln, die nicht zeitkritisch sind. Diese Lösung ist erstmal sehr komplex in der Umsetzung – erlaubt es dann aber, auf aktuelle Bedingungen zu reagieren und den nachhaltigsten Strommix zu nutzen.

Auch die asynchrone Verarbeitung mithilfe einer <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_software_a2.html" target="_blank">Queue</a> ist eine Möglichkeit, den eigenen Stromverbrauch zu optimieren. Anstatt bei hoher Last zusätzliche Instanzen hochzufahren, kann eine Queue die Anfragen abpuffern. Dadurch umgehen wir eine Überprovisionierung, um unerwartete Lastspitzen auf dem Server verarbeiten zu können. 

## Komponenten skalieren
Individuelle Skalierung kann aber auch einen Schritt früher anfangen. Wieso sollten wir das gesamte System dauerhaft laufen lassen, wenn eigentlich nur ein kleiner Teil ständig genutzt wird?

<a href="https://cloud.google.com/architecture/reduce-carbon-footprint#minimize_idle_cloud_resources" target="_blank">Google empfiehlt</a>, Microservices zu implementieren, falls Teile des Systems unterschiedlich stark genutzt werden. Beispielsweise wird ein *login-service* nur initial gebraucht, um eine Session zu starten. Im Anschluss benötigen die User den *search-service* aber häufig, um Produkte zu finden und den *basket-service*, um diese in den Einkaufswagen zu legen. Aber egal ob Microservices, Monolith oder etwas dazwischen – wir müssen die Nutzungsprofile unserer Systemkomponenten kennen. Nur dann können wir die beste Kombination von “as a service”-Angeboten und dedizierten Servern wählen, um das Problem zu lösen.

Spezialisierte Services helfen uns aber nicht nur dabei, die Performance zu verbessern, indem einzelne Komponenten schneller und stärker skaliert werden können. Auch für den Stromverbrauch hat dieser Ansatz Vorteile: Wir können Instanzen der Services – und damit auch den Stromverbrauch – herunterfahren. Die Kosten reduzieren wir damit gleich mit.

## Fazit
Wir können bereits beim Entwurf einer Architektur darauf achten, ein nachhaltigeres Fundament aufzustellen. Dabei muss es nicht unbedingt auf ein „entweder – oder“ hinauslaufen. Häufig gewinnen wir im Falle einer nachhaltigen Entscheidung auch auf der Kosten- und Performance-Ebene.

Aktuell gibt es noch große Unterschiede beim Strommix in unterschiedlichen Regionen. Über „As-a-Service“-Angebote kann die Verantwortung für eine optimale Auslastung der Ressourcen an die Provider abgegeben werden. Wenn Optimierungen wie diese zu den anderen Anforderungen an ein System passen, lassen sich Emissionseinsparungen auf einfache Weise umsetzen.

Nicht jedes Projekt wird von Anfang an möglichst sparsam entworfen. Aber auch im Nachhinein lassen sich Optimierungen umsetzen. Die Grundlage hierfür ist ein gutes <a href="https://www.codecentric.de/wissens-hub/blog/cloud-fruehjahrsputz-aws-kosten" target="_blank">Monitoring der Kosten</a> und der Performance eines Systems. Dadurch bekommen wir Hinweise für weiteres Optimierungspotential. Diese Potentiale betrachten wir im nächsten Teil der „Green Cloud“-Serie, wenn wir uns die Skalierung des Systems genauer anschauen.


Green Cloud: Ideen für eine nachhaltigere Architektur

Wenn Softwareprojekte in die Cloud gebracht werden, versprechen wir uns davon hohe Verfügbarkeit, planbare Kosten und eine immer dem Bedarf entsprechende Skalierung. Aufgrund der grenzenlosen Angebote ist es aber auch leicht, die Komponenten eines Systems zu überprovisionieren und damit mehr Ressourcen zu verbrauchen, als notwendig wären.

Nachdem ich im letzten Blogpost Ideen für eine <a href="https://www.codecentric.de/wissens-hub/blog/nachhaltigere-cloud-architektur" target="_blank">ressourcensparende Cloud-Architektur</a> besprochen habe, soll es dieses Mal darum gehen, wie wir die Emissionen unserer Anwendung mithilfe einer optimierten Skalierung reduzieren können. Skalierung bezieht sich hierbei auf die Bereitstellung von (Hardware-)Ressourcen und die Entscheidung, wie viele Server mit welcher Hardware-Ausstattung benötigt werden. Wie beim letzten Post liegt der Fokus ebenfalls auf der Public Cloud.

## Kapazitäten reduzieren
Die Last, die ein System verarbeiten können muss, ist häufig zeitlich sehr unterschiedlich verteilt. Selbstverständlich muss ein Onlineshop 24/7 verfügbar sein, damit Kunden jederzeit einkaufen können. Wenn meine Kundschaft aber nicht weltweit verteilt ist, wird die Last auf das System in der Nacht stark sinken. Auch  <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_software_a3.html" target="_blank">AWS empfiehlt</a>, kritisch zu hinterfragen, welche Systeme herunterskaliert werden können.

Ähnliches gilt auch für die Softwareentwicklung selbst: Üblicherweise arbeiten die Teams tagsüber in einem relativ festen Zeitraum. Spätestens nachts benötigt niemand mehr <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_dev_a4.html" target="_blank">den Test-Server oder die Build-Pipeline</a>. Ein netter Nebeneffekt davon: Wenn mein Server nicht mehr läuft, kostet er auch nichts. Hier gewinnen wir also auch auf der Kostenebene, während wir einen großen Einfluss auf unseren Stromverbrauch nehmen.

## Skalierung der Datenspeicher
Rechtliche Bestimmungen spielen je nach Branche eine große Rolle bei der Frage, welche Daten ein Unternehmen für welche Zeiträume speichern muss. Häufig ist die einfache Antwort dabei: „Cloudspeicher ist so günstig, lasst uns einfach alles für immer speichern“. Wenn wir aber sehr viele Daten speichern und diese nur selten aufräumen, summieren sich die Kosten schnell.

Über die Kosten lässt sich gut für eine stromsparende Reduktion der genutzten Speichersysteme argumentieren. Denn auch wenn wir keine Größe für den Cloudspeicher angeben, skalieren wir diesen indirekt durch unsere tatsächliche Nutzung. Durch <a href="https://www.digitalcleanupday.org" target="_blank">regelmäßiges Löschen</a> unserer Daten sorgen wir dafür, dass die Cloudanbieter weniger Speichermedien vorhalten müssen und reduzieren ihren Strombedarf. Es ist also aus verschiedener Sicht sehr sinnvoll, die gespeicherten Daten regelmäßig zu überprüfen und nicht mehr verwendete Daten zu löschen.

Automatisiertes Löschen der gespeicherten Daten kann dabei helfen, den Arbeitsaufwand zu reduzieren. Ein Weg sind hier Retention Policies, mit denen wir festlegen können, ab wann unsere Daten vom System entfernt werden sollen. Falls die Daten nicht gelöscht werden können, aber die Zugriffe ab einem bestimmten Zeitpunkt absehbar abnehmen, erlauben Lifecycle Policies das automatische Verschieben der Daten in andere Speichersysteme. <a href="https://aws.amazon.com/de/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage" target="_blank">Magnetspeicher</a> sind dann eine gute Lösung, da sie energiesparender sind. Für Einträge in einer Datenbank lassen sich sogenannte <a href="https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/howitworks-ttl.html" target="_blank">„Time to Live“-Werte</a> konfigurieren. Ist die Lebensdauer der Datensätze überschritten, räumt die Datenbank automatisch auf.

## Hardware skalieren
Manche Anforderungen verlangen nach einem dedizierten Server. Weil die Auswahl der Cloud-Provider heutzutage sehr groß ist, ist es leicht, die stärkste Hardware zu provisionieren und mögliche Skalierungsprobleme frühzeitig mit Geld lösen zu wollen. „Sicher ist sicher“ gewinnt gegenüber der <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_hardware_a3.html" target="_blank">sparsamen Variante</a> bei der Wahl der Hardware. 

Mithilfe von detailliertem Monitoring eines Systems kann ich nicht nur Probleme und Fehler frühzeitig erkennen. Es lässt sich auch genauer beurteilen, wie hoch die Auslastung meiner Hardware ist. Das ermöglicht es, erst bei dauerhaftem Bedarf <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_hardware_a2.html" target="_blank">vertikal auf eine bessere Hardware zu skalieren</a>.

Außerdem ist es ratsam, regelmäßig nach neuen Servermodellen Ausschau zu halten. Diese sind häufig nicht nur günstiger, sondern auch performanter. Zusätzlich haben beispielsweise die <a href="https://aws.amazon.com/de/ec2/graviton/#Benefits" target="_blank">Graviton-Instanzen</a> von AWS einen deutlich niedrigeren Energieverbrauch bei gleicher Leistung. Ein Wechsel des Instanztyps spart letztlich nicht nur Geld, sondern auch Strom.

## Dynamische Skalierung 
Die horizontale Skalierung auf mehrere Server ist die zweite Möglichkeit, auf dynamischen Workload zu reagieren. Wenn sich die Last auf ein System zeitlich sehr unterschiedlich verteilt, ist es besser, in die Breite zu skalieren. Statt den dauerhaft höheren Energieverbrauch der besseren Hardware auf sich zu nehmen, lassen sich kurzfristige Lastspitzen auch über eine dynamische Skalierung auf mehreren Instanzen abfangen.

Generell ist es empfehlenswert, möglichst kleine Skalierungsschritte zu konfigurieren. Damit beugen wir einer Überprovisionierung vor. Auch hier gilt: Zunächst sollte das System beobachtet und dann bedarfsabhängig optimiert werden, anstatt Probleme mit besserer Hardware zu erschlagen. Ein weiterer Vorteil von diesem Vorgehen: Selbst bei stark überprovisionierter Hardware besteht das Risiko, dass die Last alle Erwartungen übersteigt und das System überfordert ist. Wenn ein System dynamisch reagieren kann, lassen sich auch unerwartete Zugriffszahlen besser verarbeiten.

Die Skalierungsregeln sollten über die <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_hardware_a2.html" target="_blank">Utilization</a> implementiert werden, um so eine optimale Auslastung der Systeme umzusetzen. Erst wenn eine Ressource eine gewisse Auslastung erreicht hat, stoßen wir die Skalierung an. Im selben Moment muss auch daran gedacht werden, die Ressourcen <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a2.html" target="_blank">wieder herunter zu skalieren</a>, wenn sie nicht mehr benötigt werden.

## Spezialfall „Function as a Service“
„Function as a Service“-Angebote (FaaS) wie Azure Functions erlauben es, Code ohne Infrastruktur-Overhead in der Cloud auszuführen. Die Anbieter sorgen dafür, dass genügend Ressourcen zur Verfügung stehen, um Anfragen verarbeiten zu können. Interessant wird es, wenn eine Funktion nicht benötigt wird. Weil nach Laufzeit bezahlt wird, gibt es einen Scale-to-Zero und wir bezahlen nichts mehr. 

Leider geben die Cloud-Provider kaum Informationen über die genaue Architektur und Auslastung ihrer FaaS-Angebote heraus. Eine gewisse Grundkapazität muss jedoch immer vorgehalten werden, auch wenn unsere eigene Funktion aktuell nicht genutzt wird. Da diese Serverkapazität den Usern aber nicht abgerechnet wird, ist davon auszugehen, dass die Anbieter die Auslastung so weit wie möglich optimieren. Für uns bieten FaaS-Angebote damit eine gute Möglichkeit, die Skalierung unseres Systems vollständig abzugeben.

## Fazit
Generell gilt: Solange die aktuelle Last problemlos verarbeitet werden kann, können wir die kleinste Hardware-Konfiguration eines Systems laufen lassen. Für die unerwarteten Momente bietet sich eine dynamische Skalierung an. Grundvoraussetzung ist aber ein gutes Monitoring und detaillierte Kenntnis des Systems. Nur auf diese Weise können wir die Skalierung korrekt konfigurieren.

Häufig gewinnen wir mit der dynamischen Skalierung nicht nur beim Stromverbrauch. Auch die Kosten unseres Systems lassen sich auf diese Weise reduzieren. Es mag häufig nach der leichteren Lösung aussehen, statische Ressourcen zu nutzen. Aber langfristig rechnet sich ein dynamisch skalierendes System nicht nur finanziell, sondern auch bei den verursachten Emissionen unseres Systems.

Green Cloud: Nachhaltig skalieren 

Das Aufsetzen der CI/CD-Pipeline ist ein typischer Task in der Anfangszeit eines Projekts. Ist die Pipeline dann aufgesetzt, sind Änderungen nur noch selten notwendig. Dementsprechend wenig Routine entwickeln Programmierende im Umgang mit der Konfiguration einer Pipeline. Wenn dann noch besondere Anforderungen, wie Cross-Account-Deployments, ins Spiel kommen, wird die Konfiguration der Pipeline kompliziert.

Das AWS CDK bietet mit dem <a href="https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_codepipeline-readme.html" target="_blank">CodePipeline</a>-Konstrukt eine einfache Möglichkeit, die CI/CD-Pipeline für ein CDK-basiertes Projekt aufzusetzen. Bevor wir ein paar Beispiele betrachten, werfen wir einen Blick auf die Konzepte der CodePipeline.

## Die Struktur
![aws_codepipeline.jpg](https://media.graphassets.com/wckIVcQ7StSVaShojqqC)

Das CodePipeline-Konstrukt kapselt die drei AWS-Services CodePipeline, CodeBuild und CodeDeploy, aus denen eine Pipeline im AWS-Umfeld üblicherweise aufgebaut wird. Wie die Namen beschreiben, fokussieren sich die Services jeweils auf das Orchestrieren der Pipeline, das Bauen der Anwendung und das eigentliche Deployment.

Der Kern einer CodePipeline ist der `synth`-Schritt. Hier wird definiert, wie die Pipeline das CloudFormation-Template generieren soll, das im Anschluss für das Deployment genutzt wird. Alle Artefakte werden vollautomatisch in einem S3-Bucket abgelegt, der ebenfalls vom Konstrukt angelegt wird. Im Anschluss nutzt CodeDeploy das Template aus dem Bucket und startet das Deployment über CloudFormation. Mit <a href="https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html#cdk_pipeline_stages" target="_blank">Stages</a> werden die Accounts und Regionen der Deployments konfiguriert. 

## Die Basics
```javascript
const pipeline = new CodePipeline(this, 'my-pipeline', {
    pipelineName: 'my-pipeline',
    selfMutation: true,
    synth: new ShellStep('synth', {
        input: CodePipelineSource.codeCommit(repository, 'main'),
        commands: ['npm ci', 'npm run build', 'npx cdk synth'],
    })
});
```
Der Beispielcode zeigt die Pipeline für ein NPM-basiertes Projekt. Das CloudFormation-Template wird synthetisiert, indem zunächst die Dependencies installiert und anschließend der Code gebaut wird (Zeile 6). Das Artefakt wird anschließend automatisch in einem S3-Bucket archiviert.

Eine weitere Besonderheit der CodePipeline ist, dass ihr Code im selben Repository liegt wie der Anwendungscode. Über das Property `selfMutation` (Zeile 3) konfigurieren wir, dass sich Codeänderungen an der Pipeline selbst aktualisieren können. Hierzu ist es notwendig, die Pipeline in einen eigenen CDK-Stack auszulagern und diesen zunächst manuell zu deployen. Anschließend aktualisiert sich die Pipeline bei jeder Codeänderung selbst.

Nachdem unser CloudFormation-Template synthetisiert wurde, muss das eigentliche Deployment gestartet werden. Hier kommen die bereits erwähnten Stages ins Spiel. Das folgende Beispiel zeigt das Hinzufügen einer Deployment-Stage mit dem Namen “MyPipelineStage” zur Pipeline. Diese wird automatisch am Ende der Pipeline ausgeführt. Eine Stage wird dafür genutzt, die notwendigen Stacks einer Anwendung zu initialisieren und damit das Deployment anzustoßen. Im Beispiel ist dies "MyStack", der in den AWS-Account "111111111111" und die Region "eu-central-1" deployt werden soll.
```javascript
pipeline.addStage(new MyPipelineStage(this, 'dev'));

[...]

class MyPipelineStage extends Stage {
    constructor(scope: Construct, id: string, props?: StageProps) {
        super(scope, id, props);
        new MyStack(this, 'my-stack', {
            env: { account: '111111111111', region: 'eu-central-1' },
        });
    }
}
```

## Die Erweiterung
Der Anwendungscode wird von AWS CodeBuild gebaut. Dieser Service bietet unterschiedliche Umgebungen, in denen dieser Prozess ablaufen kann. Je nach Stack des Projekts muss eine dazu passende Umgebung ausgewählt werden. Das folgende Beispiel zeigt die Konfiguration für ein Build-Environment, in dem Node.js in Version 18 verfügbar ist. Weitere Möglichkeiten zeigt AWS in <a href="https://docs.aws.amazon.com/codebuild/latest/userguide/available-runtimes.html" target="_blank">dieser Übersicht</a>.
```javascript
synthCodeBuildDefaults: {
    buildEnvironment: { buildImage: LinuxBuildImage.STANDARD_7_0 },
    partialBuildSpec: BuildSpec.fromObject({
        phases: {
            install: {
                'runtime-versions': { nodejs: '18' },
            },
        },
    }),
 }
```
Falls das Projekt Lambda-Funktionen enthält, die mit dem NodejsFunction-Konstrukt umgesetzt werden, übernimmt das CDK das Kompilieren des Codes. In unserer Pipeline reicht es, das `dockerEnabledForSynth`-Property zu setzen. Dadurch kann die CodePipeline den Typescript-Code zu JavaScript transpilieren.

In manchen Fällen möchten wir einen Schritt manuell bestätigen und die Automatisierung der Pipeline umgehen. Beispielsweise soll das Deployment auf die Produktionsumgebung erst nach einem Test der Änderungen auf der Entwicklungsumgebung stattfinden. Mithilfe eines <a href="https://aws.amazon.com/de/blogs/devops/manually-approving-security-changes-in-cdk-pipeline" target="_blank">ManualApprovalSteps</a> können wir die Pipeline auf die Bestätigung eines Users warten lassen, bevor es mit der nächsten Stage weitergeht. 
```javascript
const devDeploymentStage = pipeline.addStage(new DevPipelineStage(this, 'dev'));
devDeploymentStage.addPost(new ManualApprovalStep('approval'));
const prodDeploymentStage = pipeline.addStage(new ProdPipelineStage(this, 'prod'));
```

## Das Cross-Account-Deployment
Gerade wenn diverse Abteilungen und Teams im AWS-Umfeld unterwegs sind, hat sich ein Deployment über Account-Grenzen etabliert. Beispielsweise werden die Entwicklungs- und Produktionsumgebungen in unterschiedlichen AWS-Accounts umgesetzt. Die Pipeline kann jedoch zentral in einem eigenen Account laufen. Auch das Deployment in mehrere Regionen lässt sich leicht durch weitere Stages umsetzen.

Hierzu muss in der Pipeline zunächst das Property `crossAccountKeys` gesetzt werden, um die KMS-Keys zu generieren. Diese Schlüssel werden genutzt, um die Pipeline-Artefakte zu verschlüsseln. Dem anderen Account muss erlaubt werden, den Schlüssel zu nutzen, um die Artefakte wieder zu entschlüsseln. Alle Ressourcen und Berechtigungen übernimmt das CDK-Konstrukt für uns.
```javascript
new CodePipeline(this, 'my-pipeline', {
    crossAccountKeys: true,
    [...]
})

pipeline.addStage(new PipelineStage(this, 'dev'), {
    env: { account: '111111111111', region: 'eu-central-1' },
});
pipeline.addStage(new PipelineStage(this, 'prod'), {
    env: { account: '222222222222, region: 'us-east-1' },
});
```

## Das Fazit
Mit dem CodePipeline-Konstrukt erlaubt es das CDK unkompliziert die Pipeline für unser Projekt aufzusetzen. Besonders bei komplexeren Use Cases ist weniger Verständnis der AWS-Plattform notwendig, um Ergebnisse zu erzielen. Ein Beispiel sind hier die notwendigen Rollen und Policies, um Cross-Account-Deployments umzusetzen.

Durch die einfache API des Konstrukts können wir schnell Erfolge erzielen und uns auf die Implementierung von fachlichen Anforderungen konzentrieren. Setzen wir ein neues Projekt um, können wir die Konfiguration der CI/CD-Pipeline zukünftig dem CDK überlassen.


CI/CD-Pipelines mit AWS CDK CodePipeline

Das Internet produziert jährlich 900 Millionen Tonnen CO₂ – das ist deutlich mehr als Deutschland insgesamt emittiert. Hauptverantwortlich ist der immer weiter steigende Stromverbrauch beim Transport und der Speicherung von Daten. Wenn ihr kurz darüber nachdenkt, fallen euch sicher Dateien ein, die noch irgendwo gespeichert sind, weil ihr sie irgendwann nochmal gebrauchen könntet. Genau darum soll es in diesem Artikel gehen: Wie können wir Daten und damit Emissionen einsparen?

Dieser Blogpost betrachtet speziell die Möglichkeiten der Public Cloud, deren Anbieter auch ganz <a href="https://speakerdeck.com/ufried/patterns-of-sustainability-going-green-in-it?slide=121"  target="_blank">eigennützige Motivationen</a> haben, ihre Emissionen zu verringern. Natürlich ist das Marketing aktuell ein wichtiger Beweggrund. Aber auch die finanziellen Gründe für eine Optimierung des Ressourcenverbrauchs sind klar: Ein geringerer Stromverbrauch senkt die Kosten für die Anbieter und steigert ihre Marge. Aus ökologischer Sicht ist Hardware, die nicht gekauft werden muss, Hardware, die nicht produziert wird und damit Ressourcen spart. Wir als Entwickler und Entwicklerinnen können durch unsere Nutzung also positiven Einfluss auf die Cloud-Anbieter nehmen – Stichwort <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/the-shared-responsibility-model.html" target="_blank">AWS Shared Responsibility</a>.

## Daten löschen
Nicht mehr benötigte <a href="https://patterns.greensoftware.foundation/catalog/cloud/delete-unused-storage-resources" target="_blank">Daten zu löschen</a> ist der einfachste Weg, den belegten Speicherplatz zu reduzieren. Bei der Frage, welche Daten nicht mehr benötigt werden, wird es aber spannend. Häufig wird zur Sicherheit erstmal alles gespeichert: *„Später können wir ja immer noch löschen“*. Hinzu kommt, dass Cloud-Speicher günstig sind. Erst mit steigender Nutzung und größeren Datenmengen fällt auf, dass die Kosten in die Höhe schießen.

Regelmäßiges Aufräumen muss aber keinen großen Zeitaufwand bedeuten. Mit <a href="https://patterns.greensoftware.foundation/catalog/cloud/set-retention-policy-on-storage-resources" target="_blank">Retention Policies</a> lassen sich Ressourcen automatisch aufräumen. Bei der Nutzung von DynamoDB-Tabellen können Time-To-Live-Werte konfiguriert werden, nach denen Einträge automatisch aus den Tabellen gelöscht werden. Unsere S3-Buckets können wir mithilfe von <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html" target="_blank">Expiration-Rules</a> aufräumen lassen oder wir verschieben die Daten in energiesparenden Cold Storage. Ähnliche Konzepte finden sich in vielen Cloud-Services.

Regelmäßiges Aufräumen schont nicht nur den Geldbeutel, sondern spart auch Ressourcen. Der freigewordene Speicher kann anderen Nutzern zur Verfügung gestellt werden und verzögert damit, dass die Cloud-Provider neue Hardware bereitstellen müssen.

## Datensparsamkeit
Nicht nur mit Blick auf die Kosten und den Stromverbrauch sollten wir uns genau überlegen, welche Daten wir wirklich benötigen. Stichwort Datenschutz und <a href="https://patterns.greensoftware.foundation/catalog/cloud/reduce-transmitted-data" target="_blank">Datensparsamkeit</a>: Nicht alle Daten müssen gespeichert werden. Denn die Daten verbrauchen nicht nur Speicherplatz, sondern vergrößern auch die Requests, die wir über das Netzwerk verschicken. Es ist sehr sinnvoll, sich vor der Integration eines Tracking-Tools im Detail zu klären, welche Events und Daten wirklich notwendig sind.

Wenn ein System geringere Datenmengen verarbeiten muss, verbessert dies viele Aspekte. Angefangen bei der Performance, da Berechnungen schneller abgeschlossen werden. Auch die Hardwareanforderungen werden reduziert und damit schließt sich der Kreis: Wir reduzieren mit dem geringeren Leistungsbedarf auch unsere Rechnung und die Anbieter müssen weniger Hardware bereitstellen, um alle Kunden versorgen zu können.

## Daten cachen
Wenn Daten über das Netzwerk versendet werden müssen, bevor eine Anwendung ihre Funktionen bereitstellen kann, verlängert das die Zeit, bis die User mit ihrer Arbeit beginnen können. Je größer die Strecke zwischen Server und Endgerät ist, desto stärker fällt dieser Punkt ins Gewicht. Darunter leidet aber nicht nur die User-Experience. Auch der Stromverbrauch wird durch den steigenden Netzwerktraffic vergrößert, da viele Geräte an der Übertragung von Daten beteiligt sind.

Eine Verbesserung kann mithilfe von <a href="https://patterns.greensoftware.foundation/catalog/cloud/cache-static-data" target="_blank">Caching</a> erreicht werden. Beispielsweise indem wir Daten direkt auf den Endgeräten speichern, nachdem sie einmal verschickt wurden. Dadurch ersparen wir zukünftig weitere Datenübertragungen. Mithilfe eines Content Delivery Networks (CDN) können wir die Ergebnisse häufiger Anfragen im Cache halten, statt diese jedes Mal durch das gesamte Netzwerk und über viele Systeme zu verschicken.

Nochmals stärker wirkt sich ein Cache auf die Antwortzeit aus, wenn es sich nicht um statische Daten handelt, sondern zunächst Berechnungslogik ausgeführt werden muss. Wenn unsere Anwendung viele User mit ähnlichen Anfragen bedient, haben wir an der Stelle einen großen Hebel. Selbstverständlich muss ein Cache für den jeweiligen Use Case kompatibel sein. Statische Dateien, wie Bilder oder das Impressum, lassen sich gut vorhalten und effizient aus einem Cache ausliefern.

## Daten komprimieren
Bevor Daten über das Netzwerk verschickt werden, sollten sie so weit wie möglich komprimiert werden. Wie bei der Datensparsamkeit gilt auch hier: Wenn weniger Daten verschickt werden, spart das Zeit und Energie.

Ein wichtiger Entscheidungsfaktor sind die Endgeräte, auf denen unsere Anwendung genutzt wird. Während Desktop-Anwendungen nicht nur aufgrund der Bildschirmgröße mit größeren Bildern bespielt werden sollten, gilt es besonders bei mobilen Anwendungen <a href="https://patterns.greensoftware.foundation/catalog/web/properly-sized-images" target="_blank">Medien zu skalieren</a>. Wir reduzieren dadurch nicht nur die Transportzeit, sondern verringern auch die Anforderungen an Hardware zur Verarbeitung der Datenmengen. Gerade bei älteren Smartphones lassen sich dadurch ein paar Millisekunden Zeit einsparen, was für die User-Experience ein großer Gewinn sein kann.

Mit der Schonung der Endgeräte erreichen wir nicht nur eine bessere Usability, sondern können auch indirekt Einfluss nehmen: Ruckeln die täglich genutzten Anwendungen auf dem Smartphone, spielt man schnell mit dem Gedanken an ein <a href="https://www.sciencedirect.com/science/article/pii/S0959652621017790#bib53" target="_blank">neues Gerät</a>. Durch unsere Optimierungen können wir den Kauf noch ein wenig hinauszögern und die Produktion weiterer Hardware reduzieren.

## Datenverbrauch messen
Idealerweise arbeiten wir nicht nur einmalig am Datenverbrauch, sondern messen zukünftige Veränderungen, um entsprechend reagieren zu können. Beispielsweise könnte eine <a href="https://aws.amazon.com/de/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage" target="_blank">Zugriffsanalyse</a> ergeben, dass bestimmte Daten nur unregelmäßig und ohne Zeitdruck angefragt werden. Dann kann ein Wechsel von schnellen SSDs auf langsamere – aber auch energiesparende – magnetische Speichermedien sinnvoll sein. Preislich lohnt sich so ein Wechsel häufig ebenfalls.

Die Cloud-Provider bieten verschiedene Metriken zu ihren Speicherservices an. Gerade wenn wir eigene Volumes konfigurieren, sollten wir durch Alarme auf die entsprechenden Metriken sicherstellen, dass wir die Deployments weiterhin benötigen. Für den EBS-Service von AWS gibt die <a href="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html#ebs-metrics" target="_blank">*VolumeIdleTime*</a> an, wie lange keine Lese- und Schreibaktionen mehr ausgeführt wurden. Wenn die Idle-Time einen gewissen Wert überschreitet, sollte zumindest darüber nachgedacht werden, die Ressourcen für andere Kunden freizugeben.

## Fazit
Mit ein paar Verbesserungen können wir nicht nur Einsparungen bei den Emissionen unserer Systeme erreichen, sondern auch die Kosten reduzieren und die Performance verbessern. Das zeigt sich auch in anderen Bereichen der <a href="https://www.codecentric.de/wissens-hub/blog/green-cloud-nachhaltig-skalieren" target="_blank">Green-Cloud-Optimierungen</a>. Beim vorsichtigen Umgang mit Daten können wir allerdings auch den Datenschutz verbessern.

Am 16. März ist der <a href="https://www.digitalcleanupday.org" target="_blank">Digital Cleanup Day</a>. Nehmt den Tag zum Anlass und stellt euren Teams einen Termin ein. Analysiert eure Daten im Projekt genauer – ihr werdet Optimierungspotenziale erkennen. Mit den Ideen aus diesem Blogpost habt ihr dann passende Lösungen zur Hand, um den datenbasierten Stromverbrauch zu reduzieren. Viel Erfolg dabei!

Green Cloud: Daten und Emissionen sparen

IT Consultant

Lass uns austauschen!

Möchtest du dich über dieses Thema austauschen?

Auf unserem Blog findest du viele Artikel zu Tech-Themen von unseren Mitarbeitenden. Vielleicht ist auch hier ein Thema für dich dabei. Schau gerne mal rein!

Hier gibt's noch mehr spannende Infos von uns für euch

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

In sechs Schritten zu einer nachhaltigen Cloud-Architektur

Aus dem Inhalt:

Lass uns austauschen!

Hier gibt's noch mehr spannende Infos von uns für euch

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten