Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Von Monolithen zu fein-granularen Services. Klausurthema in 6/11 WInf-Programmen, besonders bei Software-Architektur-Fokus.
Die Idee in einem Satz
Architektur-Evolution: Monolith (1990er-2000er) → SOA mit ESB (2000er-2010er) → Microservices (2014+), getrieben von Skalierungs- und Agilitäts-Anforderungen.
Monolith, die klassische Architektur
Definition: Eine einzelne deploybare Einheit, alle Funktionen in einer Codebase, oft mit geteilter Datenbank.
Merkmale:
- Eine Code-Base, ein Deployment-Artefakt
- Direkter Methoden-Aufruf zwischen Modulen (in-process)
- Geteilte Datenbank (typisch 1 DB für alles)
- Einheitlicher Tech-Stack (z.B. nur Java + Oracle)
Vorteile:
- Einfache Entwicklung am Anfang
- Eine Deployment-Pipeline
- ACID-Transaktionen einfach
- Schneller Debug + Stack-Trace
Nachteile:
- Skalierung nur als Ganzes (vertikal)
- Lange Build/Deploy-Zyklen bei großem Code
- Tech-Stack-Lock-In
- Cross-Team-Konflikte bei Releases
Wenn passend: Kleines Team, früher Stage, vorhersehbare Last.
SOA, Service-Oriented Architecture (2000er)
Definition: Lose gekoppelte, wiederverwendbare Services kommunizieren über einen Enterprise Service Bus (ESB).
Merkmale:
- Services mit definierten Interfaces (Contracts)
- ESB als zentrale Vermittlungs-Schicht
- Standards: SOAP / WSDL / WS-* Stack
- Oft GETEILTE Datenbanken zwischen Services
- Top-Down-Governance + Service-Katalog
4 Prinzipien (SOA-Manifest 2009):
- Geschäftswert vor technischer Eleganz
- Strategische Ziele vor Projekt-Spezifischem
- Intrinsische Interoperabilität vor maßgeschneiderter Integration
- Geteilte Services vor speziellen Implementierungen
ESB-Aufgaben:
- Routing zwischen Services
- Protocol-Translation (SOAP ↔ REST ↔ JMS)
- Datenformat-Transformation (XML ↔ JSON)
- Orchestration (BPEL)
- Security + Monitoring
ESB-Tools: TIBCO, IBM WebSphere ESB, Oracle Service Bus, Mule ESB (heute MuleSoft Anypoint).
Probleme von SOA:
- ESB = Single Point of Failure
- Schwergewichtige WS-* Standards
- Service-Granularität oft zu groß ('macro services')
- Vendor Lock-In bei ESB-Produkten
- Top-Down-Governance bremst Teams
Microservices, die moderne Antwort (2014+)
Definition (Fowler / Lewis 2014): "An architectural style that structures an application as a collection of loosely coupled services, organized around business capabilities, independently deployable, and using lightweight protocols."
8 Charakteristika nach Fowler 2014:
- Componentization via Services, Services als deploybare Komponenten
- Organized around Business Capabilities, fachlich geschnitten (Bounded Context)
- Products not Projects, Teams besitzen Service-Lebenszyklus ('you build it, you run it')
- Smart Endpoints, Dumb Pipes, Intelligenz in Services, nicht in ESB
- Decentralized Governance, jeder Service wählt seinen Tech-Stack
- Decentralized Data Management, jeder Service hat EIGENE DB
- Infrastructure Automation, CI/CD + Container essentiell
- Design for Failure, Resilience-Pattern (Circuit Breaker, Bulkhead)
Wann sinnvoll?
- Große Teams (>50 Entwickler)
- Hohe Skalierungs-Anforderungen
- Schnelle Release-Frequenz
- Polyglote Tech-Stacks gewünscht
Wann NICHT?
- Kleines Team, kleine Anwendung
- Distributed-Systems-Erfahrung fehlt
- Operations-Team kann Container/K8s nicht stemmen
SOA vs. Microservices
| Aspekt | SOA | Microservices |
|---|---|---|
| Service-Granularität | Grob (~ "Macro Services") | Fein (Bounded Context) |
| Kommunikation | ESB (zentralisiert) | Direkt: REST/gRPC/Events |
| Daten | Oft geteilte DB | Jeder Service eigene DB |
| Protokoll | SOAP / XML / WS-* | REST / JSON, gRPC, async Events |
| Governance | Zentralisiert (Top-Down) | Dezentralisiert (Team-Autonomie) |
| Deployment | Oft gemeinsam | Unabhängig pro Service |
| Tech-Stack | Einheitlich | Polyglot |
| Ära | 2000-2015 | seit 2014 |
Microservices-Pattern (Auswahl)
Service Discovery
Wie finden Services einander dynamisch?
- Client-Side: Service-Registry (Consul, Eureka)
- Server-Side: Load-Balancer (NGINX, Cloud-LBs)
API Gateway
Zentraler Eingangspunkt für Clients:
- Routing zu Microservices
- Authentication / Authorization
- Rate-Limiting
- Caching
Tools: Kong, AWS API Gateway, Tyk, Zuul (Netflix).
Circuit Breaker (Nygard 2007)
Verhindert Kaskaden-Ausfälle: wenn Service B ausfällt, "öffnet" der Circuit Breaker und Service A bekommt sofort Fehler zurück (statt zu warten).
Tools: Hystrix (Netflix, deprecated), Resilience4j.
Saga-Pattern (für verteilte Transaktionen)
Statt 2-Phase-Commit über mehrere Services: Saga = Folge lokaler Transaktionen mit Kompensations-Aktionen bei Fehler.
Varianten: Choreography (Events) vs. Orchestration (Saga-Orchestrator).
Event-Driven Architecture
Services kommunizieren über Events statt direkte Aufrufe:
- Message Broker: Kafka, RabbitMQ, AWS SQS/SNS
- Pattern: Event Sourcing, CQRS
Service-Mesh
Eine weitere Abstraktions-Schicht für Microservices-Kommunikation:
- Sidecar-Proxy vor jedem Service (z.B. Envoy)
- Übernimmt: Routing, Encryption (mTLS), Observability, Retry
Tools: Istio, Linkerd, Consul Connect.
Containerization + Orchestrierung
Microservices brauchen Container:
- Docker (2013): leichtgewichtige Container statt VMs
- Kubernetes (Google 2014, Open-Source 2015): Container-Orchestrierung
Cloud-Native Stack:
App (Microservice)
→ Docker Container
→ Kubernetes (Orchestrierung)
→ Service Mesh (Kommunikation)
→ Cloud (IaaS/PaaS)
Trends 2024
- Modular Monolith Revival: nicht jedes Projekt braucht Microservices
- Serverless Functions (FaaS) statt klassischer Microservices
- gRPC + Protobuf ersetzt REST + JSON für interne APIs
- GraphQL als unified-API-Layer
- Backend-for-Frontend (BFF) Pattern für Mobile/Web
Klausur-Faustregeln
1. Architektur-Evolution: Monolith → SOA (mit ESB) → Microservices.
2. SOA-Granularität ist GRÖBER als Microservices.
3. ESB vs. 'Dumb Pipes': SOA zentralisiert Intelligenz, Microservices verteilen sie.
4. Microservices = eigene DB pro Service (Decentralized Data).
5. Bounded Context (DDD) als Microservice-Grenze.
6. Kubernetes + Docker = Cloud-Native Standard für Microservices.
Häufige Stolpersteine
1. SOA und Microservices gleichsetzen. Beide Service-orientiert, aber unterschiedliche Philosophien (ESB vs. Smart Endpoints, geteilte DB vs. eigene DB).
2. 'Microservices sind immer besser'. FALSCH. Bei kleinen Teams + Anwendungen ist Monolith oft optimal. Microservices = Distributed-Systems-Komplexität.
3. ACID-Transaktionen über Microservices erwarten. Nicht direkt möglich. Saga-Pattern + Eventual Consistency stattdessen.
4. Microservices ohne CI/CD + Container deployen. Praktisch unmöglich, Infrastructure Automation ist Voraussetzung.
5. ESB als 'veraltet' abtun. SOA mit ESB ist immer noch in vielen Banken/Versicherungen aktiv. Nicht alles muss Microservices werden.
6. Conway's Law ignorieren. "Organisationen entwerfen Systeme, die ihre Kommunikations-Strukturen abbilden." Microservices erfordern auch Team-Strukturen anzupassen.
Interaktiv verstehen
Architektur-Evolution: 3 Modelle visualisiert
Toggle zwischen Monolith / SOA / Microservices, pro Architektur Diagramm + Merkmale + Vor-/Nachteile + Beispiel-Firmen.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Bei "Vergleichen Sie SOA und Microservices" IMMER 4-5 Achsen: Granularität (grob vs. fein), Kommunikation (ESB vs. Smart Endpoints), Daten (geteilt vs. eigen), Governance (zentralisiert vs. dezentralisiert), Tech-Stack (einheitlich vs. polyglot). Plus Conway's Law als Brücke zu Team-Strukturen.
Praxis-Übung
SOA + Microservices, Praxis-Übung
6 Aufgaben zu Architekturen, Patterns und Cloud-Native.
Klausurfragen mit Lösungen (6)
- F1.Was ist der zentrale Architektur-Bestandteil von SOA?
Antwort: Enterprise Service Bus (ESB)
Erklärung: Enterprise Service Bus (ESB) ist DAS Kern-Element von SOA, zentrale Vermittlungs-Schicht zwischen Services. Aufgaben: Routing, Protocol-Translation (SOAP↔REST), Datenformat-Transformation (XML↔JSON), Orchestration (BPEL), Security + Monitoring. Tools: TIBCO, IBM WebSphere, Oracle Service Bus, MuleSoft. Microservices-Antithese: 'Smart Endpoints, Dumb Pipes' (kein ESB).
- F2.Welcher Slogan beschreibt die Microservices-Philosophie zur Kommunikation?
Antwort: Smart Endpoints, Dumb Pipes
Erklärung: 'Smart Endpoints, Dumb Pipes' (Fowler/Lewis 2014): Intelligenz liegt in den Services selbst (Endpoints), die Kommunikations-Pipes (HTTP, Message Queues) sind dumm + simpel. Antithese zu SOA, wo der ESB komplexe Logik trägt (Routing, Transformation, Orchestration). Microservices-Standard.
- F3.Ordne Architektur-Stil dem Merkmal zu.
Zuordnungen:
- Monolith → Eine Codebase, ein Deployment, geteilte DB
- SOA → ESB-zentriert, grobe Service-Granularität, oft geteilte DBs
- Microservices → Bounded Contexts, eigene DB pro Service, Decentralized Governance
- Service Mesh → Sidecar-Proxies vor jedem Service (Envoy/Istio)
Erklärung: Architektur-Charakteristika: Monolith (alles zusammen), SOA (Services + ESB + grobe Granularität), Microservices (fein-granular + eigene DBs + Polyglot), Service Mesh (Ergänzung für Microservices-Kommunikation via Sidecar-Proxies). Klausur-Klassiker.
Typ: Zuordnung
- F4.Was bedeutet das Saga-Pattern in Microservices?
Antwort: Verteilte Transaktion als Folge lokaler Transaktionen mit Kompensations-Aktionen
Erklärung: Saga-Pattern: Ersatz für klassische 2-Phase-Commit-Transaktionen in Distributed Systems. Eine 'Saga' ist eine Folge lokaler ACID-Transaktionen pro Service. Bei Fehler eines Schritts werden vorherige Schritte durch KOMPENSATIONS-Aktionen rückgängig gemacht. Beispiel Bestellung: 1) Lager reservieren, 2) Zahlung verbuchen, 3) Versand triggern. Wenn 3) fehlschlägt → Kompensation: Zahlung stornieren + Lager-Reservierung aufheben. Varianten: Choreography (event-getrieben) vs. Orchestration (Saga-Orchestrator).
- F5.Microservices sind IMMER besser als Monolithen, weil sie skalierbarer sind.
Antwort: Falsch
Erklärung: FALSCH. Microservices haben SIGNIFIKANTE Kosten: Distributed-Systems-Komplexität, Operations-Overhead (Container/K8s), verteilte Transaktionen schwer, höhere Latenz durch Netzwerk-Calls. Sinnvoll erst ab gewisser Größe (>50 Entwickler, hohe Skalierung). Bei kleinem Team + überschaubarer Anwendung ist MONOLITH oft optimal, wird auch 'Modular Monolith Revival' genannt (Trend 2024). Fowler-Zitat: 'You must be this tall to use microservices'.
Typ: Wahr/Falsch
- F6.Was beschreibt Conway's Law?
Antwort: Organisationen entwerfen Systeme, die ihre Kommunikations-Strukturen abbilden
Erklärung: Conway's Law (Melvin Conway, 1968): 'Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.' Wenn 4 Teams an einem Compiler arbeiten, wird der Compiler 4 Phasen haben. Folge für Microservices: Team-Strukturen MÜSSEN angepasst werden, 'Inverse Conway Maneuver': Team-Strukturen so umbauen, dass sie die GEWÜNSCHTE Architektur abbilden. Klausur-Klassiker im Architektur-Modul.
Klausur-Quiz
SOA + Microservices, Klausur-Quiz
6 typische Klausurfragen zu Architektur-Vergleich, Patterns und Cloud-Native.
Klausurfragen mit Lösungen (6)
- F1.Wer prägte den Begriff 'Microservices' mit dem berühmten Artikel?
Antwort: Martin Fowler + James Lewis (2014)
Erklärung: Martin Fowler + James Lewis: 'Microservices: a definition of this new architectural term' (martinfowler.com 2014). Erste klare Definition + 8 Charakteristika. Sam Newman: Buch 'Building Microservices' (2015, 2. Aufl. 2021), populäres Standardwerk. Eric Evans: Domain-Driven Design (Buch 2003), Konzept des Bounded Context, das Microservices-Grenzen prägt. Roy Fielding: REST in Dissertation (2000). Klausur-Standard.
- F2.Was ist der primäre Unterschied zwischen SOA und Microservices bei der Datenhaltung?
Antwort: SOA hat oft geteilte DBs, Microservices haben EIGENE DB pro Service
Erklärung: Daten-Trennung ist ein KERN-Unterschied. SOA: oft geteilte Datenbanken (mehrere Services greifen auf dieselbe DB zu, 'Shared Database Pattern'). Microservices: 'Database per Service', jeder Service hat EIGENE DB, andere Services greifen nur über die Service-API zu. Vorteil Microservices: lose Kopplung, unabhängiges Schema-Refactoring. Nachteil: verteilte Transaktionen schwer (Saga-Pattern nötig).
- F3.Architektur-Evolution: {{1}} (Pre-2010) → {{2}} mit ESB (2000er) → {{3}} (2014+). Microservices nutzen 'Smart Endpoints, {{4}} Pipes' und 'Database per {{5}}'.
Lösungen pro Lücke:
- {{1}}: Monolith
- {{2}}: SOA
- {{3}}: Microservices
- {{4}}: Dumb / dumb
- {{5}}: Service
Erklärung: Architektur-Historie: Monolith (klassisch) → SOA mit ESB (Service-Oriented Architecture, 2000er-2010er) → Microservices (Netflix/Amazon-Pioniere, ab 2014). Microservices-Prinzipien: 'Smart Endpoints, Dumb Pipes' (Intelligenz im Service, nicht in der Vermittlung) + 'Database per Service' (jeder Service hat eigene DB). Klausur-Standard.
Typ: Lückentext
- F4.Bringe die Cloud-Native-Stack-Schichten in aufsteigender Abstraktions-Reihenfolge (von App nach Infrastruktur).
Richtige Reihenfolge:
- Microservice-Anwendung
- Docker Container
- Kubernetes (Orchestrierung)
- Service Mesh (Istio, Linkerd)
- Cloud (IaaS/PaaS)
Erklärung: Cloud-Native-Stack: 1) Anwendung (Microservice). 2) Docker Container (Packaging). 3) Kubernetes (Container-Orchestrierung, Scheduling). 4) Service Mesh (Sidecar-Proxies für Kommunikation). 5) Cloud-Infrastruktur (IaaS/PaaS). Jede Schicht abstrahiert die untere. Standard-Cloud-Native-Architektur seit ~2018.
Typ: Reihenfolge
- F5.Welches Pattern verhindert Kaskaden-Ausfälle in Microservices?
Antwort: Circuit Breaker
Erklärung: Circuit Breaker (Michael Nygard, 'Release It!' 2007): wenn Service B häufig fehlschlägt, 'öffnet' der Breaker und Service A bekommt sofort einen Fehler zurück (ohne auf Timeout zu warten). Verhindert Kaskaden-Ausfälle (Service C wartet auf B, das auf A wartet...). Zustände: Closed (normal) / Open (Fail Fast) / Half-Open (Test-Versuch). Tools: Hystrix (Netflix, deprecated 2018), Resilience4j (modern). Saga = verteilte Transaktion. API Gateway = zentraler Eingang. Service Discovery = Service-Lookup.
- F6.Domain-Driven Design (DDD) mit dem Konzept 'Bounded Context' liefert das primäre Kriterium zum Schneiden von Microservices.
Antwort: Wahr
Erklärung: RICHTIG. Bounded Context (Eric Evans, DDD 2003): klar abgegrenzter Bereich, in dem ein bestimmtes Domain-Modell mit konsistenter Sprache gilt. Mehrere Bounded Contexts in einem Unternehmen, z.B. 'Order Management' vs. 'Customer Service' vs. 'Inventory'. Praxis-Standard: Microservice = Bounded Context. Pendant: Conway's Law, Team-Struktur entspricht Bounded Contexts. 'Inverse Conway Maneuver': Teams nach gewünschten Bounded Contexts umstrukturieren. Klausur-Klassiker.
Typ: Wahr/Falsch
