06 Quiz: Softwarearchitektur

Twitters Fail Whale illustrierte, was passiert, wenn die Architektur eines Systems seinen Erfolg nicht unterstützen kann. Ihre monolithische Ruby on Rails-Anwendung konnte nicht skaliert werden, um das schnelle Wachstum der Benutzer zu bewältigen. Das Problem waren nicht die Entwickler, die Anzahl der Server oder Ruby selbst — es war die architektonische Entscheidung, alles als eine eng gekoppelte Anwendung zu bauen, die nicht unabhängig skaliert werden konnte.

Softwarearchitektur beschreibt, wie ein System als eine Menge kommunizierender Komponenten organisiert ist und wie sich diese Komponenten verhalten und interagieren. Sie beantwortet Fragen wie: Wie werden Verantwortlichkeiten verteilt? Wie kommunizieren Komponenten? Wie wird das System bereitgestellt? Was passiert, wenn eine Komponente ausfällt?

Architektonisches Design ist grundlegend kreativ, weil es Kompromisse beinhaltet, die vom Typ des zu entwickelnden Systems, dem Hintergrund und der Erfahrung des Architekten und den spezifischen Anforderungen des Projekts abhängen. Anders als Algorithmen mit beweisbar optimalen Lösungen hat Architektur keine “richtige” Antwort — es geht darum, informierte Entscheidungen unter Berücksichtigung von Einschränkungen und Zielen zu treffen.

Die Vorlesung identifiziert 8 zentrale architektonische Fragen: Templates, Hardware-Verteilung, Muster, grundlegende Strukturierung, Komponenten-Zerlegung, Betriebskontrolle, NFR-Organisation und Dokumentation. Die Präferenzen einzelner Entwickler für Programmiersprachen sind persönliche Entscheidungen, keine architektonischen Entscheidungen. Architektur befasst sich mit systemweiten Belangen, nicht mit individuellen Coding-Präferenzen.

Bei 100 km/h legt ein Auto in 100ms ungefähr 2,8 Meter zurück. Für sicherheitskritische Funktionen wie Lenken und Bremsen muss das Steuerungssystem schnell genug reagieren, dass Verzögerungen nicht wahrnehmbar und sicher sind. Bei 1 kHz (1ms-Zyklen) legt das Auto nur 2,8 Zentimeter zwischen den Steuerungsaktionen zurück, was einen reibungslosen und sicheren Betrieb ermöglicht.

Verteidigung in der Tiefe verwendet eine Schichtenarchitektur, bei der jede Schicht zusätzliche Sicherheit bietet. Zum Beispiel: WAF (Web Application Firewall) → API Gateway → Geschäftslogik → Datenzugriff → Datenbank. Wenn ein Angreifer eine Schicht durchbricht, steht er vor weiteren Barrieren. Dies ist widerstandsfähiger als sich auf eine einzige Sicherheitsmaßnahme zu verlassen.

99,99% Verfügbarkeit (“vier Neunen”) erlaubt etwa 52,6 Minuten Ausfallzeit pro Jahr. Vergleiche: 99% = 3,65 Tage, 99,9% = 8,76 Stunden, 99,999% = 5,26 Minuten. Jede zusätzliche “Neun” erfordert exponentiell ausgefeiltere Architektur — mehrere Rechenzentren, keine Single Points of Failure und Active-Active-Replikation.

Netflix erreicht 99,99% Verfügbarkeit durch mehrere Strategien: Deployment über mehrere AWS-Regionen in Active-Active-Konfiguration, Verwendung von Chaos Engineering (Chaos Monkey), um absichtlich Fehler einzuschleusen und Widerstandsfähigkeit zu verifizieren, und Aufbau zustandsloser Services, bei denen kein einzelner Service kritische Zustände hält. Das bedeutet, dass jede Instanz jede Anfrage bearbeiten kann, was Failover nahtlos macht.

Trennung der Zuständigkeiten bedeutet, verschiedene Verantwortlichkeiten zu isolieren, sodass Änderungen in einem Bereich nicht durch das gesamte System wellenartig wirken. Wenn du änderst, wie Daten gespeichert werden, solltest du nicht die UI ändern müssen. Wenn du eine Berechnung korrigierst, solltest du nicht die Authentifizierung kaputt machen. Diese Isolation macht das System einfacher zu verstehen, zu testen und zu ändern — kritisch, weil 80% der Softwarekosten Wartung sind.

Performance-optimierte Architekturen opfern oft Modularität und Testbarkeit. Eng gekoppelte, monolithische Komponenten minimieren Kommunikationsaufwand und sind schnell, aber sie sind schwer zu verstehen, zu testen und zu ändern. Die Vorlesung betont, Performance-Optimierung nur dann zu wählen, wenn die Anforderungen es wirklich erfordern, nicht als Standard.

Die Entwicklungssicht zeigt, wie Code in Pakete und Module organisiert ist. Sie beantwortet Fragen wie “Wo befindet sich diese Funktionalität in der Codebasis?” und hilft bei der Koordination der Entwicklung (“Anna arbeitet an services/, Ben arbeitet an presentation/”). Die Logische Sicht zeigt Domänenabstraktionen, die Prozesssicht zeigt Laufzeitverhalten, und die Physische Sicht zeigt Hardware-Deployment.

Jede Sicht im 4+1-Modell dient verschiedenen Stakeholdern: Logische Sicht → Entwickler, Domänenexperten. Prozesssicht → Performance-Ingenieure, Integratoren. Entwicklungssicht → Programmierer, Projektmanager. Physische Sicht → System-Ingenieure, Betrieb. Szenarien (+1) → alle Stakeholder. Die Physische Sicht befasst sich mit Deployment-Fragen wie Hardware, Netzwerke und Skalierung.