Die richtige Architektur
im Web

Buzzwords

Trade-Offs sind unvermeidlich!

Rahmenbedingungen
  • Ressourcen: Zeit, Geld, Motivation
  • Tools: Technologien, Know-How
  • Anspruch: Demo vs. Cash-Cow
  • Regeln: Schutzbedarf & Compliance
\(\to\)
\(\to\)
\(\to\)
\(\to\)
\(\to\)
\(\to\)
Priorisierung von Zielen
  • Geschwindigkeit
  • Sicherheit
  • Skalierung
  • Entwicklungszeit

Ein Beispiel

Die Ticketagentur

Nutzungsabsichten / Funktionales Minimum
  • Registrierung
  • Login
  • Events browsen
  • Tickets kaufen
  • Administration
  • [Angebot einstellen]
Datenobjekte/-ressourcen
  • Benutzer & Rollen (Client, Admin, [Vendor])
  • Events
  • Einzeltermine
  • Käufe
  • [Angebote]
  • [Zahlungsdienstleister]

Die klassische Serveranwendung

Anwendung vereint
  • Präsentation,
  • Geschäftslogik,
  • Infrastruktur (Auth, DB-Anbindung, etc.)
Modularisierung nach
  • Schichtenfunktionalität
  • Fachdomänen

Einschätzung des Klassikers

Vorteile
  • wenige und erprobte Technologien
    • kurze Entwicklungszeiten
    • wenige Kontextwechsel
    • wenig Spezifikation
  • wenige Abhängigkeiten
  • Code läuft in statischer & bekannter Umgebung
  • interner Datenfluss vertrauenswürdig
Nachteile
  • Diagnose: Monolith
  • Modularisierung erfordert Selbstdisziplin
  • wenig flexibel erweiterbar
  • wenig flexibel skalierbar
  • geschlossenes System

Alle wollen Wachstum

Und Mobile Apps, Zwei-Faktor-Authentifizierung, etc.

Offenheit, Flexibilität und Skalierung

  • Offene, dokumentierte Schnittstellen
  • Zerlegung und Spezialisierung von Komponenten
  • Maximierung von Unabhängigkeit und Zustandslosigkeit


Microservices!

Die Microservices

  • Separierung fachlicher Domains in dedizierte Anwendungen
  • API-Gateway als SPOC (ReverseProxy oder mit Zusatzlogik)
  • Möglich: Einbindung externer/bestehender Services (z.B. Keycloak)
  • Container/Cloud: Redundanz & horizontale Skalierung von Flaschenhälsen

Die Microservices

  • Separierung fachlicher Domains in dedizierte Anwendungen
  • API-Gateway als SPOC (ReverseProxy oder mit Zusatzlogik)
  • Möglich: Einbindung externer/bestehender Services (z.B. Keycloak)
  • Container/Cloud: Redundanz & horizontale Skalierung von Flaschenhälsen

Und die Daten?

  • Service-spezifische, nicht-lokale Datenablage (Zustandslosigkeit)
  • Klassisch relational, aufgabenbezogen NoSQL (z.B. MongoDB) oder Object Storage
  • Datenbanken skalieren deutlich schwerer als Microservices selbst:
    • vertikales Skalieren
    • Sharding/Clustering
    • Cloud-Datenbanken (CNCF Landscape)

Schnittstellen: REST

RessourceZugriffsmethoden
/usersGET, POST
/users/{name}GET, PUT, DELETE
/orders/GET, POST
/orders/{id}GET, PUT, DELETE
/events/GET, POST
/events/{id} GET, PUT, DELETE
/events/{id}/occurrences/GET, POST
/events/{id1}/occurrences/{id2}GET, PUT, DELETE


Formale Modellierung: OpenAPI und Swagger

Verlagerung von Logik auf Client-Seite

  • Client-Logik interagiert mit Ressourcen über REST-API
  • technisch z.B.
    • Single-Page-WebApp
    • Views für Kernfunktionen (Register, Login, Browsing, Kauf, Admin)
    • Frontend-Frameworks: Vue, Angular, React
  • Ausblick:
    • Progressive Web App
    • Native Apps

Beschränkung der Rolle des Webservers

  • Erstauslieferung der Web-App
  • Abruf statischer, binärer Informationen (Bilder, Videos, etc.)

Das ganze Bild

Ergebnis ist ein verteiltes System

  • Offenheit, Flexibilität, Skalierung sind erreicht, aber
  • neue Herausforderungen:
    • Sicherheit (Zugangskontrolle REST-API, Formatwandlungen, Vertrauensdomänen)
    • Wartbarkeit (#Komponenten, #Sprachen, #Werkzeuge, #Ausführungsumgebungen)
    • Kontrollierbarkeit (Logging)

Moderne Web-Anwendungen

  • ... sind gekommen um zu bleiben.
  • ... sind komplex durch ihre Architektur.

Approaches to handle complexity

(yet) more tools / automatisms
  • use formal modeling (e.g. OpenAPI)
  • Dev (automated tests, tree shaking)
  • DevOps (infrastructure as code, reuse)
  • DevSecOps (OWASP scanners, etc.)
  • be open
take only what you need
  • solve easy problems for yourself
  • use established solutions for hard ones
  • don't embrace hypes
  • minimize dependencies / technology stack
  • write good, modular code

And sometimes, a simpler approach is the better one.

Thank You!

Questions?