Definitionen und Abgrenzung
Sehr gut 👍 – deine Definition ist korrekt, aber noch sehr „Wikipedia-artig“. Für deinen Architektur-Docusaurus kannst du stärker auf Architektur-Implikationen, Trade-offs und echte Kriterien eingehen – also: Woran erkennt man es wirklich?
Hier eine erweiterte Version, die du fast 1:1 ĂĽbernehmen kannst.
Definitionen und Abgrenzung
Newman und Fowler/Lewis​
- Sam Newman: kleine, autonome Services, die zusammenarbeiten.
- Fowler/Lewis: Services um Business-Fähigkeiten, unabhängig deploybar, dezentrale Daten und Governance.
Ergänzend:
- Services kapseln Business Capabilities, nicht technische Schichten.
- Kommunikation erfolgt ĂĽber klar definierte APIs oder Events.
- Jeder Service besitzt seine eigene Datenhaltung.
Kerneigenschaften eines Microservice-Systems​
Ein System darf sich nur dann Microservice-Architektur nennen, wenn folgende Eigenschaften erfĂĽllt sind:
1. Fachliche Schnitte (Business Capabilities)​
Services sind entlang von Domänen geschnitten:
- Billing
- Identity
- Order Management
- Reporting
Nicht entlang technischer Layer wie:
- Service A = „User CRUD“
- Service B = „Validation Service“
2. Unabhängige Deploybarkeit​
Ein Service kann:
- ohne Koordination mit anderen Services deployed werden
- ohne Gesamtsystem-Restart aktualisiert werden
- in eigener Release-Frequenz betrieben werden
Wenn ein gemeinsames Versionieren oder „Big Bang“-Release notwendig ist → kein echtes Microservice-System.
3. Dezentrale Datenhaltung​
Jeder Service:
- besitzt seine eigene Datenbank
- kontrolliert sein Datenmodell selbst
- wird nicht per Shared Database gekoppelt
Gemeinsame Datenbank = starker Hinweis auf verteilten Monolith.
4. Autonome Teams​
Ein Team:
- besitzt Code + Daten + Deployment
- kann Entscheidungen lokal treffen
- trägt End-to-End-Verantwortung
Wenn zentrale Architektur- oder Datenbank-Gremien jede Ă„nderung freigeben mĂĽssen, ist echte Autonomie nicht gegeben.
5. Fehlertoleranz​
Ein einzelner Service darf ausfallen, ohne:
- das gesamte System lahmzulegen
- andere Services synchron zu blockieren
Daraus folgen:
- Timeouts
- Circuit Breaker
- Retry-Strategien
- Asynchrone Kommunikation
Praktische Abgrenzung​
Ein System ist nicht automatisch Microservices, nur weil:
- es viele Deployables gibt
- Docker verwendet wird
- Kubernetes im Einsatz ist
- REST-APIs existieren
Microservices sind eine organisatorische und architektonische Entscheidung, keine Infrastruktur-Frage.
Nicht verwechseln mit​
Verteiltem Monolith​
- Mehrere Deployables
- Starke synchrone Kopplung
- Gemeinsame Datenbank
- Gemeinsame Versionierung
Symptom: Ein Service kann nicht deployt werden, ohne 3 andere mit anzupassen.
SOA (klassisch)​
- Zentral gesteuerte Governance
- ESB-getriebene Integration
- Technische statt fachliche Schnitte
Modularer Monolith​
- Ein Deployable
- Saubere Modulgrenzen
- Interne Entkopplung
Wichtig: Ein sauberer Modular Monolith ist oft die bessere Wahl als schlecht gemachte Microservices.
Technische Konsequenzen​
Microservices implizieren:
- Netzwerk-Latenz
- Verteilte Transaktionen (oder deren Verzicht)
- Eventual Consistency
- Monitoring- und Observability-Overhead
- Komplexes Deployment
Microservices reduzieren nicht Komplexität – sie verlagern sie vom Code in die Infrastruktur.
Wann sind Microservices sinnvoll?​
Geeignet bei:
- GroĂźen Organisationen
- Mehreren autonomen Teams
- Stark unterschiedlichen Skalierungsanforderungen
- Heterogenen Technologien
- Hoher Release-Frequenz
Nicht geeignet bei:
- Kleinen Teams
- Stark gekoppelter Domäne
- Stabilen Anforderungen
- Geringem Skalierungsbedarf
Entscheidungsleitfrage​
Ist die organisatorische Autonomie wichtiger als die betriebliche Einfachheit?
Wenn nein → eher Modular Monolith. Wenn ja → Microservices.
Architektur-Denke (optional für dein Docusaurus)​
Du könntest einen Abschnitt einbauen wie:
Conway’s Law​
Die Architektur spiegelt die Kommunikationsstruktur der Organisation wider.
Microservices funktionieren nur, wenn:
- Teams wirklich unabhängig sind
- Ownership klar geregelt ist
- Verantwortlichkeiten nicht zentralisiert sind