Microservices vs. monolithische Architektur
Dieser Beitrag ist eine Begriffserklärung zum Architekturvergleich Microservices vs. Monolith – inklusive Prüfungsfragen, Kernelementen und Tags.
In a Nutshell
Microservices und monolithische Architektur sind zwei gegensätzliche Ansätze zur Softwarestruktur: modular/dezentral/skalierbar vs. zentral/einfach/konsistent.
Kompakte Fachbeschreibung
Die monolithische Architektur beschreibt eine Software, die als eine einzige Einheit bereitgestellt und betrieben wird. Funktionen, Logiken und Schnittstellen sind eng gekoppelt.
Die Microservices-Architektur zerlegt die Anwendung in viele kleine, eigenständige Dienste, die über Netzwerkschnittstellen (meist REST oder Messaging) kommunizieren. Jeder Service ist unabhängig entwickel-, test- und deploybar – oft mit eigener Datenhaltung.
Microservices bieten Vorteile bei Skalierung und Wartbarkeit, benötigen aber mehr Infrastruktur, DevOps-Know-how und saubere Schnittstellen.
Prüfungsrelevante Stichpunkte
- Monolith = eine Anwendung, ein Deployment
- Microservices = unabhängige Dienste (oft eigene Repositories)
- Microservices fördern Skalierbarkeit und Flexibilität (IHK-relevant)
- Monolith ist einfacher bei kleinen Projekten (Praxisbezug)
- Microservices brauchen API-Gateways, Authentifizierung, Logging (Sicherheitsaspekt)
- Infrastrukturaufwand bei Microservices ist höher (Wirtschaftlichkeit)
- Schnittstellen und Abhängigkeiten müssen dokumentiert werden (Dokumentationspflicht)
- Microservices eignen sich gut für CI/CD und agile Teams
Kernkomponenten
- Servicegrenzen und Bounded Context
- Kommunikation (REST, gRPC, Messaging)
- Datenbank pro Service (Microservices)
- Zentrale Datenbank (Monolith)
- Deployment-Strategie (Single vs Multiple Pipelines)
- Service Registry & Discovery
- Monitoring/Logging pro Service
- Sicherheitslayer und Authentifizierung
- Fehlerisolierung (Circuit Breaker, Retry, Fallback)
- Service-Dokumentation (OpenAPI)
Einfaches Praxisbeispiel
Monolith:
Ein Webshop ist ein Java-Spring-Boot-Projekt mit Modulen (User, Bestellungen, Lager) → ein Deployment.
Microservices:
User-Service, Order-Service, Inventory-Service sind eigenständige Dienste, kommunizieren über REST,
werden getrennt via Docker/Kubernetes deployed.
Vorteile und Nachteile
Monolith
- Vorteile: einfaches Deployment, geringerer Infrastrukturbedarf, weniger Komplexität bei kleinen Teams
- Nachteile: schwer skalierbar, Änderungen beeinflussen andere Module, längere Releasezyklen
Microservices
- Vorteile: unabhängige Teams, Skalierung pro Service, Technologievielfalt
- Nachteile: hoher DevOps-Aufwand, komplexe Schnittstellen, verteilte Transaktionen schwieriger
Typische Prüfungsfragen (mit Kurzantwort)
- Was ist ein Monolith? Eine Anwendung, die als eine Einheit läuft und deployed wird.
- Zwei Vorteile von Microservices? Skalierung einzelner Dienste, unabhängiges Deployment.
- Wann ist ein Monolith sinnvoll? Bei kleinen Projekten mit wenigen Beteiligten.
- Wie kommunizieren Microservices typischerweise? Über HTTP/REST, gRPC oder Messaging (Kafka/RabbitMQ).
- Warum ist Microservice-Architektur komplexer? Verteiltes System, mehrere Deployments, mehr Fehlerquellen.
- Was ist ein API-Gateway? Zentrales Eingangstor zu Services (Routing, Auth, Monitoring).
Glossar
| Begriff | Definition |
|---|---|
| Monolithische Architektur | zentrale Softwarestruktur in einer Codebasis |
| Microservices-Architektur | verteilte Architektur mit autonomen Diensten |
| API-Gateway | zentrale Steuerung der Zugriffe auf Microservices |
Freie Antwort
Für viele IHK-Prüfungsprojekte ist ein Monolith oft besser dokumentierbar und ausreichend. Microservices lohnen sich erst, wenn klare Grenzen, Infrastruktur und DevOps-Fähigkeiten vorhanden sind. Ein guter Kompromiss ist ein modularer Monolith.
Lernstrategie
- Verständniseinstieg: Skizziere beide Architekturen für denselben Use Case.
- Vertiefung: Baue ein Mini-System mit Docker Compose.
- Prüfungsfokus: Begründe schriftlich die Architekturwahl.
- Fehlervermeidung: Nicht automatisch „Microservices = besser“ annehmen.
Themenanalyse
- Technischer Kern: Serviceorientierung, Schnittstellen, Deployments
- Implementierung: Kommunikation, Datenkonsistenz, CI/CD
- Sicherheit: Dienstgrenzen, Auth, Gateways
- Doku: Schnittstellen/Abhängigkeiten/Deployments
- Wirtschaftlichkeit: Aufwand vs. Flexibilität