Ein Monolith (monolithische Architektur) ist ein Software-Architekturansatz, bei dem eine Anwendung als eine einzige, zusammenhaengende Einheit entwickelt und bereitgestellt wird. Alle Komponenten -- Benutzeroberflaeche, Geschaeftslogik, Datenbankzugriff und APIs -- sind Teil desselben Codebase und werden gemeinsam deployt.
Der Monolith ist die traditionelle und nach wie vor weit verbreitete Architekturform. Waehrend Microservices in den letzten Jahren viel Aufmerksamkeit erhielten, setzen zahlreiche erfolgreiche Unternehmen bewusst auf monolithische Architekturen -- darunter Shopify, Stack Overflow und Basecamp.
Merkmale einer monolithischen Architektur
Einheitliche Codebasis
Die gesamte Anwendung lebt in einem Repository. Alle Funktionen -- von der Nutzerverwaltung bis zur Zahlungsabwicklung -- teilen sich denselben Code, dieselben Abhaengigkeiten und denselben Deployment-Prozess.
Gemeinsame Datenbank
Alle Module greifen auf dieselbe Datenbank zu. Das vereinfacht Transaktionen und Abfragen, da keine verteilten Datenbankoperationen noetig sind.
Single Deployment Unit
Die gesamte Anwendung wird als eine Einheit bereitgestellt. Ein Update am Zahlungsmodul erfordert das Redeployment der gesamten Anwendung.
Vorteile des Monolithen
| Vorteil | Beschreibung |
|---|---|
| Einfache Entwicklung | Eine Codebasis, ein Framework, ein Build-Prozess |
| Einfaches Debugging | Alle Fehler im selben Prozess, Stack Traces sind vollstaendig |
| Einfaches Testing | End-to-End-Tests ohne Netzwerk-Mocks |
| Keine Netzwerk-Latenz | Funktionsaufrufe statt HTTP-Requests zwischen Services |
| Transaktionale Konsistenz | ACID-Transaktionen ueber die gesamte Anwendung |
| Geringer operativer Aufwand | Ein Server, ein Deployment, ein Monitoring |
| Schneller Start | Weniger Infrastruktur-Setup zum Loslegen |
Nachteile des Monolithen
Skalierungsgrenzen
Ein Monolith kann nur als Ganzes skaliert werden. Wenn der Zahlungs-Service unter Last steht, muss die gesamte Anwendung hochskaliert werden -- auch die Teile, die nicht belastet sind.
Deployment-Risiko
Jedes Deployment betrifft die gesamte Anwendung. Ein Fehler in einem kleinen Modul kann die ganze Anwendung zum Absturz bringen.
Wachsende Komplexitaet
Mit zunehmender Groesse wird die Codebasis schwerer zu verstehen und zu warten. Abhaengigkeiten zwischen Modulen werden unuebersichtlich, und Aenderungen koennen unerwartete Seiteneffekte haben.
Team-Bottlenecks
In grossen Teams blockieren sich Entwickler gegenseitig, wenn sie am selben Code arbeiten. Merge-Konflikte und koordinierte Releases bremsen die Entwicklung.
Monolith-Varianten
Klassischer Monolith
Alle Schichten (Praesetation, Geschaeftslogik, Datenzugriff) sind in einer einzigen Anwendung integriert. Typisch fuer aeltere Anwendungen.
Modularer Monolith
Die Anwendung ist intern in klar getrennte Module aufgeteilt, wird aber als eine Einheit deployt. Module haben definierte Schnittstellen und koennen spaeter leichter in Microservices extrahiert werden. Shopify ist das bekannteste Beispiel.
Majestic Monolith
Ein Begriff, den Basecamp-Gruender David Heinemeier Hansson praegte: Ein bewusst monolithisch gehaltenes System, das durch gute Code-Organisation und moderne Tools auch bei Wachstum effizient bleibt.
Wann ist ein Monolith die richtige Wahl?
Ein Monolith ist ideal, wenn:
- Das Entwicklerteam kleiner als 10 Personen ist
- Die Anwendung nicht extrem unterschiedlich skaliert werden muss
- Schnelle Marktreife (Time-to-Market) wichtig ist
- Die Domaene noch nicht vollstaendig verstanden ist
- Das Budget fuer Infrastruktur begrenzt ist
Beispiele aus der Praxis
Frameworks wie Next.js, Ruby on Rails und Django sind auf monolithische Anwendungen ausgelegt. Eine typische Agentur-Website mit CMS, Kontaktformular und Blog ist perfekt als Monolith umgesetzt -- Microservices waeren hier Overengineering.
Vom Monolith zu Microservices
Wenn ein Monolith an seine Grenzen stoesst, gibt es erprobte Migrationspfade:
- Strangler Fig Pattern: Neue Features als separate Services bauen, alte Funktionen schrittweise migrieren
- Domain-Driven Design: Bounded Contexts im Monolithen identifizieren und als Services extrahieren
- Modularer Monolith als Zwischenschritt: Interne Module sauber trennen, bevor sie ausgelagert werden
Die goldene Regel stammt von Martin Fowler: "Starten Sie als Monolith." Erst wenn die Komplexitaet oder die Teamgroesse den Monolithen zum Engpass macht, ist der Schritt zu Microservices oder einer hybriden Architektur mit API Gateway und Serverless-Funktionen gerechtfertigt.