実運用に耐える Azure アーキテクチャの設計 — MVP Mike Martin さんとともに

Azure-Architektur wirkt einfach, solange alles funktioniert. Der eigentliche Test beginnt, wenn Abhängigkeiten ausfallen, Regionen nicht verfügbar werden, Lastspitzen auftreten, Annahmen sich als falsch erweisen, Anforderungen sich ändern und irgendwann jemand die unbequeme Frage stellt: Warum haben wir das überhaupt so entworfen?

In dieser Folge von M365.FM spricht Mirko Peters mit Mike Martin [MVP] darüber, wie Azure-Architektur aussieht, wenn sie unter realen Produktionsbedingungen bestehen muss und nicht nur auf einem Diagramm gut aussieht.Mike bringt jahrzehntelange Erfahrung aus Entwicklung, Infrastruktur, Architektur, Führung, Coaching, Schulung und Microsoft Azure mit. Eine seiner stärksten Beobachtungen ist, dass viele Probleme, mit denen Architekten heute konfrontiert sind, eigentlich nicht neu sind. DNS fällt weiterhin aus. IP-Abhängigkeiten sind weiterhin wichtig. Kosten werden weiterhin zum Problem. Integrationen scheitern weiterhin. Abhängigkeiten verschwinden weiterhin im ungünstigsten Moment.

Was sich verändert hat, ist das Maß an Komplexität, das wir um diese Probleme herum aufbauen.

VOM VISUAL BASIC ZUR MODERNEN AZURE-ARCHITEKTUR
Mike blickt auf fast drei Jahrzehnte in der IT zurück, angefangen als Visual-Basic-Entwickler in den 1990er-Jahren, über verteilte Systeme, Netzwerke, Unternehmenssoftware und Infrastruktur bis hin zu Azure.

Seine zentrale Beobachtung ist einfach: Die Branche löst immer wieder dieselben grundlegenden Probleme, aber die Architekturen darum herum sind deutlich komplexer geworden.

Moderne Systeme haben sich von Client-Server-Anwendungen zu verteilten Architekturen, Cloud-Plattformen, Containern, Microservices, Kubernetes, hybriden Umgebungen und inzwischen KI-gestützter Entwicklung entwickelt. Das eröffnet enorme Möglichkeiten, schafft aber auch ein neues Risiko: Überengineering.

Mike argumentiert, dass viele Teams heute einfache Probleme unnötig kompliziert machen. Gute Architektur bedeutet oft nicht, mehr Technologie hinzuzufügen, sondern zu wissen, was man nicht hinzufügen sollte.

WAS MACHT EIN AZURE-ARCHITEKT EIGENTLICH?
Für Mike geht es bei Architektur nicht darum, möglichst viele Azure-Dienste auszuwählen oder ein beeindruckendes Diagramm zu erstellen.

Es geht darum zu verstehen, welche Komponenten zusammengehören, welche vermieden werden sollten, welche notwendig sind und wie man etwas baut, das wartbar, skalierbar, sicher und resilient bleibt.

Architektur umfasst weit mehr als Rechenleistung.

• Identität
• Netzwerke
• Datenflüsse
• Sicherheit
• Überwachung
• Integration
• Abhängigkeiten
• Skalierbarkeit
• Betrieb
• Wiederherstellung
• Bereitstellung
• Kosten

Mike stellt außerdem die Vorstellung infrage, dass Cloud-native automatisch Kubernetes oder Container bedeutet. Azure bietet viele verwaltete und native Dienste, die Probleme lösen können, ohne unnötigen Betriebsaufwand zu erzeugen.

Die Rolle des Architekten besteht darin, die gesamte Lösung zu verstehen und die einfachste Architektur zu wählen, die dennoch die realen Anforderungen erfüllt.

MIT GESCHÄFTSANFORDERUNGEN BEGINNEN, NICHT MIT AZURE-DIENSTEN
Eine der wichtigsten Lehren dieser Folge ist einfach: Man sollte nicht mit der Technologie beginnen.

Bevor Teams sich für Azure Kubernetes Service, App Service, Azure Functions, Container, Service Bus oder eine andere Plattform entscheiden, sollten sie zuerst verstehen, was die Lösung tatsächlich leisten muss.

Fragen, die man stellen sollte:

• Ist die Lösung intern oder kundenorientiert?
• Wie viele Nutzer werden davon abhängig sein?
• Muss sie global skalieren?
• Wie lange darf sie nicht verfügbar sein?
• Wie viele Daten kann das Unternehmen sich leisten zu verlieren?
• Welche Compliance-Anforderungen gelten?
• Was passiert, wenn die Anwendung mehrere Stunden verschwindet?
• Wer ist betroffen?
• Welcher Umfang an betrieblicher Unterstützung wird benötigt?

Diese Fragen führen direkt zu Konzepten wie SLAs, SLOs, RTOs und RPOs. Sie bestimmen außerdem, ob die Architektur single-region, multi-region, active-active, active-passive oder deutlich einfacher sein sollte.

RTO UND RPO OHNE BUZZWORDS
RTO und RPO werden oft als technische Akronyme diskutiert, aber ihre eigentliche Bedeutung ist geschäftsorientiert.

• RTO – Recovery Time Objective: Wie schnell muss das System nach einem Ausfall wieder verfügbar sein?
• RPO – Recovery Point Objective: Wie viel Datenverlust ist akzeptabel?

Ein System für unkritische Überwachung kann mehrere Stunden Ausfall oder Datenverlust verkraften. Ein System, das Ersthelfer, Finanzprozesse, Handel oder kritische Infrastruktur unterstützt, benötigt unter Umständen eine Wiederherstellung innerhalb von Minuten.

Der wichtige Punkt ist, dass diese Werte nicht vom Architekten erfunden werden sollten. Sie sollten sich aus den tatsächlichen geschäftlichen Auswirkungen eines Ausfalls ergeben. Sobald diese Anforderungen verstanden sind, lassen sie sich in technische Designentscheidungen übersetzen.

RESILIENZ IST NICHT DASSELBE WIE HOHE VERFÜGBARKEIT
Mike verwendet eine einfache Analogie, um den Unterschied zwischen Verfügbarkeit und Resilienz zu erklären.

Ein hochverfügbares System hat möglicherweise eine andere Komponente bereit, die übernimmt, wenn die primäre ausfällt. Ein resilientes System ist so konzipiert, dass es Probleme abfängt, weiterhin funktioniert, sich geordnet erholt und wieder in den Normalbetrieb zurückkehrt, ohne vollständig zusammenzubrechen.

Dieser Unterschied ist wichtig. Eine Anwendung kann technisch verfügbar sein und dennoch eine schlechte Erfahrung bieten. Sie kann:

• langsam sein
• gedrosselt werden
• teilweise nicht verfügbar sein
• von einem ausfallenden Backend abhängen
• von einem Integrationsproblem betroffen sein
• unter regionalem Druck stehen

Echte Resilienz erfordert daher mehr als Betriebszeit. Sie erfordert eine Architektur, die mit Last, Anwendungsfehlern, Teilausfällen, regionalen Problemen, defekten Abhängigkeiten, Betriebsvorfällen und der Wiederherstellung nach dem Vorfall umgehen kann.

AZURE MACHT IHRE ANWENDUNG NICHT AUTOMATISCH RESILIENT
Eine gefährliche Annahme lautet, dass eine Anwendung, die auf Azure läuft, automatisch die Resilienz der Plattform erbt, weil Azure selbst hochverfügbar ist.

Das stimmt nicht. Microsoft stellt die Dienste und Funktionen bereit, die resiliente Architekturen ermöglichen. Kunden müssen dennoch Resilienz gezielt entwerfen.

Hier sind Architekturmuster entscheidend:

• Circuit Breaker
• Lose Kopplung
• Asynchrone Verarbeitung
• Unabhängige Skalierung
• Mehrere Verfügbarkeitszonen
• Mehrere Regionen
• Failover-Mechanismen
• Überwachung
• Infrastructure as Code
• Getestete Wiederherstellungsverfahren

Microsoft stellt die Bausteine bereit. Die Architektur entscheidet, ob diese Bausteine tatsächlich ein resilientes System ergeben.

WARUM ASYNCHRONES DESIGN WICHTIG IST
Eines der stärksten Beispiele in der Folge stammt von Systemen, die vorhersehbare Lastspitzen erleben, etwa Steuerportale der Verwaltung.

Ein häufiges Designproblem entsteht, wenn jede Aktion von einer synchronen Backend-Operation abhängt. Der Nutzer klickt auf eine Schaltfläche. Das Frontend wartet auf das Backend. Das Backend wartet auf einen weiteren Dienst. Eine andere Abhängigkeit wird langsam. Schließlich ist das gesamte Nutzererlebnis betroffen.

Mike erklärt, warum lose gekoppelte Systeme oft widerstandsfähiger sind. Anstatt das Frontend auf jede Backend-Operation warten zu lassen, können Anwendungen Arbeit in Warteschlangen oder ereignisgesteuerte Systeme legen und Komponenten erlauben, Aufgaben unabhängig voneinander zu verarbeiten.

Das bringt mehrere Vorteile:

• Verschiedene Komponenten können unabhängig voneinander skaliert werden
• Ein Dienst kann ausfallen, ohne die gesamte Plattform zu beeinträchtigen
• Backends können Arbeit asynchron verarbeiten
• Lastspitzen lassen sich leichter abfangen
• Benutzerorientierte Komponenten sind weniger vom Timing des Backends abhängig
• Fehler lassen sich leichter isolieren

DER MYTHOS VON 100 PROZENT BETRIEBSZEIT
Ein weiteres zentrales Thema der Diskussion ist die Fixierung auf 100 Prozent Verfügbarkeit. Mike ist hier sehr klar: 100 Prozent Betriebszeit ist kein realistisches Architekturziel.

Eine Lösung besteht in der Regel aus mehreren Diensten. Jeder Dienst hat seine eigene SLA. Sobald mehrere Abhängigkeiten kombiniert werden, sinkt die