embarc logo
embarc logo

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

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.

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.

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:

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:

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.

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.

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.

 

Weitere Blogposts in dieser Reihe

‘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 Pillars “Cost Optimization” und Sustainability”
“Well Architected Cloud: die Architektur-Frameworks effektiv und effizient einsetzen”

 

“Das AWS Well-Architected Framework”, Stand Februar 2023
“Das Azure Well-Architected Framework”, Stand Februar 2023
“Das Google Cloud Architecture Framework”, Stand Februar 2023

Referenzen

[1] “Landscape der CNCF”, Stand Februar 2023
[2] “Generelle Designprinzipien des AWS Well-Architected Frameworks”, Stand Februar 2023
[3] “Generelle Designprinzipien des Azure Well-Architected Frameworks”, Stand Februar 2023
[4] “Azure Advisor”, Produktübersicht
[5] “AWS Trusted Advisor”, Produktübersicht
[6] “AWS Well-Architected Custom Lenses”, Produktdokumentation