Microservices vs. Monolith
In L6 haben wir die Schichtenarchitektur als das Standard-Strukturierungs-Pattern kennengelernt: Präsentation, Logik, Datenzugriff. Wir haben dort gesagt, dass diese drei Schichten typischerweise in einer einzigen Anwendung liegen – also einem Monolithen. In dieser Lektion stellen wir dieser klassischen Bauweise einen modernen Gegenspieler gegenüber: die Microservices-Architektur. Bei ihr wird das System in viele kleine, unabhängige Dienste zerschlagen, von denen jeder seine eigene Verantwortlichkeit hat.
Die Entscheidung Monolith oder Microservices ist eine der wichtigsten Architektur-Fragen überhaupt – mit großen Konsequenzen für Entwicklungstempo, Skalierbarkeit, Team-Struktur und Betrieb. Es gibt kein „besser" oder „schlechter", nur „passender" oder „weniger passend". Diese Lektion hilft dir, beide zu verstehen und die Wahl bewusst zu treffen.
1) Was ist ein Monolith?
Ein Monolith ist eine Anwendung, in der alle Funktionen in einer einzigen Codebasis entwickelt, als eine einzige Einheit deployed und meist als ein einziger Prozess ausgeführt werden. Das bedeutet nicht, dass der Code unstrukturiert ist – ein gut gemachter Monolith hat eine saubere Schichtenarchitektur, klare Modulgrenzen und vielleicht hunderte Klassen. Aber: alles wird gemeinsam gebaut, getestet und ausgerollt.
Eine gute Analogie ist ein Einfamilienhaus: alle Räume (Küche, Bad, Wohnzimmer) sind unter einem Dach, teilen sich Strom-, Wasser- und Heizungsanschluss. Wenn du die Küche renovierst, betrifft das auch die anderen Räume – mindestens kurzzeitig durch Bauarbeiten und Lärm. Genauso ist es im Monolithen: eine Änderung an einer Stelle erfordert, das ganze Haus neu zu bauen (zu deployen).
2) Was sind Microservices?
Eine Microservices-Architektur zerlegt das System in viele kleine, unabhängige Dienste. Jeder Microservice hat eine klar abgegrenzte fachliche Aufgabe (Bezahlung, Bestellungen, Benutzerverwaltung, Versand …), seine eigene Codebasis, oft sogar seine eigene Datenbank, und wird unabhängig deployed. Die Services kommunizieren miteinander über das Netzwerk – meist über REST-APIs oder über Message Queues.
Im Hausbau-Vergleich ist das eine Wohnsiedlung: viele kleine Häuser nebeneinander, jedes mit eigener Küche, eigenem Bad, eigenem Stromanschluss. Renovierungen im Haus 5 haben keine Auswirkungen auf Haus 7. Dafür braucht es Wege zwischen den Häusern (das Netzwerk), und Besuche kosten Zeit (Netzwerk-Latenz). Mehr Eigenständigkeit, aber auch mehr Koordinations-Aufwand.
3) Die zwei Bilder im direkten Vergleich
Bevor wir tief einsteigen, hier die beiden Welten nebeneinander. Beide zeigen einen vereinfachten Webshop – einmal als Monolith, einmal in Microservices zerschnitten:
4) Direkte Gegenüberstellung
Damit du in einer Klausur die Unterschiede aus dem Effeff heraussortierst, hier eine Tabelle mit den wichtigsten Aspekten:
5) Vor- und Nachteile mit Bewertung
Beide Architekturen haben Stärken und Schwächen – und nicht alle wiegen gleich schwer. Hier eine bewertete Übersicht. Die Sterne (★) zeigen, wie deutlich der jeweilige Vor- oder Nachteil ist:
6) Kommunikation zwischen Microservices
Wenn Services nicht mehr im selben Prozess laufen, müssen sie übers Netzwerk reden. Es gibt zwei große Stile dieser Kommunikation: synchron (Service A wartet auf Antwort von Service B) und asynchron (Service A schickt eine Nachricht und macht weiter, B antwortet später oder gar nicht). Diese Begriffe kennen wir bereits vom Sequenzdiagramm – hier werden sie technisch konkret:
7) Wann passt was? – Der Entscheidungs-Wizard
Es gibt keine pauschale Antwort, aber ein paar gute Fragen, die helfen, die Wahl zu treffen. Beantworte sie für dein Projekt – am Ende siehst du eine Empfehlung. Klick die zutreffenden Optionen:
8) Häufige Bausteine einer Microservices-Architektur
Wer eine Microservices-Architektur betreibt, kommt fast nie mit „nur Services" aus. Es gibt eine Reihe ergänzender Komponenten, die das Gesamtsystem zusammenhalten. Diese Begriffe solltest du kennen – sie tauchen in IHK-Klausuren regelmäßig auf:
9) Modulithen: der Mittelweg
Es gibt nicht nur Schwarz und Weiß. In den letzten Jahren hat sich ein interessanter Mittelweg etabliert: der Modulith – ein Monolith mit sehr strikt getrennten internen Modulen. Jedes Modul hat seine eigene API, seine eigenen Daten, kommuniziert nur über klar definierte Schnittstellen mit anderen Modulen. Aber: das Ganze wird als ein Artefakt deployed.
Vorteile: man hat die klare Strukturierung, die später eine Aufteilung in Microservices erleichtert – aber muss heute nicht die Komplexität eines verteilten Systems beherrschen. Wenn das Projekt wächst und ein Modul tatsächlich eigene Skalierung braucht, kann es gezielt herausgelöst werden. Ein Modulith ist quasi ein Monolith, der microservices-bereit ist.
10) Häufige Fehler in Klausuren
Typische Verwechslungen, die in IHK-Klausuren Punkte kosten:
11) Klausur-Fokus
Was wird typisch geprüft? Die Liste der wiederkehrenden Fragen:
- Definition: Was ist ein Monolith? Was sind Microservices? Worin liegt der Unterschied?
- Vor- und Nachteile beider Architekturen – jeweils mindestens 3 nennen.
- Kommunikation: wie reden Microservices miteinander? REST (synchron), Message Queue (asynchron), Events.
- Bausteine einer Microservices-Architektur: API-Gateway, Service Registry, Load Balancer, Message Broker, Container-Orchestrierung.
- Entscheidungsfaktoren: wann eignen sich Microservices, wann ein Monolith? Team-Größe, erwartete Last, DevOps-Reife, Projekt-Phase.
- Schichten vs. Services: kein Gegensatz, ergänzen sich.
Zusammenfassung
Diese Lektion hat die zwei großen Architektur-Stile gegenübergestellt. Ein Monolith ist eine Anwendung mit einer Codebasis, einem Deployment-Artefakt und meist einer Datenbank – innerlich kann er durch Schichten und Module gut strukturiert sein. Eine Microservices-Architektur zerlegt das System in viele kleine, unabhängige Dienste, jeder mit eigener Codebasis, oft eigener DB, unabhängig deploybar, kommunizierend über Netzwerk (REST synchron oder Message Queue asynchron). Vorteile Monolith: einfacher Einstieg, schnelles Deployment, einfaches Debugging, ACID-Transaktionen trivial, geringe Infrastruktur-Kosten. Nachteile Monolith: wächst unhandlich, lange Build-Zeiten, Crash = alles weg, Skalierung nur ganzheitlich, Team-Blockaden. Vorteile Microservices: unabhängige Deployments, selektive Skalierbarkeit, Fehler-Isolation, Technologie-Freiheit, klare Team-Zuständigkeit. Nachteile Microservices: verteiltes System (komplex), Netzwerk-Latenz, Daten-Konsistenz schwer (eventual consistency, Saga-Pattern), hohe Infrastruktur-Kosten, schwierigeres Debugging, hoher DevOps-Aufwand. Bausteine einer Microservices-Architektur: API-Gateway (Eingangspunkt), Service Registry (Verzeichnis), Load Balancer, Message Broker (RabbitMQ/Kafka), Container-Orchestrierung (Kubernetes, siehe K31 Cloud), zentralisiertes Logging, Monitoring, Circuit Breaker. Wichtige Daumenregel: „Don't start with microservices" – mit gut strukturiertem Monolithen beginnen, bei wirklichem Bedarf zerlegen. Modulith als Mittelweg: Monolith mit strikt getrennten Modulen, der „microservices-bereit" ist. Häufige Klausur-Fehler: Microservice mit kleiner Klasse verwechselt, Schichten und Services als Gegensatz, „Microservices automatisch besser", zentrale DB für alle Services (verteilter Monolith), Monolith pauschal als schlechter Code abqualifiziert. Klausur-Fokus: Definitionen kennen, je 3 Vor- und Nachteile, Kommunikations-Stile, typische Bausteine, Entscheidungsfaktoren. Nächste Lektion: REST-APIs – das Standardprotokoll für synchrone Service-Kommunikation, sowohl im Monolithen als auch zwischen Microservices.