Moderne Webarchitekturen im Überblick

Moderne Webarchitekturen im Überblick

0:00 Willkommen zu diesem Seminar. Es geht um Architektur für moderne Web-Anwendungen — und ich sage gleich zu Beginn, was es nicht ist: eine Reise durch Frameworks. Wir werden zwar über Rendering, über APIs, über Kubernetes und über KI-Komponenten sprechen, aber immer mit derselben Frage im Hintergrund: Woran machen Sie fest, ob das für Ihr System die richtige Wahl ist?

0:22 Architektur ist am Ende eine Kette von Entscheidungen unter Unsicherheit. Manche davon korrigieren Sie in einer Woche, andere begleiten Sie fünf Jahre. Genau diese Unterscheidung zu treffen, ist die eigentliche Fähigkeit — und die üben wir hier.

Moderne Webarchitekturen im Überblick

0:37 Dieses erste Modul legt das Fundament für alles Weitere. Wir schauen zunächst, was aus dem Web in den letzten Jahren geworden ist — technisch, aber vor allem mit Blick darauf, welche Fragen dadurch neu entstanden sind. Danach geht es um Architektur als Entscheidungsprozess. Und Sie lernen das Referenzsystem kennen, das uns über das gesamte Seminar begleiten wird.

0:57 An ihm treffen wir in jedem Modul mindestens eine konkrete Entscheidung, damit am Ende kein Stapel Wissen steht, sondern eine zusammenhängende Architektur.

Vom World Wide Web zur verteilten Anwendungsplattform

1:06 Fangen wir mit einer Bestandsaufnahme an. Das Web war einmal ein System zum Austausch von Dokumenten. Davon ist heute wenig übrig. Was daraus geworden ist, verändert nicht nur die Technik, sondern die Art von Problemen, mit denen Sie es im Entwurf zu tun bekommen. Stellen Sie sich eine moderne Webanwendung nicht als Programm mit einer Oberfläche davor vor, sondern als ein Netz aus Orten, an denen Arbeit passiert.

1:31 Ein Stück davon läuft im Browser Ihrer Nutzer, ein Stück auf einem Knoten nahe bei ihnen, ein Stück in Ihren Diensten, ein Stück in Datenbanken und Fremdsystemen. Das klingt nach einer Beschreibung von Infrastruktur, ist aber eine Aussage über Ihre Fehlerfälle: Sobald Arbeit über Grenzen hinweg verteilt ist, gelten die Gesetze verteilter Systeme.

1:51 Teile fallen einzeln aus, Zustände laufen auseinander, jeder Sprung kostet Zeit. Das ist der Ausgangspunkt für alles, was danach kommt. Diese vier Ebenen sind bewusst übereinander gezeichnet, nicht nebeneinander. Jede Schicht ist ein eigener Laufzeitort mit eigenen Regeln — und jede Grenze dazwischen ist eine Stelle, an der etwas schiefgehen kann.

2:11 Interessant ist vor allem die Edge-Ebene: Sie ist in den letzten Jahren dazugekommen und verschiebt Entscheidungen, die früher eindeutig waren. Was am Rand zwischengespeichert werden kann, belastet Ihre Dienste nie. Was personalisiert ist, kann es nicht. Behalten Sie die Schichtung im Kopf — wir kommen in fast jedem Modul an eine Stelle zurück, an der die Frage lautet: Auf welcher Ebene lösen wir das?

2:34 Der eigentliche Bruch liegt nicht in der Technik, sondern in den Annahmen. In einem einzelnen Prozess ist ein Aufruf entweder erfolgreich oder er wirft einen Fehler. Über das Netz gibt es einen dritten Fall: Sie wissen es nicht. Die Antwort kann verloren gegangen sein, nachdem die andere Seite gehandelt hat. Genauso beim Zustand — in einem Prozess ist ein Wert einfach der Wert, verteilt ist er an verschiedenen Orten verschieden alt.

2:59 Und Betrieb, Beobachtbarkeit und Sicherheit hören auf, nachgelagerte Themen zu sein. Sie werden zu Entwurfsentscheidungen, weil man sie später nicht mehr sauber einbauen kann. Diese Tabelle löst ein Problem, das Sie aus Meetings kennen. Jemand sagt „Architektur", und die Runde diskutiert gleichzeitig über Modulschnitt, über Diensteaufteilung und darüber, ob man Kubernetes nimmt.

3:21 Das sind drei verschiedene Ebenen mit drei verschiedenen Entscheidungsgrundlagen — und solange sie durcheinandergehen, wird keine von ihnen entschieden. Der praktische Nutzen ist klein und sofort spürbar: Wenn Sie in einer Diskussion merken, dass die Ebene wechselt, sagen Sie es. Meistens stellt sich heraus, dass die untere Ebene nur deshalb so heiß diskutiert wird, weil die obere ungeklärt ist.

3:44 Es gibt einen einfachen Test dafür. Geben Sie zwei Teams dasselbe Framework und dieselbe Aufgabe — Sie bekommen zwei völlig verschiedene Systeme zurück. Das Framework beantwortet keine einzige der Fragen, die wirklich zählen: Wer ist für welche Fachlichkeit zuständig, wo verlaufen die Grenzen, wer darf wen aufrufen. Und umgekehrt überlebt ein guter fachlicher Schnitt jeden Technologiewechsel.

4:07 Das ist kein Argument gegen sorgfältige Technologiewahl — wir beschäftigen uns in Modul fünf ausführlich damit. Es ist ein Argument dafür, sie an die zweite Stelle zu setzen. Diese vier Fehler sehen unterschiedlich aus, haben aber dieselbe Wurzel: Es wird über die Lösung entschieden, bevor das Problem beschrieben ist. Besonders teuer ist der letzte Punkt.

4:28 Große Unternehmen veröffentlichen ihre Architekturen, und das ist verdienstvoll — aber diese Architekturen sind Antworten auf Probleme, die Sie wahrscheinlich nicht haben, entstanden unter Bedingungen, die bei Ihnen nicht gelten. Ein Vortrag zeigt Ihnen das Ergebnis, nie den Weg und nie die Kosten. Wenn Sie eine solche Vorlage übernehmen, übernehmen Sie eine Antwort ohne die zugehörige Frage.

4:51 Lernen Sie Kartenwerk kennen — unsere Beispielplattform für die nächsten zwei Tage. Tickets für regionale Veranstaltungen, also Konzerte, Lesungen, Stadtfeste. Der Grund für genau dieses Beispiel ist das Lastprofil: Beim Vorverkaufsstart kommen in wenigen Minuten Zehntausende, danach ist es über Tage ruhig. Dazu kommen Sitzplätze, die nur einmal verkauft werden dürfen, Bezahlvorgänge, eine Suche, und am Veranstaltungsabend Menschen mit dem Handy am Einlass.

5:18 Jedes dieser Merkmale wird in einem der Module zur entscheidenden Randbedingung. Am Ende des zweiten Tages entwerfen Sie dafür eine vollständige Zielarchitektur.

Architektur als Entscheidungsprozess

5:28 Damit zum Handwerk selbst. Wenn Architektur nicht die Auswahl von Technologien ist — was ist sie dann? Die ehrlichste Antwort: das Treffen und Begründen von Entscheidungen, die man später nur schwer zurücknehmen kann. Beachten Sie, was in dieser Definition nicht steht. Es steht dort nicht, dass Sie die beste Lösung finden sollen.

5:48 Die gibt es nicht — es gibt nur Lösungen, die zu Ihren Anforderungen, Ihrem Team und Ihrem Betriebsmodell passen, und solche, die das nicht tun. Entscheidend ist der zweite Teil des Satzes: nachvollziehbar bleiben. In zwei Jahren wird jemand vor Ihrer Architektur stehen und sich fragen, warum sie so aussieht. Wenn darauf niemand antworten kann, wird die Entscheidung entweder blind übernommen oder blind umgeworfen. Beides ist teuer.

6:14 Die Reihenfolge in dieser Kette ist der ganze Punkt. In der Praxis beginnt es nämlich fast immer in der Mitte: Jemand hat eine Lösung im Kopf und sucht rückwärts nach Gründen. Der Anlass am Anfang zwingt Sie zu der Frage, warum jetzt überhaupt entschieden werden muss — und erstaunlich oft lautet die ehrliche Antwort: Muss es nicht.

6:32 Das ist ein gutes Ergebnis, denn eine aufgeschobene Entscheidung kostet nichts und gewinnt Information. Und die Konsequenzen am Ende sind kein Anhängsel: Sie sind das, was Sie tatsächlich kaufen. Diese fünf Schritte sind kein Formular, sondern eine Denkreihenfolge. Zwei davon werden regelmäßig übersprungen. Der zweite: Annahmen benennen, auch die unbequemen — etwa dass das Team, das den Dienst betreiben soll, heute noch gar nicht existiert.

6:59 Und der dritte: mindestens zwei ernsthafte Alternativen. Wenn Sie nur eine Option ausarbeiten und dann begründen, warum sie gut ist, haben Sie nicht entschieden, sondern gerechtfertigt. Ein guter Test dafür: Könnte eine Kollegin anhand Ihrer Aufstellung zu einem anderen Ergebnis kommen? Wenn nicht, war es keine Entscheidung.

7:19 Diese Gegenüberstellung ist vielleicht das Nützlichste aus dem ganzen Modul, weil sie Ihnen sagt, wo Sie Ihre Zeit investieren. Links stehen Dinge, die Sie in einem Sprint ändern können. Dort ist langes Abwägen reine Verschwendung — entscheiden, ausprobieren, notfalls zurücknehmen. Rechts stehen Dinge, die Sie in drei Jahren noch begleiten: der fachliche Schnitt, die Frage, wem welche Daten gehören, ob Sie synchron oder über Ereignisse koppeln.

7:45 In der Praxis ist es leider oft umgekehrt: Über die Bibliothek wird wochenlang gestritten, und der Datenbesitz ergibt sich nebenbei aus einem Ticket. Hier steckt ein verbreitetes Missverständnis drin. Viele denken, sauberer Aufbau sei etwas, das man sich leistet, wenn Zeit da ist — als stünden Qualität und Tempo gegeneinander.

8:04 Das Gegenteil ist der Fall, und zwar früher, als die meisten vermuten: Der Aufwand für tragfähige Struktur rechnet sich in Wochen, nicht in Jahren. Der Grund ist einfach. Angesammelte Altlast wirkt wie Reibung. Sie zahlen sie bei jeder einzelnen folgenden Änderung, und Sie merken es nicht, weil es sich nach normalem Arbeiten anfühlt.

8:25 Die beiden letzten Punkte gehören zusammen und beschreiben dieselbe verdrehte Prioritätensetzung. Wochen für eine Bibliothek, ein Ticket für die Datenhoheit — das passiert nicht aus Nachlässigkeit, sondern weil die Bibliothekswahl sichtbar ist und die Datenhoheit nicht. Deshalb ist die Einteilung in reversibel und schwer reversibel so wertvoll: Sie macht sichtbar, was sonst unter dem Radar entschieden wird.

8:46 Im nächsten Modul schauen wir uns an, woher die Kriterien für solche Entscheidungen überhaupt kommen — nämlich aus den Anforderungen, die die Struktur verändern.