Während sich die anderen Pillars der Architektur-Frameworks damit beschäftigen, wie wir die Cloud einsetzen können, um unser Produkt besser zu machen, beschäftigt sich die "Cost Optimization"-Pillar mit Kosteneinsparungen. Sie steht damit in Konflikt mit anderen Pillars. Manche der Best Practices drehen sich aber um organisatorische und technische Maßnahmen zur Kosten-Kontrolle und sind somit auch unabhängig der anderen Pillars einsetzbar.
Die beiden Pillars “Cost Optimization” und Sustainability sind sehr ähnlich. Wenn wir ressourcenschonend arbeiten, dann verringern sich sowohl die Kosten unserer Systeme als auch deren negativen Auswirkungen auf die Umwelt. In diesem Blogpost fliegen wir einmal über die Pillars und greifen stichpunktartig spannende Elemente raus. Falls Sie weiter in die Tiefe gehen möchten, finden Sie an den entsprechenden Stellen Referenzen. Die Namenskürzel der Verweise haben eine Bedeutung: Kürzel, die mit A beginnen, beziehen sich auf AWS, M auf Microsoft Azure und G auf Google Cloud.
Abbildung 1: Verdichtete Designprinzipien aus den drei Architektur-Frameworks
- Optimiere die Auslastung von Ressourcen. Streben Sie für Ressourcen wie virtuelle Maschinen oder Datenbankserver eine möglichst hohe Auslastung an. Wenn Sie 50 ständig laufende Knoten in Ihrem Cluster haben, diese aber nur einen Bruchteil der Zeit ausgelastet sind, dann sollten Sie eher auf automatisierte Skalierung setzen. So hat Ihr Cluster weniger Knoten, aber eine bessere Auslastung – und fügt neue Knoten bei Bedarf hinzu.
- Messe Kosten und setze sie in Relation zu anderen Metriken. Bestimmte Teile Ihres Systems werden mehr Kosten erzeugen als andere. Messen Sie die Kosten Ihres Systems und Ihrer Teilsysteme (das können vertikale Teilsysteme sein wie eine bestimmte Subdomäne oder horizontale Teilsysteme wie die Summe aller Datenbanken). Korrelieren Sie diese Werte gegen andere Metriken. Messen Sie, ob das teure (Teil-)System die versprochenen Mehrwerte in anderen Qualitäten wie Performance, Reliability oder Security bringt und somit ihre hohen Kosten rechtfertigt.
- Nutze Services der Cloud-Anbieter. High-Level Services, die Ihr Cloud-Anbieter managed, helfen nicht nur bei Performance-Aspekten, sondern auch bei der Kostenoptimierung. Je mehr technische Ressourcen Sie verwalten müssen, desto mehr technisches Know-How müssen Sie in die Kostenoptimierung investieren. “Managed Services” müssen Sie im Gegenzug einfach nur benutzen – anstatt eigene Rechenzentren, Infrastruktur oder Cluster selbst aufzubauen und zu administrieren, können Sie sich auf die Expertise des Cloud-Anbieters verlassen und sich auf Ihre Geschäftsprojekte konzentrieren.
- Setze Limits für Kosten. Wenn Sie Ihre Kosten messen, dann sollten Sie auch Limits setzen. Stellen Sie sicher, dass die richtigen Personen Bescheid bekommen, wenn Kostenlimits überschritten werden. Sie können Kosten auch unterteilen und detailliertere Limits setzen – beispielsweise für Teams oder bestimmte Arten von Ressourcen.
Das AWS Well-Architected Framework empfiehlt die Einrichtung eines Teams zur Verwaltung von organisationsweiten Cloud-Kosten [ACF]. Dieses Team kann zentral oder dezentral agieren. Ein Blick in das Google Architecture Framewok empfiehlt in diesem Zusammenhang einen FinOps-Ansatz [GFO].
Statt zentraler Kostenverwaltung und -kontrolle fördert FinOps eine Kultur, in der Teams mehr Freiheiten genießen und die Verantwortung ihrer Cloud-Kosten tragen. Ein zentrales FinOps-Team übernimmt dann die Funktion von Kosten-Beratung und Etablierung von Best Practices.
Das Google Architecture Framework führt Prinzipien auf, die dieses zentrale Team etablieren soll [GFO]. Auf der Website der FinOps-Foundation finden sich ebenfalls Prinzipien [FOP]. Im Folgenden fasse ich diese Ideen kurz zusammen:
- Teams übernehmen die Verantwortung ihrer Cloud-Kosten. Das führt einerseits zu Freiheiten in den Teams und erhöht Agilität, sowie die Möglichkeit zu experimentieren. Andererseits stehen Kostenänderungen auch in der Verantwortung der Teams. Genauso wie gute Produktteams die Verantwortung über die funktionalen Anforderungen und die Qualität ihrer Lösung übernehmen, übernehmen sie auch Verantwortung über die Kosten, die sie in der Cloud verursachen. Als zentrales Team können Sie diese Kosten in der Organisation transparent machen und kosteneffiziente Teams als gutes Beispiel hervorheben.
- Teams kollaborieren und tauschen Erfahrungen aus. Ein FinOps-Team kann hier unterstützen und kosteneffiziente Patterns aus den Teams sammeln und zentral publizieren. Eine offene Kollaborationskultur ermöglicht es auch, dass Teams Ihre Lösungen gegenseitig auf Kostenoptimierungen peer-reviewen.
- Teams machen ihre Kostenreports zeitnah und transparent. Dadurch werden die Auswirkungen von Architekturentscheidungen auf Kosten von Team-Ressourcen sichtbar. Das führt dazu, dass sich gute und kostenoptimierte Patterns aufzeigen und durchsetzen können. Teams sind dann dazu motiviert, ihre Freiheit für Experimente und kurzfristig benötigte, teure Zwischenlösungen auszunutzen, haben aber langfristig ihre Kosten immer im Blick – auch im Vergleich mit anderen Teams. Sind Ausreißer dabei (nach oben oder nach unten) wird das zentral sichtbar. Ein FinOps-Team kann hier eingreifen und für die Teams beratend tätig werden.
- Teams treffen Entscheidungen aufgrund von Business Value, nicht aufgrund von Kostenoptimierung. Dadurch tappen Teams nicht in die Falle, Chancen und Experimente auszulassen, nur weil sie teuer sind. Berechnen Sie Kosten auch pro aktiven Nutzer, um einen Anstieg der Kosten durch höhere Nutzerlast nicht negativ aussehen zu lassen.
Abbildung 2 fasst die Ideen und die Struktur von FinOps zusammen.
Abbildung 2: FinOps-Struktur
Für Ihre Kostenreports sind oft feingranulare Fragen interessant. Wenn Sie Ihre Kostenstruktur besser verstehen, dann können Sie auch besser optimieren. Solche Fragen könnten beispielsweise sein:
- Wie teuer sind alle unsere Datenbankressourcen?
- Wie teuer sind die Ressourcen, die wir mit anderen Teams teilen?
- Haben wir Machine-Learning-Kosten außerhalb der Research-Abteilung?
Um diese Fragen beantworten zu können, müssen Sie Ihre Ressourcen kategorisieren. Das erreichen Sie beispielsweise durch Tagging, also die Markierung mit von Ihnen gewählten Schlüssel/Wert-Paaren [ABC] [GTC] [MCO]. Abbildung 3 zeigt Ressourcen in verschiedenen Umgebungen, die jeweils mit Tags versehen sind.
Abbildung 3: Ressourcen mit Tags für Kostenreports
Bei allen großen Cloud-Anbietern können Sie bestimmte Tags für Ressourcen als Pflichtfelder vorgeben. So vergessen Sie auch nicht, richtige Parameter zu vergeben.
Hier sind ein paar Ideen für kostenrelevante Tags. All diese Kriterien können Sie verwenden, um detaillierte Kostenreports zu erzeugen:
- Welches Team hat die Verantwortung über die Ressource?
- Welche Abteilung hat die Verantwortung über die Ressource?
- Wird die Ressource zur Ausführung von Code oder zum Speichern von Daten verwendet?
- Ist die Ressource ein Replica und für Skalierungs- oder Failover-Zwecke vorhanden?
- Wird die Ressource über Teams/Abteilungen hinweg geteilt?
- Wird die Ressource temporär benutzt bspw. für Proof of Concepts?
- Für welches System/Service/Modul wird die Ressource verwendet?
- In welcher Umgebung ist die Ressource provisioniert (Dev, Staging, Prod ..)?
Dieses Thema findet sich als eigene Pillar im AWS Well-Architected Framework. Das heißt aber noch lange nicht, dass Nachhaltigkeit in den anderen Frameworks von Microsoft und Google außer Acht gelassen werden. Meistens sind diese Konzepte dort über andere Pillars verteilt.
Sustainability-Themen sind verwandt zu den Ideen aus den “Cost Optimization”-Pillars. Was Kosten spart – und somit auch mit weniger Ressourcen auskommt – ist in der Regel auch umweltschonender. Im Folgenden fasse ich wichtige Punkte aus der Sustainability-Pillar des AWS Well-Architected Frameworks zusammen:
- Das Shared-Responsibility Model habe ich bereits im Blogpost zur Security-Pillar beschrieben. Dieses Modell gilt auch für das Thema Sustainability – während Ihr Cloud-Anbieter für Nachhaltigkeit der Infrastruktur zuständig ist, sind Sie für die Nachhaltigkeit Ihrer Cloud-Anwendung (Container, Daten, Code) zuständig [ASR].
- Setzen Sie explizite Sustainability-Ziele. Langfristig ressourcenschonendere Cloud-Anwendungen zu entwickeln kommt nicht nur dem Thema Kosteneffizienz zugute – auch Ihre Sustainability-Ziele können Sie damit erreichen. Beispiele für solche Zielsetzungen sind die Minuten von vCPU-Verbrauch, die Menge an Speicher, die Ihre Anwendung provisioniert oder der Umfang Ihrer Netzwerkkommunikation [AME].
- Sustainability als Trade-Off. Sie können an manchen Qualitätseigenschaften einzahlen, um Ihre Sustainability-Ziele einfacher zu erreichen [ASN]. Beispielsweise können Sie bei Ihrer Reliability und Performance einsparen, um redundante Ressourcen zu sparen.
- Architekturmuster wie Event-getriebene Modelle gleichen den Ressourcenverbrauch aus. Sie können auch Queues oder Topics verwenden, um an verschiedenen Stellen unabhängiger und individueller skalieren zu können [AOA].
Das war der sechste Beitrag der Blogreihe “Well Architected Cloud” und somit der letzte Beitrag zu den Pillars. Der nächste Artikel zeigt Ansatzpunkte auf, wie Sie die Architektur-Frameworks in der Praxis einsetzen.
Sie möchten sich zum Thema Kosten, Sustainability oder den Architektur-Frameworks der Cloud-Anbieter austauschen? Melden Sie sich gerne, meine Kontaktdaten finden Sie hier.
“Well Architected Cloud: ein Überblick über drei Architektur-Ratgeber”
‘Well Architected Cloud: die “Operational Excellence”-Pillar’
“Well Architected Cloud: die Security-Pillar”
“Well Architected Cloud: die Reliability-Pillar”
‘Well Architected Cloud: die “Performance Efficiency”-Pillar’
“Well Architected Cloud: die Architektur-Frameworks effektiv und effizient einsetzen”
“Die Pillar “Cost Optimization” im AWS Well-Architected Framework”
“Die Sustainability-Pillar im AWS Well-Architected Framework”
“Die Pillar “Cost Optimization” im Azure Well-Architected Framework”
“Die Pillar “Cost Optimization” im Google Cloud Architecture Framework”
[ACF] “Establish a cost optimization function”
[ABC] “Configure billing and cost management tools”
[AME] “Evaluate specific improvements”
[ASR] “The shared responsibility model”
[ASN] “Sustainability as a non-functional requirement”
[AOA] “Optimize software and architecture for asynchronous and scheduled jobs”
[FOP] “What is FinOps”
[GFO] “Adopt and implement FinOps”
[GTC] “Track and allocate cost using labels”
[MCO] “Generate cost reports”
Alexander Kaserbacher