| Typ | Konzept |
|---|---|
| Quellen | Quelle - Docker Bootcamp |
| Erstellt | 2026-09-27 |
| Aktualisiert | 2026-09-27 |
| Tags | softwarearchitektur, microservices, cloud, devops |
Microservices sind eine Softwarearchitektur, in der eine Anwendung aus vielen kleinen, eigenständigen Diensten mit eng begrenzter Aufgabe besteht, die über Schnittstellen miteinander sprechen. Sie lassen sich einzeln austauschen und skalieren, machen aber Entwicklung, Test und Betrieb komplexer. Das Gegenmodell ist der Monolith.
Monolith und Microservices
Im Software-Engineering gab es einen Paradigmenwechsel (Quelle - Docker Bootcamp, Folie 227):
- Monolith: alle Komponenten in einer Codebasis.
- Microservices: funktional eng begrenzte, eigenständige Komponenten, die über Schnittstellen kommunizieren. In Docker läuft in der Regel jeder Dienst in einem eigenen Container (Folie 132).
| Vorteile | Nachteile |
|---|---|
| Komponenten gezielt austauschen und weiterentwickeln | mehr Komplexität bei Entwicklung, Test und Deployment |
| verschiedene Technologien kombinierbar | schwierigere Kommunikation zwischen Diensten, z.B. um Datenbanken konsistent zu halten |
| mehrere Teams arbeiten parallel | Architektur insgesamt unübersichtlicher |
| Last flexibel auf mehrere Rechner verteilen | |
| Ausfallsicherheit |
Zustandslos
Microservices sollen oft automatisch skaliert werden: Kommen mehr Anfragen, werden weitere Webserver gestartet. Darum sind sie häufig zustandslos (stateless): Sie speichern selbst keine Daten, die Datenhaltung liegt bei einer Datenbank oder einem Datenbankdienst in der Cloud. Es gibt aber auch zustandsbehaftete Microservices (Folie 228). Kubernetes unterscheidet entsprechend Deployments für zustandslose und StatefulSets für zustandsbehaftete Dienste (siehe Kubernetes).
Beispiel im Kurs: Flask als Frontend, Redis als Backend, nginx als Proxy davor, jeder Teil in eigenem Container, verbunden über ein gemeinsames Netzwerk (siehe Docker Compose).
Die Abwägung gleicht der Frage aus der Angular-Architektur, wie stark man eine Frontend-Anwendung in unabhängige Feature-Bereiche zerlegt: Isolierte Teile lassen sich getrennt entwickeln und laden, aber jede Grenze kostet Abstimmung. Viele Fachleute empfehlen heute, mit einem gut gegliederten Monolithen zu beginnen und erst dann Dienste herauszulösen, wenn Teams oder Last es verlangen. Die Datenkonsistenz über Dienste hinweg ist das schwierigste Problem, weil klassische Datenbanktransaktionen nicht mehr über alles reichen. Das ist Allgemeinwissen und nicht eigens recherchiert. Betriebswirtschaftlich erinnert die Zerlegung an die Frage der Arbeitsteilung und Spezialisierung in der Produktionswirtschaft.
Verwandt
- Container – ein Dienst pro Container
- Container-Orchestrierung – Microservices auf Clustern betreiben und skalieren
- Kubernetes – Deployments und Services für Microservices
- Docker Compose – mehrere Dienste lokal zusammen starten
- Angular-Architektur – Zerlegung in isolierte Features im Frontend