Architektur-Ratgeber in der Cloud
Die Landschaft von Cloud-Services und die darin enthaltene technische Komplexität ist in den vergangenen Jahren rasant gewachsen. Dadurch stehen wir vor der Herausforderung, dass Architektur im Cloud-Umfeld immer schwieriger wird. Es gibt viele Bereiche, die bedacht werden müssen und ständige technische Innovation, die den Lösungsraum unserer Entscheidungen kontinuierlich verändert. Die frei verfügbaren Architektur-Frameworks der drei großen Cloud-Anbieter (Amazon, Microsoft und Google) versprechen hier Abhilfe. Wie nützlich sind sie wirklich? Und wie können Sie diese in der Praxis einsetzen? Dieser Artikel gibt Antworten.
"Noch ein letztes T-Shirt einpacken... hab‘ ich alles dabei?", ich schließe meinen Koffer und mache mich auf den Weg... nur um dann am Reiseziel festzustellen, dass ich doch mein Ladekabel vergessen habe.
Es ist schwierig, an alles zu denken und zudem gefährlich, etwas Komplexes wie Software-Entwicklung mit Kofferpacken zu vergleichen. Aber es ist offensichtlich, dass wir auch bei einem technisch komplexen Thema (wie der Entwicklung von Cloud-Anwendungen) an bestimmte Dinge denken müssen. Haben wir sichergestellt, dass wir für Alarme exakte Action Items definiert haben? Haben wir an relevanten Stellen an Datenverschlüsselung gedacht? Sind unsere Services zustandslos?
Über bestimmte Fragen müssen wir uns auf Architekturebene Gedanken machen. Vielleicht haben wir auch schon viele Anwendungen in der Cloud entwickelt und eine gewisse Routine und einen Erfahrungsschatz aufgebaut. Gegebenenfalls ist es aber auch unser erster Kontaktpunkt mit Cloud-Anwendungen. In jedem Fall würden uns Ratgeber guttun, die für uns die wichtigsten Fragestellungen aufwerfen, über die wir uns bei unserer Lösung Gedanken machen sollen.
Genau solche Ratgeber stellen uns die drei großen Cloud-Vendoren zur Verfügung. Aus dem Wissen und den Erfahrungen von Systemen ihrer Kunden hat Amazon 2015 das "AWS Well-Architected Framework" [1] destilliert. Microsoft [2] und Google [3] haben im Jahr 2020 mit ihrer jeweils eigenen Version nachgezogen.
Struktur
Die Frameworks sind grundsätzlich ähnlich aufgebaut. Abbildung 1 zeigt eine verallgemeinerte Struktur mit Begriffen, die Sie in allen drei Frameworks wiederfinden.
Die Frameworks unterteilen sich in sogenannte Pillars (englisch für Säulen), die wiederum Designprinzipien und Best Practices enthalten. Designprinzipien sind allgemeine Leitplanken und inspirieren eine Richtung, in die sich unsere Cloud-Anwendung perspektivisch entwickeln soll. Best Practices sind konkrete Vorschläge, die Sie direkt umsetzen können. Da jede Pillar üblicherweise recht viele Best Practices enthält, werden sie gruppiert. Das sind – je nach Framework – typischerweise Fragen, die wiederum in Best Practice Bereiche einsortiert sind. Fragen eignen sich als Gruppierung, da die konkreten Best Practices auf Themen wie "Wie führen Sie Backups durch?" Antworten liefern.
Die Pillars
Bei der Entwicklung von Software spielen verschiedene Qualitätsaspekte eine Rolle. Soll Ihr System besonders schnell oder zuverlässig sein? Haben Sie vielleicht außerordentliche Anforderungen an die Sicherheit? Oder wollen Sie eher ein kostengünstiges System in der Cloud betreiben? Pillars repräsentieren diese Aspekte und tragen erfolgreiche Lösungen in der Cloud.
Operational Excellence
Die "Operational Excellence"-Pillar konzentriert sich auf Automatisierung, Observability und Continuous Integration. Hier finden Sie Themen wie Metriken und Alarme genauer aufgeschlüsselt sowie Best Practices für Ihren Entwicklungs-, Integrations- und Deployment-Prozess.
Security (Google Architecture Framework: Security, privacy, and compliance)
Diese Pillar beschäftigt sich mit Security-relevanten Themen, wie Encryption at rest (also auf der Platte) oder in transit (also im Netzwerk). Außerdem deckt sie das Management von Zugriffsberechtigungen und Authentifizierung ab und gibt Hinweise, wie Sie die Sicherheit Ihrer Systeme kontinuierlich überwachen und verbessern können.
Reliability
Hier finden sich Themen wie "Disaster Recovery" oder Best Practices für Anwendungen, die in mehreren Regionen laufen sollen. Werfen Sie auch einen Blick in diese Pillar, wenn Sie sich über Ihre Backup-Strategie Gedanken machen.
Performance Efficiency (Google Architecture Framework: Performance optimization)
In der "Performance Efficiency"-Pillar finden Sie neben Best Practices zur Auswahl der performantesten Ressourcen auch Konzepte zum Monitoring von Performance.
Cost Optimization
Da viele Best Practices aus den anderen Pillars (z. B. Redundanz, Verschlüsselung) Konstrukte einführen, die zusätzliche Kosten verursachen, enthält diese Pillar Trade-Offs. Sie finden hier aber auch Inspiration zur optimalen Kostenüberwachung und wie Sie Ihre Systeme kosteneffizient betreiben.
Sustainability
Diese Pillar findet sich nur im AWS Well-Architected Framework wieder. Viele dieser Elemente sind aber eng verwandt mit Best Practices aus "Cost Optimization" – wenn Ihr System kostengünstig läuft, dann läuft es auch ressourcenschonend und damit nachhaltig.
System Design
Google hat sich dazu entschieden, einige Best Practices zum allgemeinen Systemdesign in eine eigene Pillar auszulagern. Viele dieser Elemente finden sich bei Microsoft oder Amazon in den spezialisierten Pillars. Hier geht es vor allem um die Auswahl von Regionen und Rechenzentren, Datenbank- und Netzwerk-Optimierung sowie Kernprinzipien zum Systementwurf.
Eine Übersicht der hier erwähnten Pillars finden Sie in Abb. 2. In meiner Blogserie stellen einzelne Beiträge jede Pillar im Detail vor [4].
Die Designprinzipien
Alle drei Architektur-Frameworks enthalten grundlegende Designprinzipien, die sich auf die Entwicklung und den Betrieb von Cloud-Anwendungen beziehen. Eine Zusammenfassung der Designprinzipien aus den drei Frameworks finden Sie in Abbildung 3.
Erlauben Sie Evolution in Ihrer Architektur. Gestalten Sie Ihre Systeme so, dass sie offen für Veränderung sind. Sich ständig ändernde Anforderungen machen Anpassungsfähigkeit notwendig. In der Cloud sind Sie dort gut aufgehoben, da Sie durch die Flexibilität der Ressourcen auch hier auf Evolution setzen können.
Nutzen Sie die Daten in der Cloud, um Entscheidungen zu unterfüttern. Verschiedene Metriken und Logs – nicht nur aus Anwendungscode, sondern auch System- und Infrastrukturdaten – bieten Ihnen eine hervorragende Unterstützung bei der Weiterentwicklung des Systems. Lernen Sie aus historischen Daten und ziehen Sie Schlüsse für zukünftige Entscheidungen.
Raten Sie nicht, wie viel Kapazität Sie benötigen, sondern skalieren Sie flexibel. Durch das Konzept des "Self-Service" können Sie in der Cloud per API-Aufruf neue Ressourcen zuschalten und nicht mehr benötigte Ressourcen entfernen. Des Weiteren bezahlen Sie nur für die Ressourcen, die Sie benötigen. Nutzen Sie diese Möglichkeit und skalieren Sie so flexibel wie möglich. Dies betrifft nicht nur Rechenressourcen, sondern auch Speicherplatz und andere Infrastruktur wie Netzwerke.
Automatisieren Sie manuelle Arbeit. Dies betrifft unter anderem die Beschaffung oder Skalierung von Ressourcen, aber auch die Auswertung von Anomalien in Log-Files oder das Aufdecken ungewöhnlicher Nutzeraktivitäten in der Administrationsoberfläche Ihrer Cloud-Umgebung. Viele dieser Aktivitäten sollten sinnvoll automatisiert werden.
Ausgewählte Designprinzipien aus den Pillars
Wie in Abb. 1 dargestellt, haben die jeweiligen Pillars auch spezifischere Designprinzipien. In den folgenden Absätzen hebe ich spannende Gemeinsamkeiten heraus.
Etablieren Sie "Everything as code": Applikationen, Infrastruktur, Konfiguration, betriebliche Vorgänge. Im "Operational Excellence"-Pillar finden Sie Prinzipien zur Automatisierung. Die deklarative Ausgestaltung von Infrastruktur mittels "Infrastructure as Code" ist längst Standard in vielen Unternehmen. Automatisieren Sie auch betriebliche Vorgänge, wie Recovery-Mechanismen oder das Patching von Betriebssystemen.
Ein Prinzip aus der Security-Pillar ist das "Defense in depth"-Prinzip. Es besagt, dass es beim Absichern von Systemen nicht ausreicht, sich nur mit einer Ebene zu beschäftigen. Sie müssen Ihre Systeme in verschiedenen Bereichen absichern. Denken Sie nicht nur an die Sicherheit Ihres Anwendungscodes, sondern auch an die Sicherheit Ihrer Container, Ihres Clusters oder der (virtuellen) Maschinen, auf denen die Container laufen.
Das Konzept der horizontalen Skalierung ist ein Prinzip in der Reliability-Pillar. Im Gegensatz zur vertikalen Skalierung werden hier neue Ressourcen (z.B. virtuelle Maschinen) hinzugefügt, anstatt die bestehenden Ressourcen aufzuwerten (z. B. schnellere virtuelle Maschinen).
Wenn Sie einen Blick in die "Cost Optimization"-Pillar werfen, dann finden Sie Prinzipien zur Überwachung Ihrer Kosten. Machen Sie sich Gedanken über Budget-Limits für bestimmte Umgebungen oder Ressourcen-Typen und erstellen Sie automatisierte Alarme, die Ihnen im Fall einer Budgetüberschreitung zeitnah eine Rückmeldung geben.
Die Best Practices
Im Gegensatz zu den Designprinzipien geben Ihnen Best Practices konkrete Umsetzungen an die Hand. Sie finden etwa im Security-Pillar Best Practices zur Verwaltung Ihrer Schlüssel für "Encrpytion at rest", also der Datenverschlüsselung auf Datenspeichern.
Eine andere Best Practice empfiehlt, dass Sie die Verschlüsselung mittels SSL/TLS an einen Load Balancer auslagern sollen, der zugleich die Last gleichmäßig auf Ihre Ressourcen verteilt.
Spätestens auf dieser Ebene unterscheiden sich die Frameworks der verschiedenen Anbieter deutlich. Während Amazon seine Best Practices recht stark mithilfe der Fragenkonstrukte strukturiert, ist das Framework der Google Cloud etwas loser strukturiert. Manchmal ist es notwendig, dass Sie das jeweilige Framework recht genau kennen, insbesondere wenn Sie spezifisch nach Best Practices suchen.
Oft finden Sie in den Best Practices auch konkrete Hinweise auf herstellerspezifische Cloud-Services, die Sie zur Erfüllung der Aufgaben benutzen können.
Domänen- und technologiespezifische Erweiterungen
Die Designprinzipien und Best Practices der Architektur-Frameworks sind so gewählt, dass sie auf möglichst viele Cloud-Anwendungen anwendbar sind. Amazon und Microsoft bieten zudem für bestimmte Branchen und Technologienischen Erweiterungen an. Diese stellen zusätzliche Designprinzipien und Best Practices zur Verfügung, aber spezifisch für die jeweilige Branche (z. B. Finance) oder Technologie (z. B. Serverless).
Diese Erweiterungen heißen im Amazon-Kontext "Lenses" und im Microsoft Azure Well Architected Framework sind sie unter "Workloads" zu finden.
Anwendung der Architektur-Frameworks
Sie können die Architektur-Frameworks auf unterschiedliche Arten anwenden. Die Intention der Cloud-Vendoren war initial, dass Sie die Best Practices dazu nutzen, bestehende Systeme zu beleuchten und bestehende Architekturentscheidungen zu hinterfragen. Allerdings sind die Frameworks mittlerweile so groß und mächtig, dass Sie das darin enthaltene Wissen auch für neue bzw. offene Fragestellungen auf Architekturebene benutzen könnten.
Beides sind valide Anwendungsfälle, erfordern aber etwas andere Herangehensweisen.
Die Architektur-Frameworks als Werkzeug für Architektur-Reviews
Sie haben eine bestehende Lösung, die (zumindest teilweise) in der Cloud läuft. Nun nehmen Sie das Architektur-Framework des Cloud-Anbieters Ihres Vertrauens zur Hand. Plötzlich sehen Sie sich mit hunderten Best Practices konfrontiert, die Sie mit Ihrem Team und relevanten Stakeholdern durchsprechen sollen. Zudem werden Sie bemerken, dass nicht zu allen Best Practices eine einheitliche Meinung im Team besteht. Das führt dazu, dass Sie und Ihr Team bei vielen Best Practices etwas länger diskutieren. Dies ist in erster Linie gut, weil die Architektur-Frameworks so konzipiert sind, um Redeanlässe zu erzeugen. Der Aufwand einer solchen Bewertung wird aber schnell recht hoch.
Daher werden Sie davon profitieren, wenn Sie Best Practices auswählen und priorisieren. Vielleicht wollen Sie das Framework auch einfach in einem kleinen Workshop ausprobieren. Hier ist es hilfreich, wenn Sie Best Practices durchsprechen, die einen möglichst großen Einfluss haben.
Bei der Auswahl von passenden Best Practices bieten Ihnen die Leitfragen aus Abbildung 4 eine Orientierung. So können Sie eine kleine, priorisierte Auswahl von Best Practices für einen Durchsprache-Workshop vorbereiten.
Amazon und Microsoft bieten zur Besprechung der Frameworks auch Tools an. Dort können Sie auswählen, welche Best Practices Sie erfüllen und welche nicht. Das jeweilige Werkzeug generiert im Anschluss einen Bericht mit Risiken aus unerfüllten Best Practices. Abb. 5 zeigt diese Tools.
Die Architektur-Frameworks als Unterstützung für Architekturentscheidungen
Stellen Sie sich vor, Sie stehen vor einer wichtigen Architekturentscheidung und haben bereits einige Lösungsoptionen gefunden und diskutiert. Mehrere hundert Best Practices werden Ihnen beim Treffen der Entscheidung nur eine kleine Hilfe sein. Manche sind detaillierter, andere abstrakter und wieder andere beziehen sich auf Vorgehen und Methoden. Wenn Sie jede Lösungsoption im Rahmen dieser Best Practices diskutieren müssen, dann bringt Ihnen das wenig Mehrwert und kostet viel Zeit. Außerdem ist es unrealistisch, bei der Entscheidungsfindung jede Best Practice im Kopf zu haben.
Viel mehr Sinn ergibt es, zuerst einen Lösungsfavoriten auszuwählen. Lassen Sie sich durch die Richtung inspirieren, die Ihnen die Designprinzipien der Architektur-Frameworks vorgeben. Diesen Lösungsfavoriten halten Sie dann gegen ausgewählte Best Practices und überprüfen, ob Sie wichtige Aspekte vergessen oder vernachlässigt haben. Abb. 6 gibt einen schematischen Überblick dieses Prozesses.
Eine kleine Notiz am Rande: Es gibt Best Practices, die Sie und Ihr Team direkt beim Treffen von Architekturentscheidungen unterstützen. Ein Beispiel aus dem AWS Well-Architected Framework ist eine Empfehlung für ein Vorgehen zur Auswahl von Datenbanksystemen [5]. Um konkrete Best Practices für eine Entscheidungsfindung identifizieren zu können, müssen Sie das jeweilige Framework aber schon etwas besser kennen. Es ist nicht verboten (und sogar sehr nützlich), solche eher methodischen Best Practices als Unterstützung zu verwenden – nutzen Sie aber als Daumenregel eher die Designprinzipien, insbesondere wenn das Framework noch recht neu für Ihr Team ist.
Und nun?
Jetzt haben Sie einen groben Überblick bekommen. Sie wissen, dass Sie die Architektur-Frameworks als Review-Unterstützung oder als Unterstützung für Architekturentscheidungen benutzen können.
Als nächsten Schritt empfehle ich Ihnen, dass Sie sich im Team einen halben Tag Zeit für einen Workshop nehmen und wichtige Best Practices besprechen. Bereiten Sie den Termin gut vor und benutzen Sie die Frageliste in Abb- 3 als Unterstützung, um 5 bis 10 Best Practices zu finden, auf die Sie sich in dem Workshop fokussieren. Starten Sie gerne mit dem Architektur-Framework Ihres Cloud-Anbieters.
Wenn Sie in der private Cloud sind, dann nehmen Sie einfach das AWS Well Architected Framework, da es aktuell am besten strukturiert ist und den einfachsten Einstieg bietet. Sie müssen dann nur die proprietären Cloud-Services in den Best Practices durch (Open-Source-)Dienste ersetzen, die Ihnen zur Verfügung stehen.
Ich wünsche Ihnen mit der Anwendung dieser mächtigen und umfangreichen Werkzeuge spannende Erkenntnisse!
- Das AWS Well-Architected Framework
- Das Microsoft Azure Well-Architected Framework
- Das Google Cloud Architecture Framework
- Blogreihe, A. Kaserbacher
- AWS Database architecture selection - Performance efficiency Pillar
