Well Architected Cloud: ein Überblick über drei Architektur-Ratgeber

Alexander Kaserbacher
28.02.2023

Lesezeit: 8 Minuten

Die großen Cloud-Vendoren AWS, Microsoft Azure und Google Cloud geben uns mit ihren drei Architekturframeworks ein mächtiges Werkzeug an die Hand. Dieser Blogpost ist der erste der Reihe "Well Architected Cloud" und führt in das Thema ein.

Stellen wir uns eine Situation vor, wo wir ein neues System entwickeln oder ein bestehendes System in die Cloud (sei es private oder public) migrieren wollen. An welche Architekturfragen sollen wir denken? Wie können wir das Risiko minimieren, bei diesem Umfang an Cloud-Angebot etwas zu übersehen? Gibt es Hindernisse, über die andere bereits gestolpert sind? Zudem ist Cloud-Computing ein sehr umfangreiches Thema.

Die Landscape der Cloud Native Computing Foundation, die verschiedene Produkte und Projekte im Cloud-Umfeld auflistet, umfasst mittlerweile 1.174 Einträge [1]. Dabei handelt es sich um Technologien und Services - teilweise Open Source und teilweise proprietär - die im Cloud-Umfeld Einsatz finden. Der Umfang dieser Werkzeuge und das dazugehörige Know-How ist schwer für einzelne Personen oder Teams zu fassen.

Somit ist es sehr hilfreich, wenn wir auf einen etablierten Erfahrungsschatz zurückgreifen können. Einerseits hilft gute Dokumentation, die uns bei spezifischen Fragen rund um Tools und Services Abhilfe schaffen kann. Aber das reicht noch nicht aus.

Die drei großen Cloud-Anbieter (Amazon, Microsoft und Google) haben erkannt, dass bei vielen ihrer Kunden diese Probleme aufkommen. Daraus haben sie eine Sammlung von Best Practices, die oft funktionieren, zusammengetragen und strukturiert. AWS hat im Jahr 2015 das “Well-Architected Framework” veröffentlicht. Microsoft hat 2020 mit einem gleichnamigen Framework nachgezogen, während Google im selben Jahr ihr “Architecture Framework” vorstellten. Abbildung 1 zeigt einen groben Vergleich der drei Frameworks. Ich gehe im Folgenden genauer auf Gemeinsamkeiten und Unterschiede ein.

Abb. 1: Die drei Frameworks gegenübergestellt

Struktur

Die Frameworks sind unterschiedlich aufgebaut, aber es gibt in der Struktur wichtige Gemeinsamkeiten. Beispielsweise taucht der Begriff “Pillar” (englisch für Säule) oder “Best Practice” in allen drei Frameworks auf. Abbildung 2 illustriert die Gemeinsamkeiten.

Abb. 2: Struktur der drei Frameworks konsolidiert

Pillars sind die oberste Einordnungsebene für jedes der drei Frameworks. Jede Pillar entspricht im Wesentlichen einem Qualitätsziel, das wir im Cloud-Umfeld erreichen möchten: “Operational Excellence”, Sicherheit, Zuverlässigkeit, Performance und Kosteneffizienz. AWS definiert noch zusätzlich eine Nachhaltigkeits-Pillar und die Google Cloud hat einen fundamentale Pillar, in dem es um allgemeines Systemdesign geht.

Pillars beinhalten jeweils Designprinzipien und Best Practices:

Designprinzipien sind allgemeine Wegweiser zur Entscheidungsfindung, die für jede Pillar eine Richtung vorgeben. Beispiele sind das Prinzip von kleinen, reversierbaren Releases aus der Pillar “Operational Excellence” oder das “Defense in depth” Prinzip in der Security-Pillar.
Best Practices geben abgeleitet aus den Designprinzipien konkrete Implementierungsvorschläge. Es gibt etwa in allen drei Frameworks Best Practices, die das Definieren von aussagekräftigen Systemmetriken vorschlagen.

Fragen und Best Practice Bereiche dienen hauptsächlich dazu, die große Anzahl an Best Practices zu gruppieren und strukturieren. Die Strukturierung nach Fragen (mit Best Practices als Antworten) ist sehr hilfreich beim Durchführen von Architekturreviews anhand der Frameworks.

Verwendung der Frameworks

Sie können die Frameworks auf zwei verschiedene Arten verwenden: als Wissensdatenbank oder als Review-Grundlage.

Wenn Sie das Framework Ihres Cloud-Providers als Wissensdatenbank verwenden, dann können Sie Entscheidungen nach den Designprinzipien und Best Practices der Frameworks ausrichten. Designprinzipien sind hier sehr nützlich, da sie eine Richtung bei einzelnen Architekturentscheidungen vorgeben.

Außerdem können Sie das Framework als Review-Grundlage benutzen, dann können Sie für einzelne Best Practices überprüfen, ob Sie diese einhalten. In einem weiteren Blogbeitrag dieser Reihe werde ich genauer darauf eingehen. Zwei wichtige Punkte allerdings vorab:

Nicht alle Best Practices passen für jeden Kontext und jede Situation. Die Implementierung einzelner Best Practices bringt Kosten mit sich, die dem jeweiligen Nutzen gegenübergestellt werden sollen. Hinterfragen Sie jede Best Practice und starten Sie im Idealfall mit einer kleineren Auswahl von Best Practices, z. B. einer einzelnen Pillar.
Ein solches Review ist kein Audit. Sehen Sie es als Möglichkeit, über Best Practices zu diskutieren und Dinge aufzudecken, an die Sie (noch) nicht gedacht haben. Die Durchsprache von Best Practices im Team wird oft eine Diskussion lostreten. Sehen Sie diese Gespräche als eine konstruktive Konversation über Architekturentscheidungen und betrachten Sie diese als wertvoll, da sie neue Erkenntnisse und Lerneffekte hervorbringen.

Allgemeine Designprinzipien

Sowohl das AWS Well-Architected Framework als auch (etwas versteckt) das Azure Well-Architected Framework definieren allgemeine Designprinzipien für die Cloud [2] [3]. Diese Prinzipien sind fundamental und es ist absolut notwendig, dass Sie diese Prinzipien beachten, wenn Sie erfolgreich Systeme in der Cloud entwickeln wollen.

Ich habe die Designprinzipien von AWS und Azure zusammengefasst und verdichtet. Abbildung 3 zeigt einen Überblick.

Abb. 3: Allgemeine Designprinzipien zusammengefasst

Erlauben Sie Evolution in der Architektur. Der Kontext unserer Systeme ändert sich ständig. Denken Sie diese Faktoren mit und halten Sie Ihre Architektur flexibel genug, um schnell auf Änderungen reagieren zu können. Cloud-Umgebungen helfen Ihnen dabei, da viele Prozesse automatisiert sind, z. B. das Provisionieren neuer Testumgebungen.
Nutzen Sie die Daten in der Cloud, um Entscheidungen zu unterfüttern. Neben den von Ihnen definierten Metriken, zeichnen Cloud-Services viele Systemdaten auf, die Ihnen bei der Entscheidungsfindung helfen können. Sie sind sich nicht sicher, ob Ihr Datenbank-Cluster in bestimmten Situationen skaliert? Prüfen Sie Logs und Metriken Ihrer Systeme und stellen Sie Situationen in Testumgebungen nach.
Raten Sie nicht, wie viel Kapazität Sie benötigen, sondern skalieren Sie flexibel. Die Aufgabe, ein passendes Volumen von Servern für ein Softwaresystem zu beschaffen, ist ein Ratespiel. Fast immer beschaffen sie zu viel oder zu wenig. In Cloud-Umgebungen haben Sie dieses Problem nicht, da Sie zu jeder Zeit genau so viele Ressourcen allokieren können, wie Sie gerade benötigen. Nutzen Sie das und denken Sie automatische Skalierung in Ihrer Architektur mit.
Automatisieren Sie manuelle Arbeit. Viele Prozesse, die früher manuell erledigt wurden, sind in der Cloud automatisch möglich. Wenn Sie eine neue virtuelle Maschine benötigen, dann rufen Sie eine API auf, anstatt ein Ticket in einer zentralen IT-Abteilung anzulegen. Denken Sie dieses Konzept weiter und automatisieren Sie so viel wie möglich. Dazu zählen etwa das Hochziehen und Löschen von vollumfänglichen Test- und Entwicklungs-Umgebungen Ihres Systems.

Tools

Wenn Sie die Architekturframeworks als Review-Tool einsetzen möchten, dann geben Ihnen AWS und Azure Werkzeuge an die Hand, mit denen Sie systematisch Ihre Best Practices evaluieren können. Die Google Cloud stellt zurzeit noch kein entsprechendes Werkzeug zur Verfügung.

Die Assessment-Tools bieten eine Checkliste an, in der Sie Best Practices abhaken können. Das AWS-Tool erlaubt zudem, Best Practices als “nicht zutreffend” zu deklarieren, wenn sie für dieses spezifische System nicht anwendbar sind. Abbildung 4 zeigt die beiden Tools gegenübergestellt.

Abb. 4: Das Azure Well-Architected Review Assessment (links) und das AWS Well-Architected Tool (rechts) gegenübergestellt.

Azure und AWS bieten außerdem Hilfestellungen an, um Ihnen beim Ausfüllen der Best Practices zu helfen. Sie können den Azure Advisor [4] oder den AWS Trusted Advisor [5] mit dem entsprechenden Well-Architected Tool verknüpfen. Diese Tools überprüfen bestimmte Konfigurationen in Ihrer Cloud und machen Vorschläge, ob Sie bestimmte Best Practices einhalten oder nicht.

Wenn Sie das Review abschließen, generiert das Tool einen Abschluss-Report mit Risiken. Jede Best Practice, die Sie nicht abgehakt haben, wird zu einem Risiko. AWS bzw. Azure geben Ihnen zu jedem Risiko eine Einschätzung, ob Sie es als “hoch”, “mittel” oder “niedrig” einstufen sollen.

Domänen- und Technologie-spezifische Elemente

Wenn Sie sich mit den Architekturframeworks genauer beschäftigen und vielleicht erste Review-Runden absolviert haben, dann werden Sie merken, dass die Best Practices sehr allgemein gehalten sind. Der Grund dafür ist, dass die grundlegenden Prinzipien und Best Practices alle Arten von Systemen und verschiedenen Domänen abzudecken versuchen. Um dem entgegenzuwirken, haben die Cloud-Vendoren Erweiterungen für die Frameworks entwickelt, die Domänen- oder Technologie-spezifische Designprinzipien und Best Practices einstreuen.

AWS nennt diese Erweiterungen “Lenses”. Stand heute gibt es 14 Lenses. Unter anderem für die Gesundheits- oder Gaming-Industrie oder für Systeme, die sich um Internet of Things (IoT) drehen. Azure hat für ihre eigenen “Lenses” keinen spezifischen Namen. Ich nenne sie “Workload Guides”, da jeder Guide eine spezielle System-Art bedient. So gibt es beispielsweise einen Guide für kritische Systeme oder hybride Cloud-Anwendungen. In Summe gibt es 7.

Seit 2022 unterstützt AWS außerdem sogenannte “Custom Lenses”, wo Sie selbst eigene Best Practices definieren und mit anderen teilen können. Mehr Informationen dazu finden Sie unter [6].

Die Blogreihe

Dieser Beitrag ist der Erste in meiner Blogreihe “Well Architected Cloud”. Die nächsten Artikel, die wöchentlich erscheinen werden, behandeln jeweils eine Pillar. Abschließen werde ich mit einem Beitrag über den methodischen Einsatz dieser Frameworks im “Architekturalltag”, zum Beispiel als Werkzeug für Architektur-Reviews. Ich freue mich auf die kommenden Wochen!

Sie möchten sich gerne zu den Architekturframeworks der Cloud-Anbieter austauschen? Melden Sie sich gerne, meine Kontaktdaten finden Sie hier.

Well Architected Cloud: ein Überblick über drei Architektur-Ratgeber

Referenzen