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).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
Von Monolithen zu fein-granularen Services. Klausurthema in 6/11 WInf-Programmen, besonders bei Software-Architektur-Fokus.
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
Von Monolithen zu fein-granularen Services. Klausurthema in 6/11 WInf-Programmen, besonders bei Software-Architektur-Fokus.
Architektur-Evolution: Monolith (1990er-2000er) → SOA mit ESB (2000er-2010er) → Microservices (2014+) — getrieben von Skalierungs- und Agilitäts-Anforderungen.
Definition: Eine einzelne deploybare Einheit — alle Funktionen in einer Codebase, oft mit geteilter Datenbank.
Merkmale:
Vorteile:
Nachteile:
Wenn passend: Kleines Team, früher Stage, vorhersehbare Last.
Definition: Lose gekoppelte, wiederverwendbare Services kommunizieren über einen Enterprise Service Bus (ESB).
Merkmale:
4 Prinzipien (SOA-Manifest 2009):
ESB-Aufgaben:
ESB-Tools: TIBCO, IBM WebSphere ESB, Oracle Service Bus, Mule ESB (heute MuleSoft Anypoint).
Probleme von SOA:
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:
Wann sinnvoll?
Wann NICHT?
| 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 |
Wie finden Services einander dynamisch?
Zentraler Eingangspunkt für Clients:
Tools: Kong, AWS API Gateway, Tyk, Zuul (Netflix).
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.
Statt 2-Phase-Commit über mehrere Services: Saga = Folge lokaler Transaktionen mit Kompensations-Aktionen bei Fehler.
Varianten: Choreography (Events) vs. Orchestration (Saga-Orchestrator).
Services kommunizieren über Events statt direkte Aufrufe:
Eine weitere Abstraktions-Schicht für Microservices-Kommunikation:
Tools: Istio, Linkerd, Consul Connect.
Microservices brauchen Container:
Cloud-Native Stack:
App (Microservice)
→ Docker Container
→ Kubernetes (Orchestrierung)
→ Service Mesh (Kommunikation)
→ Cloud (IaaS/PaaS)
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.
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.
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.
6 Aufgaben zu Architekturen, Patterns und Cloud-Native.
Klausurfragen mit Lösungen (6)
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).
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.
Zuordnungen:
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
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).
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
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.
6 typische Klausurfragen zu Architektur-Vergleich, Patterns und Cloud-Native.
Klausurfragen mit Lösungen (6)
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.
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).
Lösungen pro Lücke:
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
Richtige Reihenfolge:
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
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.
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
| 2000-2015 |
| seit 2014 |