Exkurs

Microservices

Microservices

• Architekturkonzept
  • Trade-Offs
  • Aktive Bewertung notwendig

Microservices > Motivation

Unabhängige Entwicklung

• Kommunikationsbeziehungen in Teams (n(n-1)/2)
  • Teams skalieren nicht linear
• Ziel: Kleine Teams (7-10 Personen)
• Gilt genauso für andere Kommunikationsbeziehungen zwischen
  • Teams
  • Systemen

Microservices > Motivation

Unabhängiges Deployment

• Features können schneller und unabhängig ausgeliefert werden
  • In agilen Kontexten interessant (MVPs, ...)

Microservices > Motivation

Verteilung des Systems auf viele physische Knoten

• Lastverteilung
• Verteilung auf viele Rechenzentren
  • Ausfallsicherheit
  • Latenzverbesserung (dichter am Nutzer)

Microservices > Motivation

Verteilung des Systems auf kleine unabhängige Einheiten

• Skaliertung für Lastspitzen optimieren (Cloud-Abrechnungsmodelle)

Microservices > Motivation

Technologistack kann passend zur Aufgabe gewählt werden

• Bessere Anpassung an unterschiedliche Aufgaben
• Größerer Kandidatenpool durch mehr System-Divergenz

Microservices > Motivation

Im Monolithen ist alles @&#$*

Jimmy's Law

A broken, dysfunctional organisation driven by meeting unhealthy goals and metrics will produce broken, dysfunctional systems.

Im Monolithen ist alles @&#$*

Microservice won't fix it

... sie machen es nur schlimmer

Microservices

Nachteile

• Verteiltes System
  • Netzwerkschnittstellen führen zu Latenzen und Mehraufwand bei Fehlerbehandlung
  • Ausfallwahrscheinlichkeit steigt
  • Fehlersuche deutlich komplexer
• Verwaltung und Betrieb vieler unabhängiger Systeme aufwändiger
• Teststrategie muss angepasst werden
• ...

Voraussetzungen

• Fachliches Design des Systems
  • Bounded Contexts
  • Teams/Systeme um fachliche Entitäten gruppieren
    • "Do one thing well"
• Die Organisation muss sich mitentwickeln!

Micro-Frontends

Im Frontend?

• Eine Codebase
• Ein Technologie-Stack
• Eine Release-Pipeline
• Manchmal: zentrales API Gateway

Micro-Frontends > Motivation

Organisatorische Gründe

• Wie bei μ-Services
• Vollständige Ownership über die Fachlichkeit
  • Frontend-for-Backend
  • MVPs

Micro-Frontends > Motivation

Schneller Wandel der Technologien

• Frameworks laufen schneller aus
• Nicht jedes Update kann in der ganzen Anwendung gleichzeitig umgesetzt werden
  • Mehrere Versionen/Technologien müssen parallel unterstützt werden
• Nicht als Selbstzweck: Nicht alles MUSS auch eingebaut werden

Micro-Frontends > Motivation

Migrationsstategie

• Stückweise Zerlegung eines (UI-)Monolithen (JSF, JSP, PHP, Rails, ...) in Verticals
  • Analog zu den Backend-Services

Micro-Frontends > Herausforderungen

Einheitliches Design

• Gleicher Stiel
• Gemeinsame Elemente
  • Navigation
  • Struktur der Seite
  • Footer

Micro-Frontends > Herausforderungen

Schnitt

• Nicht durch die Seiten-Struktur vorgeben lassen
• DDD-Entities ggf. nicht der richtige Schnitt
  • Eher Fähigkeiten:
    • Suche
    • Produkt-Details
    • Warenkorb
    • Checkout
• Sehr wichtig, aber nicht Thema dieses Vortrags

Micro-Frontends > Herausforderungen

Einheitliche Konzepte

• Konzepte sollte durchgängig verwendet werden
• Bedienelemente sollten gleich funktionieren
• Zusammenfassung:
  • Detaillierte Style-Guides
  • Wenig geteilter Code

Micro-Frontends > Herausforderungen

Simultane Änderung an mehreren Positionen

• Anzahländerung, direkt beim Öffnen einer Nachricht
• Aktualisierung des Warenkorb-Icons
• Themenbereich: Kommunikation im Client

Micro-Frontends > Herausforderungen

Integration von unterschiedlichen Webanwendungen

• Initiale Laden
  • Zeit
  • Flackern
  • Größe
• Konflikte bei JavaScript und CSS
  • Isolation
• Durchsuchbarkeit (SEO)
• Themenbereich: Integration auf Makro-Ebene

Server Side UI Integration

UI Integration

Server-Side

• ESI und SSI sind etabliert
• Optimierte Ergebnisse für Suchmaschinen
• Optimierung für den initialen Aufruf
  • Ggf. Nachladen von weiteren Daten
    • Größe
    • Kann nicht schnell genug bezogen werden
• Bekannt bei Inhaltsbasierten Seiten (Shops, News, ...)

UI Integration

Server-Side

• Für große öffentliche Seiten mit einfachen Anforderungen an die Bedienung
• Web 1.0
  • Erweiterungen für bessere UX müssen erstellt werden
  • Nicht geeignet für Backoffice Anwendungen mit Desktop-Bedienung

Client Side UI Integration

Client Side UI Integration

Idee

• Laden mehrerer Anwendungen im Browser
• Verwendung von Links und URIs
• Jedes System hat sein eigenes Frontend
• Kommunikation der Komponenten im Browser untereinander

i-Frames

i-Frames

• 1996 von Netscape eingeführt
• Anzeige mehrerer kompletter Seiten auf einer Seite
  • Integration Einbettung bestehender Anwendungen ohne Anpassung
  • Eckig
• Sehr starke Isolation auf einer sichtbaren Seite
  • Kommunikationskanäle lassen sich allerdings aufbauen
• Wird z.B. bei der Spotify-App genutzt

i-Frames

Zusammenfassung

• Isolation
• Größenangabe und Skalierung
• Browser Support in Zukunft unklar

Generic HAL Browser

Generic HAL Browser

IDEE

• Browser über REST-Ressources
• Aktionen und Links werden Anhand von HAL-Metadaten erzeugt
• Anpassungen an Client nur, falls neue Link-Typen unterstützt werden müssen

Generic HAL Browser

Bewertung

• Sehr hohe Autonomie der Teams
• Serverseitig guter Support
• SEO?
• Kein öffentlicher Client-Technologiestack verfügbar
• Wenig Freiheitsgrade beim UI
• Schlechte UX
• Konzeptionell kein Offline-Mode

Ressource-ORIENTED CLIENT ARCHITECTURE

(ROCA)

ROCA

Resource orientated client architecture

• UI muss in Ressourcen gedacht werden

ROCA

Idee

• Mehrere Dienste (Suche, Produkte, Warenkorb, Vorschläge, ...)
• Geteilte Anteile (Navigation, Footer, ...)
• Suche liefert Liste mit Links auf Ergebnisse
• Im Client werden die Links gegen den Teaser ausgetauscht

ROCA > Prinzipien

Server

• REST-Prinzipien
  • Jede Ressource hat eine URI
• Alle Logik existiert nur auf dem Server
• HTTP als Transport-Layer
• Links für weitere Informationen
• Unterstützung für alternative Clients
• Sessions and Cookies nur für CSRF und Authentication
• Back und Reload müssen wie erwartet funktionieren

ROCA > Prinzipien

Client

• Semantisches HTML ohne Layout Informationen
• CSS für Formatierung und Layout
• JavaScript nur unobtrusively
• Soll auch ohne JavaScript funktionieren
  • Mit Einschränkungen bei der UX
• Keine Redundanz bei der Code auf Client- und Server-Seite

ROCA

Zusammenfassung

• Relativ einfaches Konzept
• Sehr hohe Autonomie der Teams
• Langfristig wartbar
• Nutzung ohne JavaScript möglich

ROCA

Zusammenfassung

• Ggf. Optimierung für Durchsuchbarkeit notwendig
• Nur Konzept
  • Kein fertiger Technologiestack verfügbar
  • Einzelne Lösungen in Beispielen 1, 2
• Grenzen beim UX durch Server-Requests
• Konzeptionell kein Offline-Mode

SPAs

• Angular
• React
• Vue

SPA-Frameworks

• Desktopartike Anwendungen im Browser
• Sehr breite UI und UX Unterstützung
• Offline-Fähigkeiten
• Durchdachte Komponentenmodelle
• Zustandsmanagement für sehr große Anwendungen (Flux-Pattern)
• Technische Unterstützung für sehr große Anwendungen
• Beliebt bei Entwicklern

SPA-Frameworks

• Initial: Leere Seite
  • Unterstützung für (initiales) Server-Side-Rendering (Universal App)
• Schnelllebig
  • Akzeptabler Supportrahmen für Enterprise-Anwendungen
  • Sofern aktiv aktualisiert wird
• Monolitisch

SPAs

Integrationsmodelle

• Majestic Modular Monoliths
• Link-Aggregation
• i-Frames
• Web Components

Majestic Modular Monoliths

Majestic Modular Monoliths

• Beispiele:
  • Outlock.com
  • Google Docs

Majestic Modular Monoliths

npm package

• Frontend-for-Backend
  • package pro Microservices
• Definierte Interfaces
• Fachlicher Schnitt der Komponenten
• Applikation wird aus mehreren Bibliotheken zusammengesetzt
  • Ein Deployment, ggf. auf mehrere Artefakte verteilt

npm package

Zusammenfassung

• Konsistente Oberfläche
• Verteilung
  • Kleiner Netzwerk-Footprint
• Versionierung
  • Sauberes Update
• Entkopplung zwischen Bibliotheks- und Applikationsentwicklung

npm package

Zusammenfassung

• Verteilung
  • Aufwändiger Round-Trip
• Versionierung
  • Veraltete Versionen
  • Aktualisierung von Versionen
  • Inkompatible Versionen
• Entkopplung zwischen Bibliotheks- und Applikationsentwicklung
  • Unnötiger Aufwand, wenn es die selben Leute sind
• Gleicher Technologie-Stack

Monorepo

Monorepo

Idee

• Alle Module in einem SCM-Repository
• Referenzieren sich gegenseitig
• Projekt- oder Unternehmensweit
• Organisatorische Änderung

Monorepo

Tools

• lerna
• nrlw (angular)

Monorepo

Bewertung

• Einfachere Verwaltung von vielen Bibliotheken
• Besserer Round-Trip
• Weg zurück ist offen
• Mehr Abstimmung notwendig

Monorepo

Bewertung

• Gemeinsames Release
  • Blockierende Abhängigkeiten
• Ein System
  • Eine Architektur
• Ein Technologie-Stack

Micro Apps

Micro Apps

Idee

• Mehrere Apps auf einer Seite
• Keine technischen Abhängigkeiten
• Integration im Browser
• Kommunikation der Apps untereinander

Micro Apps

• Getrennte Deployments
• Freie Technologiewahl
• Weniger Abstimmungen
• Weniger Komplexität je App
• Verteiltes System
• Verteilte Daten
• UI-Komposition

Micro Apps

Link Integration

Micro Apps > Link Integration

Idee

• Jede App wird in einer Seite ausgeliefert
• Verlinkung untereinander
• Kommunikation über Local Storage, Links, Cookies
• Beispiele
  • Outlook.com
  • Xing

Micro Apps > Link Integration

Bewertung

• Freie Technologiewahl
  • Klassisch Serverseitig
  • SPA
  • Mischformen
• Migrationspfad
• Unabhängiges Deployment
  • Mögliche Inkompatibilitäten

Micro Apps > Link Integration

Bewertung

• Redundanter Rahmen
• Einheitliches Look-and-Feel
• Verlust des Zustands
• Netzwerk Footprint

Micro Apps

i-Frames

• Beispiele:
  • Spotify Desktop App

Micro Apps > i-Frames

Bewertung

• Isolation
  • Separate Technologie-Stacks
  • Ladezeiten
  • Kommunikation schwieriger
• Größenangabe und Skalierung
• Navigation zwischen Apps aufwändig
• Browser Support in Zukunft unklar

Micro Apps

Web Components

• Shadow-DOM
• Custom Elements
• HTML Imports
• HTML Template
• W3C Standart

Micro Apps > Web Components

Idee

• Erstellung einer Web Component je App
  • Ggf. Kleinere Apps für die Verwendung in anderen Apps

Micro Apps > Web Components

Erstellung von Web Components

• Web Component Compiler
• stencil
• Angular Elements

Micro Apps

Web Components

• Leider nur über Polyfil in einigen Browsers
  • Polymer als Polyfill für webcomponents
• Kompatibilität der Frameworks mit Web-Components

Micro Apps > Web Components

Fragestellungen

• Initiale Ladezeit
  • Caching Strategy
• Größe der Apps

Micro Apps > Web Components

Fragestellungen

• Teamgröße
  • Ansonsten zu viele Komponenten
  • Organisation anhand von Fähigkeiten (Suche, Warenkorb, Vorschläge,...)
  • Alternativ: Kombination mit Library-Ansatz
• Server Side Rendering nicht spezifiziert
  • Alternative Lösungen

Micro Apps > Web Components

Bewertung

• Aktuelle Versionen weitestgehend kompatibel
• Autonomie lässt sich herstellen
• Komplexität bleibt im Rahmen
  • Falls Server Side Rendering benötigt wird höher
• Aufwand

Kommunikation im Client

• Event-Bus am Window-Object
• DOM-Event-Handler
• Gemeinsamen Zustand
• Über den Server

Kommunikation im Client

Event-Bus am Window-Object

• Zentral definiert
• Performant
• Lose Kopplung

Kommunikation im Client

DOM-Event-Handler

• Definierte Schnittstelle
• CDC-Testing möglich

Kommunikation im Client

Gemeinsamen Zustand

• Flux-Pattern
• Innerhalb einer App vorziehen
• An möglichen Bruchstellen sollte auf Events gesetzt werden

Kommunikation im Client

Über den Server

• Über Applikationsgrenzen
• Nicht bei schlechtem Netz

Fazit

Fazit

Zwei Ebenen

• Auf Seitenebene
• Auf Komponentenebene

Fazit

i-Frame

• Temporär bei Migrationen
• Hoher Isolationsgrad erforderlich
  • Nur wenn keine alternative Lösung!
• Nicht bei öffentlichen Anwendungen

Fazit

Link

• Temporär bei Migrationen
• Stark getrennten Bestandeilen (Office-Suites)

Fazit

ROCA

• Autonome Teams
• Nicht zu hohe Anforderungen
  • UX
  • UI
• Viel Interaktion zwischen Komponenten

Fazit

SPAs

• Sehr hohe Anforderungen an
  • UX
  • UI
• Integrations-Level nach Autonomiebedarf
  • Integration inkl. Server Side Rendering kann komplex werden
• Mögliche Trennung von Anfang an im Auge behalten

Zusammenfassung

• Mirco-Frondtends als Hilfsmittel, nicht selbstzweck
• Alignment für Design, ... notwendig
• Standarts müssen entwickelt werden (UI, UX, Kommunikation, ...)
• Anwender im Auge behalten