Azure-Architektur, die der Realität standhält — mit Mike Martin [MVP]

Azure-Architektur wirkt einfach, solange alles funktioniert. Die echte Bewährungsprobe beginnt, wenn Abhängigkeiten ausfallen, Regionen nicht verfügbar werden, Lastspitzen auftreten, Annahmen sich als falsch erweisen, sich Anforderungen ä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, gar nicht neu sind. DNS fällt immer noch 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 Ausmaß an Komplexität, das wir um diese Probleme herum aufbauen.

VON 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 lautet: 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, Hybrid-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
• Netzwerk
• 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 Aufgabe des Architekten ist es, die gesamte Lösung zu verstehen und die einfachste Architektur zu wählen, die dennoch die realen Anforderungen erfüllt.

MIT DEN GESCHÄFTSANFORDERUNGEN BEGINNEN, NICHT MIT AZURE-DIENSTEN
Eine der wichtigsten Lehren dieser Folge ist einfach: Beginnen Sie nicht mit der Technologie.Bevor Sie sich für Azure Kubernetes Service, App Service, Azure Functions, Container, Service Bus oder eine andere Plattform entscheiden, sollten Teams zunächst verstehen, was die Lösung tatsächlich leisten muss.Fragen, die zu klären sind:

• Ist die Anwendung intern oder kundenorientiert?
• Wie viele Nutzer werden davon abhängen?
• 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 ausfällt?
• Wer ist betroffen?
• Welcher Umfang an operativem Support ist erforderlich?

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, ihre eigentliche Bedeutung ist jedoch 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 unkritisches Monitoring kann mehrere Stunden Ausfallzeit oder Datenverlust tolerieren. Ein System, das Ersthelfer, Finanzprozesse, Handel oder kritische Infrastruktur unterstützt, erfordert möglicherweise eine Wiederherstellung innerhalb von Minuten.Der wichtige Punkt ist, dass diese Werte nicht vom Architekten erfunden werden sollten. Sie müssen 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 kann eine weitere Komponente bereithalten, die übernimmt, wenn die primäre ausfällt.Ein resilientes System ist darauf ausgelegt, Probleme abzufangen, weiter zu funktionieren, sich geordnet zu erholen und in den Normalbetrieb zurückzukehren, ohne vollständig zusammenzubrechen.Dieser Unterschied ist wichtig.Eine Anwendung kann technisch verfügbar sein und dennoch eine schlechte Nutzererfahrung 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 Störungen, defekten Abhängigkeiten, betrieblichen Vorfällen und der Wiederherstellung nach dem Vorfall umgehen kann.

AZURE MACHT IHRE ANWENDUNG NICHT AUTOMATISCH RESILIENT
Eine gefährliche Annahme ist, dass Anwendungen auf Azure automatisch deren Resilienz erben, weil Azure selbst hochverfügbar ist.Das trifft nicht zu.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 liefert die Bausteine. 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 mit vorhersehbaren Lastspitzen, etwa Steuerportalen der Verwaltung.Ein häufiges Designproblem entsteht, wenn jede Aktion von einer synchronen Backend-Operation abhängt.Der Nutzer klickt auf einen Button. Das Frontend wartet auf das Backend. Das Backend wartet auf einen weiteren Dienst. Eine andere Abhängigkeit wird langsamer. Irgendwann 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 lahmzulegen
• Backends können Arbeit asynchron verarbeiten
• Lastspitzen lassen sich leichter abfangen
• Nutzerorientierte Komponenten hängen weniger vom Timing des Backends ab
• Fehler lassen sich leichter isolieren

DER MYTHOS DER 100-PROZENT-VERFÜGBARKEIT
Ein weiteres zentrales Thema der Diskussion ist die Besessenheit von 100 Prozent Verfügbarkeit.Mike ist klar: 100 Prozent Betriebszeit ist kein realistisches Architekturziel.Eine Lösung besteht in der Regel aus mehreren Diensten.Jeder Dienst hat sein eigenes SLA.Sobald mehrere Abhängigkeiten kombiniert werden, sinkt die