Der Spickzettel zum Seminar Architektur und Technologien für moderne Web-Anwendungen, zweiter Teil: der Zuschnitt des Systems und alles, was danach kommt — Stile, Bereitstellung, Sicherheit, Resilienz, Beobachtbarkeit, KI-Komponenten und Dokumentation. Treiber, Rendering, Schichten, Schnittstellen und Daten stehen auf dem ersten Blatt, Bausteine.
Für die genannten Standards ist jeweils die Originalquelle maßgeblich — OWASP Top 10:2025, SLSA, OpenTelemetry, C4 und arc42. Dieses Blatt ist die Auswahl, nicht die Referenz.
Architekturstile und ihre Domänen
Ein Stil ist eine Menge von Einschränkungen. Wer sie nicht einhält, bekommt die Eigenschaften nicht — nur die Kosten.
| Stil | Abhängigkeiten | Passt zu |
|---|---|---|
| N-Tier | waagerechte Schichten | klassische Fachlichkeit, seltene Änderungen |
| Web-Queue-Worker | Vorderseite und Arbeiter, entkoppelt | einfache Domäne mit schweren Aufgaben |
| Microservices | fachlich geschnittene Dienste über APIs | komplizierte Domäne, häufige Änderungen |
| Event-driven | Erzeuger und Verbraucher, entkoppelt | Echtzeitnähe, hohe Ereignisraten |
| Serverless | einzelne Funktionen, ereignisausgelöst | schwankende Last, kurze Aufgaben |
Der Monolith hat Stärken, die in der Debatte regelmäßig fehlen — und Nachteile, die erst mit Größe und Teamzahl auftreten.
| Stärke | Preis |
|---|---|
| Aufrufe sind lokal und damit effizient | ein Technologiestapel für alles |
| Abläufe als ACID-Transaktion möglich | Teams arbeiten an derselben Codebasis |
| Zusammenhänge leichter nachzuvollziehen | die Auslieferungskette wird mit der Größe langsam |
| keine Kopplung über Netzgrenzen | Teilbereiche lassen sich nicht getrennt betreiben |
| Kriterium | Spricht für Monolith | Spricht für Dienste |
|---|---|---|
| Domäne | überschaubar, stabil | groß, in Bewegung |
| Teams | eines bis zwei | mehrere, eigenständig |
| Liefertakt | gemeinsam planbar | unabhängig nötig |
| Skalierung | gleichmäßig | sehr ungleich verteilt |
| Verfügbarkeit | einheitlich | je Teil verschieden |
| Betriebsreife | im Aufbau | belastbar vorhanden |
Modul: Architekturstile und Systemzuschnitt
Bereitstellung, Compute und Plattform
| Kandidat | Wann er in Frage kommt |
|---|---|
| Virtuelle Maschinen | Bestand wird unverändert übernommen, volle Kontrolle nötig |
| Verwaltete Anwendungsplattform | Webanwendung ohne Anspruch auf Maschinenzugriff |
| Verwalteter Container-Dienst | Container ja, Kubernetes-Steuerebene nicht gebraucht |
| Kubernetes | Zugriff auf Kubernetes-API und Steuerebene wird benötigt |
| Funktionen | ereignisgetriebene, kurze Aufgaben, stark schwankende Last |
Der Zielkonflikt ist immer derselbe: IaaS gibt die meiste Kontrolle und verlangt den meisten Betrieb, FaaS umgekehrt.
| Modell | Wofür es gewählt wird |
|---|---|
| Public Cloud | Elastizität, verwaltete Dienste, kein eigener Betrieb |
| Private Cloud | Datenschutz, Regulierung, vorhandene Investitionen |
| Hybrid | Übergang, Sonderfälle, Daten müssen im Haus bleiben |
| Multi-Cloud | Verhandlungsposition, Ausfallszenarien, Kundenauflagen |
Eine Plattform ist ein Produkt mit Nutzern — und wird als solches gemessen.
| Ebene | Kennzahl |
|---|---|
| Nutzerzufriedenheit | Weiterempfehlung, Zahl aktiver Nutzer |
| Organisatorische Effizienz | Wartezeit auf angeforderte Ressourcen |
| Lieferfähigkeit | Auslieferungsfrequenz, Durchlaufzeit, Wiederherstellzeit, Fehlerrate |
Modul: Cloud-native Architekturen und Plattformen
OWASP Top 10:2025 und ASVS
Ein Bewusstseinsdokument, kein Prüfkatalog: Die Reihenfolge ist datengetrieben und beschreibt die Verbreitung, nicht Ihr Risiko.
| Kennung | Kategorie |
|---|---|
| A01:2025 | Broken Access Control |
| A02:2025 | Security Misconfiguration |
| A03:2025 | Software Supply Chain Failures |
| A04:2025 | Cryptographic Failures |
| A05:2025 | Injection |
| A06:2025 | Insecure Design |
| A07:2025 | Authentication Failures |
| A08:2025 | Software or Data Integrity Failures |
| A09:2025 | Security Logging and Alerting Failures |
| A10:2025 | Mishandling of Exceptional Conditions |
Der überprüfbare Gegenpart ist der Application Security Verification Standard. Version 5.0.0 ist eine Umstrukturierung: 17 Kapitel, 345 Anforderungen, durchgängig neu nummeriert, drei Prüfstufen — die meisten Anwendungen zielen auf Stufe 2.
Modul: Security, Resilienz und Observability
SLSA Build Track
Provenance ist der dokumentierte Nachweis, wie ein Artefakt entstanden ist. SLSA trennt einen Build Track vom Source Track für die Quellcodeseite.
| Stufe | Kernanforderung |
|---|---|
| Build L0 | keine Garantien |
| Build L1 | Provenance existiert und zeigt, wie gebaut wurde |
| Build L2 | die Bauplattform erzeugt und signiert die Provenance selbst |
| Build L3 | gehärtete Bauplattform — Läufe isoliert, Signaturschlüssel unerreichbar |
Ab L2 schützt die Signatur vor nachträglicher Manipulation, ab L3 beeinflusst kein Bauschritt den nächsten.
Modul: Security, Resilienz und Observability
Circuit Breaker und Resilienzmuster
| Zustand | Verhalten |
|---|---|
| Closed | Aufrufe gehen durch, Fehler werden gezählt, Schwelle öffnet den Schalter |
| Open | Aufrufe scheitern sofort, eine Zeitsperre läuft |
| Half-Open | begrenzt viele Versuche; Erfolg schließt, ein Fehlschlag öffnet erneut |
Retry und Circuit Breaker lösen Verschiedenes: Retry erwartet, dass es beim nächsten Mal klappt; der Schalter verhindert Aufrufe, die voraussichtlich scheitern. Kombiniert wird über den Schalter wiederholt, nicht gegen ihn.
| Mittel | Wirkung |
|---|---|
| Bulkheads | trennen Ressourcen, damit ein Bereich den anderen nicht aufzehrt |
| Rate Limiting | begrenzt die Aufrufrate je Aufrufer |
| Load Shedding | wirft Last ab, bevor das System unter ihr zusammenbricht |
| Graceful Degradation | liefert eine kleinere Antwort statt gar keiner |
| Health Checks | machen Erholung überhaupt planbar |
Modul: Security, Resilienz und Observability
OpenTelemetry-Signale
| Signal | Bedeutung |
|---|---|
| Traces | Der Weg einer Anfrage durch die Anwendung |
| Metrics | Eine zur Laufzeit erfasste Messung |
| Logs | Die Aufzeichnung eines Ereignisses |
| Baggage | Kontextinformation, die zwischen Signalen weitergereicht wird |
| Profiles | Aufzeichnung des Ressourcenverbrauchs auf Codeebene |
Context Propagation ist die Grundlage verteilter Ablaufverfolgung: Der Context
trägt die Kennungen, ein Propagator serialisiert ihn beim Senden. Standard ist
W3C TraceContext mit dem Header traceparent — reißt eine Spur ab, fehlt meist
genau er.
Modul: Security, Resilienz und Observability
RAG, Agenten und ihre Risiken
Der Zugriff aufs Modell folgt einem von zwei Mustern: cloudnah (direkt, tief integriert, neue Fähigkeiten sofort) oder über ein Gateway (einheitliche Schnittstelle, zentrale Richtlinien, gemeinsame Kostenverfolgung).
| Abrufart | Wofür sie taugt |
|---|---|
| Stichwortsuche | exakte Begriffe, Bezeichner, Codes |
| Semantische Suche | Bedeutungsnähe statt Wortgleichheit |
| Vektorsuche | Ähnlichkeit über Einbettungen |
| Hybride Suche | Stichwort und Vektor kombiniert, oft mit Neubewertung |
Agentic Retrieval zerlegt eine komplexe Frage in mehrere Teilanfragen, führt sie parallel aus und liefert strukturierte Grounding Data samt Belegen zurück.
| Risiko | Gegenmaßnahme |
|---|---|
| Indirekte Prompt Injection | abgerufene Inhalte als Daten behandeln, nicht als Weisung |
| Datenabfluss über Antworten | Rechtefilter beim Abrufen, Prüfung der Rückgaben |
| Übermäßige Berechtigungen | eigene Identität je Agent, engste nötige Rechte |
| Unsichere Werkzeugaufrufe | Argumente prüfen, Aufrufe abfangen und filtern |
| Anbieterabhängigkeit | Abstraktion des Zugriffs, benannte Rückfallebene |
Assistent, Workflow und Agent unterscheidet die Autonomie, nicht das Modell. Groundedness misst die Genauigkeit einer Antwort, Vollständigkeit ihre Abdeckung — zwei Maße, nicht eines.
Modul: KI-erweiterte und agentische Webanwendungen
C4 und arc42
C4 ordnet Diagramme in vier Abstraktionsebenen; ergänzend gibt es System-Landscape-, Dynamic- und Deployment-Diagramme.
| Ebene | Zeigt | Für wen |
|---|---|---|
| System Context | das System und seine Umwelt | alle, auch fachliche Rollen |
| Container | ausführbare Einheiten und Datenspeicher | Technik, Betrieb, Architektur |
| Component | Bausteine innerhalb eines Containers | Entwicklungsteam des Containers |
| Code | Klassen und Strukturen | selten nötig, meist generiert |
Ein Container ist etwas, das läuft — kein Ordner und kein Modul.
| Abschnitt | Inhalt |
|---|---|
| 1 Einführung und Ziele | Grundanforderungen, besonders die Qualitätsziele |
| 2 Randbedingungen | Vorgaben und externe Einschränkungen |
| 3 Kontextabgrenzung | Nachbarsysteme und Schnittstellen |
| 4 Lösungsstrategie | Kernideen und Lösungsansätze |
| 5 Bausteinsicht | Struktur des Quellcodes und die Modularisierung |
| 6 Laufzeitsicht | wichtige Abläufe zur Laufzeit |
| 7 Verteilungssicht | Hardware, Infrastruktur, Auslieferung |
| 8 Querschnittliche Konzepte | wiederkehrende Muster und Technikentscheidungen |
| 9 Architekturentscheidungen | wichtige Entscheidungen, sofern nicht anderswo beschrieben |
Es folgen 10 Qualitätsanforderungen (Qualitätsbaum und -szenarien), 11 Risiken und technische Schulden sowie 12 Glossar. Architecture Decision Records halten je eine Entscheidung mit Begründung, Abwägungen und Konsequenzen fest; verbreitete Formate sind Nygard, Y-Statement und MADR, gesammelt in einem Decision Log.
Modul: Architektur dokumentieren und weiterentwickeln
Typische Fallen
- Geschnitten wird nach technischen Schichten. Ein Dienst je Schicht ergibt einen verteilten Schichtmonolith, keine Microservice-Architektur.
- Der Distributed Monolith. Getrennte Dienste, gemeinsame Auslieferung, gemeinsame Datenbank — volle Verteilungskosten bei voller Kopplung.
- Kubernetes für drei Dienste. Clusterpflege, Aktualisierungen und Absicherung bleiben Ihre Aufgabe, auch bei einem verwalteten Angebot.
- Canary ohne Abbruchkennzahl. Ohne messbares Signal ist es ein langsames Rollout mit besserem Namen.
- Das Rollback scheitert an der Datenbankmigration. Wer zurück können will, muss abwärtsverträglich migrieren.
- Die Top 10 als Prüfliste. Sie ersetzen kein Bedrohungsmodell — Insecure Design findet ohnehin kein Werkzeug.
- Stückliste erzeugt, nie ausgewertet. Dasselbe gilt für Signaturen, die beim Einspielen niemand prüft.
- Wiederholungen auf jeder Ebene. Drei Ebenen mit je drei Versuchen sind siebenundzwanzig Aufrufe für eine Anfrage.
- Die Spur endet an der Warteschlange. Der Kontext muss über jede Grenze weitergereicht werden, auch über Nachrichten.
- Die Gegenmaßnahme ist ein Satz im Prompt. Eine Bitte an das Modell ist keine Prüfung im System.
- Fitness Functions definiert, laufen aber nicht im Bauprozess. Dann sind es Absichtserklärungen.
Dieses Thema als Schulung für Ihr Team
Dieser Beitrag erklärt das Thema. Damit Ihr Team es danach auch anwendet, gibt es Architektur und Technologien für moderne Web-Anwendungen als Schulung — an Ihrem eigenen Code, mit den Fragen, die ein Text nicht beantwortet. Sie wählen die Module, wir bauen daraus ein Programm.
2 Tage·ab 900 EUR netto pro Tag (bis 3 Teilnehmende) ·Termin nach Vereinbarung
Als Team-Schulung anfragenZum Seminar Architektur und Technologien für moderne Web-Anwendungen →