Microservices
Microservices sind fachlich abgegrenzte Dienste mit eigener Bereitstellung und Betriebsverantwortung. Ihre Unabhängigkeit erzeugt zugleich Netzwerk- und Koordinationsaufwand.
- Eigener DienstEigene Bereitstellung, Daten und Verantwortung.
- VoraussetzungenDaten, Vertrag und Betrieb müssen stehen.
- Distributed MonolithGetrennt gebaut, aber weiter abhängig.
Einordnung
Warum das wichtig ist
Ein eigener Dienst macht nur unabhängig, wenn Team, Daten, Verträge und Betrieb mitziehen; sonst entsteht ein Distributed Monolith. Die Fallacies of Distributed Computing beginnen mit dem Irrtum, das Netz sei zuverlässig. Strangler Fig löst eine Fähigkeit schrittweise heraus. Für fachliche Grenzen innerhalb einer Anwendung siehe Modularer Monolith.
Dieser Baustein erklärt unabhängige Dienstgrenzen. Für fachliche Grenzen innerhalb einer Anwendung siehe Modularer Monolith.
Auf einen Blick · Eigenständige Dienste mit eigener Datenbank
Trägt der Versand einen eigenen Dienst?
Variante: Der Shop trennt den Versand als eigenen Dienst ab, weil ein separates Team ihn unabhängig veröffentlicht und skaliert. Die übrigen sechs Module bleiben im modularen Monolithen; der Zahlungsanbieter bleibt extern.
So liest du das Bild
- Eigener Dienst Das Urteil „Eigener Dienst trägt“ erscheint, wenn Nutzen und alle Voraussetzungen angekreuzt sind.
- Voraussetzungen Die Gruppe „Voraussetzungen“; nicht angekreuzte Punkte erscheinen unter „Es fehlt:“.
- Distributed Monolith Das Urteil „Risiko Distributed Monolith“ bei Nutzen ohne vollständige Voraussetzungen.
Risiko Distributed MonolithDer Nutzen ist da, aber nicht alle Voraussetzungen stehen. Der Dienst wäre getrennt, bliebe aber abhängig und teuer im Betrieb.
Es fehlt: Eigene Versanddaten, Ausfallfester Vertrag, Betrieb aus einer Hand
Nutzen & Grenzen
Hilft, wenn
- Unabhängig zu veröffentlichende Fähigkeiten erhalten mit eigenen Dienstverträgen getrennte Änderungs- und Releasewege.
- Unterschiedliche Lastprofile lassen sich gezielt mit Ressourcen für den jeweils beanspruchten Dienst bedienen.
- Ein Team mit Verantwortung für Daten, Vertrag, Überwachung und Wiederherstellung kann eine unabhängige Dienstgrenze tragfähig betreiben.
Grenzen
- Eine Bestellung über zwei Dienste braucht Koordination und sichtbare Zwischenzustände, weil es keine gemeinsame Transaktion mehr gibt; siehe Saga.
- Ohne Bereitschaft für Überwachung und Wiederherstellung ist ein Dienst kein eigener Dienst.
- Gemeinsame Tabellen oder lange synchrone Ketten führen zum Distributed Monolith, der Kosten ohne Autonomie trägt.
In der Praxis
- Schneide einen Dienst entlang einer fachlichen Fähigkeit und ordne ihm Daten, Vertrag und Betriebsverantwortung zu. Die Grenze soll ein Team eigenständig entwickeln und wiederherstellen können.
- Definiere pro Operation Timeout, Ergebnis und unbekannten Ausgang. Ein Aufrufer benötigt eine Statusklärung, wenn eine Antwort ausbleibt; verwende dafür Timeout und Partielle Ausfälle.
- Erfasse Releaseautonomie, Lastverteilung und Betriebsaufwand gemeinsam. Bei enger Kopplung prüfe Distributed Monolith; Abhängigkeiten beschreibt Datenhoheit.
Ausführliche Erklärung lesen
Ein Microservice besitzt eine fachliche Fähigkeit, ihren Vertrag und den Zustand, den er verbindlich ändern darf. Andere Dienste greifen über ein Netzwerk oder veröffentlichte Ereignisse darauf zu. Teams können so einzelne Dienste unabhängig entwickeln, ausliefern und skalieren.
Die Prozessgrenze bringt eigene Latenz, Versionierung, Ausfälle, Beobachtbarkeit und Wiederherstellung mit sich. Ein Timeout klärt den Ausgang einer Operation nicht; die Zuständigkeit und Fehlersemantik müssen deshalb im Vertrag sichtbar werden. Eigenständigkeit umfasst Entwicklung und Betrieb, nicht allein einen separaten Prozess.
Bounded Context bestimmt den fachlichen Zuschnitt; Distributed Monolith macht sichtbar, wann Netzgrenzen trotzdem gemeinsame Releases erzwingen.
Eine Spielart mit eigenem Namen sind Self-contained Systems (SCS): Jeder Fachbereich ist eine eigenständige Web-Anwendung mit eigener Oberfläche und eigenen Daten. Das Muster ist besonders im deutschsprachigen Raum verbreitet.
Der Netzwerkaufruf zum Versand bringt typische Irrtümer mit, die die Fallacies of Distributed Computing beschreiben, etwa dass das Netz zuverlässig sei. Wer den Versand herauslösen will, kann das mit Strangler Fig schrittweise tun, statt ihn auf einmal neu zu schreiben.
Ein eigener Dienst braucht ein zuständiges Team mit Entscheidungsbefugnis sowie Daten- und Betriebsverantwortung; ein separater Prozess allein schafft diese Autonomie nicht.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welches Urteil zeigt das Bild im Startzustand, und was fehlt?
Lösung mit Begründung ansehen
Risiko Distributed Monolith: Team und Release-Takt sind angekreuzt, aber eigene Versanddaten, ausfallfester Vertrag und Betrieb aus einer Hand fehlen.
AnwendenAuf eine neue Lage übertragen
Der Versand bekommt eigene Daten, der Betrieb ist aber noch nicht geregelt. Was zeigt das Urteil?
Lösung mit Begründung ansehen
Weiterhin Risiko Distributed Monolith. „Es fehlt“ nennt nur noch ausfallfesten Vertrag und Betrieb aus einer Hand.
BewertenEine Alternative abwägen
Alle sechs Kriterien sind erfüllt. Sollte der Versand sofort komplett neu als Dienst geschrieben werden?
Lösung mit Begründung ansehen
Nein, nicht zwingend. Ein Komplettersatz bündelt Risiko und lässt keinen Rückweg. Besser Strangler Fig: schrittweise herauslösen, messen, bei Bedarf zurückschalten. Dafür dauert der Übergang länger.
Vertiefen
Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.
Peer-to-Peer
Peer-to-Peer beschreibt eine Rollenverteilung, in der Teilnehmende je nach Vorgang zugleich Leistungen anbieten und nutzen. In einer hypothetischen Shop-Erweiterung können gleichberechtigte Händlerknoten Bestandsangebote veröffentlichen, abfragen und bei Bedarf weiterleiten. Das unterscheidet sich von der üblichen zentralen Shopplattform mit klarer Client- und Serverrolle. Der Händlerverbund braucht Regeln für Identität, Konfliktauflösung, Erreichbarkeit und Zustellung; dieser Stil passt nur, wenn solche dezentrale Zusammenarbeit einen fachlichen Bedarf erfüllt.
Zum AusprobierenVergleiche die zentrale Shopplattform mit einem hypothetischen Marktplatz gleichberechtigter Händlerknoten. Prüfe, ob jeder Knoten Angebote veröffentlichen und abfragen muss, und kläre Identität, Konfliktauflösung, Erreichbarkeit sowie Zustellung, bevor du Peer-to-Peer als Netzform wählst.
Weiterführende Bausteine
Quellen
- Martin Fowler · Microservices (öffnet in neuem Tab)Beschreibt Servicegrenzen, Datenverantwortung und organisatorische Konsequenzen.
- Martin Fowler · Breaking a Monolith into Microservices (öffnet in neuem Tab)Zeigt die Vorbereitung von Servicegrenzen und den schrittweisen Umbau.
- microservices.io · Database per Service (öffnet in neuem Tab)Beschreibt Datenverantwortung, API-Zugriff und Folgen für Abfragen.
- Martin Fowler · Microservice Prerequisites (öffnet in neuem Tab)Fowler nennt Voraussetzungen wie schnelle Bereitstellung, Monitoring und DevOps-Kultur, bevor Microservices sich lohnen.
- Team Topologies · Key Concepts (öffnet in neuem Tab)Wertstromorientierte Teams, Zusammenarbeit und kognitive Last als Perspektiven auf Teamzuschnitt.
- Microsoft · Peer-to-Peer Collaboration (öffnet in neuem Tab)Grundprinzip der Teilnehmer als Anbieter und Nutzer; historische Plattformbeispiele.