Azure को असली दुनिया में टिकाऊ बनाना — Mike Martin [MVP] के साथ

Azure-Architektur wirkt einfach, solange alles funktioniert.Die eigentliche Bewährungsprobe beginnt, wenn Abhängigkeiten ausfallen, Regionen nicht verfügbar sind, Traffic-Spitzen auftreten, Annahmen sich als falsch erweisen, sich Anforderungen ändern und irgendwann jemand die unbequeme Frage stellt: Warum haben wir es ü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 bricht immer noch aus, IP-Abhängigkeiten sind nach wie vor wichtig, Kosten werden weiterhin zum Problem, Integrationen schlagen fehl und Abhängigkeiten verschwinden im ungünstigsten Moment.Was sich verändert hat, ist das Ausmaß der Komplexität, die 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 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 nun 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 widerstandsfähig 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 verursachen.Die Rolle des Architekten besteht darin, die gesamte Lösung zu verstehen und die einfachste Architektur zu wählen, die die tatsächlichen Anforderungen erfüllt.

MIT DEN 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 zwischen Azure Kubernetes Service, App Service, Azure Functions, Containern, Service Bus oder einer anderen Plattform entscheiden, sollten sie zunächst verstehen, was die Lösung tatsächlich leisten muss.Zu klärende Fragen:

• Ist sie intern oder kundenorientiert?
• Wie viele Benutzer werden von ihr 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 verschwindet?
• Wer ist betroffen?
• Welcher Umfang an betrieblicher Unterstützung ist erforderlich?

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

RTO UND RPO OHNE FACHJARGON
RTO und RPO werden oft als technische Akronyme besprochen, ihre eigentliche Bedeutung ist aber 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 Ausfall 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 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 kann eine andere Komponente bereithalten, die übernimmt, wenn die primäre ausfällt.Ein resilientes System ist dafür ausgelegt, Probleme abzufangen, weiter zu funktionieren, sich geordnet zu erholen und in den Normalbetrieb zurückzukehren, ohne vollständig zusammenzubrechen.Diese Unterscheidung 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, betrieblichen Vorfällen und der Wiederherstellung nach Abklingen des Vorfalls umgehen kann.

AZURE MACHT IHRE ANWENDUNG NICHT AUTOMATISCH RESILIENT
Eine gefährliche Annahme ist, dass Azure selbst hochverfügbar ist und deshalb jede Anwendung auf Azure automatisch von dieser Resilienz profitiert.Das stimmt nicht.Microsoft stellt die Dienste und Fähigkeiten bereit, die resiliente Architekturen ermöglichen.Kunden müssen Resilienz trotzdem selbst 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, die vorhersehbare Traffic-Spitzen erleben, etwa Steuerportalen der Regierung.Ein häufiges Designproblem entsteht, wenn jede Aktion von einer synchronen Backend-Operation abhängt.Der Benutzer klickt auf einen Button.Das Frontend wartet auf das Backend.Das Backend wartet auf einen anderen Dienst.Eine weitere Abhängigkeit wird langsamer, und schließlich ist die gesamte Benutzererfahrung 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 Aufgaben unabhängig voneinander verarbeiten lassen.Das bringt mehrere Vorteile:

• Verschiedene Komponenten können unabhängig voneinander skaliert werden
• Ein Dienst kann ausfallen, ohne die gesamte Plattform mitzureißen
• Backends können Arbeit asynchron verarbeiten
• Traffic-Spitzen lassen sich leichter abfangen
• Benutzerorientierte Komponenten werden weniger vom Timing des Backends abhängig
• Fehler lassen sich leichter isolieren

DER MYTHOS DER 100-PROZENT-VERFÜGBARKEIT
Ein weiteres zentrales Thema der Diskussion ist die Besessenheit von 100-prozentiger Verfügbarkeit.Mike ist sehr deutlich: 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