Die Diskussion über Monolithen und Microservices wird häufig als Skalierungsfrage dargestellt. In der Praxis geht es jedoch meist um operative Komplexität und Teamstruktur.
Viele Startups führen Microservices sehr früh ein. Obwohl Microservices für große Systeme sinnvoll sein können, bringen sie auch erhebliche zusätzliche Komplexität mit sich.
Zu verstehen, wann welche Architektur sinnvoll ist, hilft dabei, Systeme aufzubauen, die wachsen können, ohne unnötige Komplexität zu erzeugen.
Was ein Monolith tatsächlich ist
Ein Monolith ist ein System, bei dem die Anwendung als eine einzige Einheit deployt wird.
Das bedeutet nicht automatisch, dass die Codebasis unstrukturiert ist. Gut entwickelte Monolithen besitzen häufig klare interne Module und Domänengrenzen.
Ein modularer Monolith enthält typischerweise:
- getrennte Domänenmodule
- klar definierte interne Schnittstellen
- isolierte Business-Logic-Layer
- gemeinsames Deployment
Operativ läuft das System als eine Anwendung.
Was Microservices einführen
Microservices teilen die Systemfunktionalität in unabhängige Services auf, die über APIs oder Messaging miteinander kommunizieren.
Typische Eigenschaften:
- mehrere deploybare Services
- Service-zu-Service-Kommunikation
- verteilte Datenverantwortung
- unabhängige Skalierung
Diese Struktur kann langfristige Skalierung unterstützen, bringt jedoch zusätzliche Komplexität mit sich.
Operative Komplexität von Microservices
Microservices erfordern Infrastruktur und Betriebsprozesse, die kleine Teams häufig noch nicht aufgebaut haben.
Typische Herausforderungen sind:
- Service Discovery
- Netzwerkzuverlässigkeit
- verteiltes Debugging
- Datenkonsistenz zwischen Services
- API-Versionierung
- Monitoring und Tracing über mehrere Systeme
Für kleine Teams kann diese Komplexität die Entwicklung erheblich verlangsamen.
Wann ein Monolith die bessere Wahl ist
Für die meisten Seed-Stage-Produkte bietet ein modularer Monolith das beste Gleichgewicht zwischen Struktur und Einfachheit.
Vorteile sind:
Einfacheres Deployment
Eine Pipeline statt vieler unabhängiger Services.
Geringerer Betriebsaufwand
Monitoring, Logging und Debugging sind deutlich einfacher.
Schnellere Entwicklung
Entwickler können leichter zwischen Domänen arbeiten.
Konsistente Transaktionen
Datenbanktransaktionen bleiben einfacher zu handhaben.
Wenn Domänengrenzen im Monolithen klar definiert sind, kann die Architektur auch bei wachsendem System stabil bleiben.
Einen Monolithen so gestalten, dass er wachsen kann
Ein häufiger Irrtum ist, dass Monolithen nicht skalieren können.
In der Praxis liegt das Problem meist nicht im Monolithen selbst, sondern in fehlender modularer Struktur.
Ein skalierbarer Monolith sollte enthalten:
- klar definierte Domänenmodule
- interne Schnittstellen zwischen Domänen
- Trennung von Infrastruktur und Business-Logik
- möglichst getrennte Datenmodelle pro Domäne
Diese Struktur erleichtert später die Extraktion einzelner Services.
Wann Microservices sinnvoll werden
Microservices werden sinnvoll, wenn Systemkomplexität bestimmte Schwellen überschreitet.
Typische Anzeichen:
- mehrere unabhängige Entwicklungsteams
- sehr hohe Last in einzelnen Systembereichen
- unterschiedliche Laufzeitanforderungen einzelner Services
- mehrere Produktlinien auf gemeinsamer Infrastruktur
In solchen Fällen lassen sich Services aus einem modularen Monolithen deutlich leichter herauslösen.
Die Kosten verfrühter Microservices
Werden Microservices zu früh eingeführt, entstehen oft Systeme, die schwerer zu warten sind als ein Monolith.
Typische Symptome sind:
- übermäßige Service-Kommunikation
- doppelte Infrastrukturlogik
- fragile Integrationspunkte
- langsamere Feature-Entwicklung
Anstatt Skalierung zu ermöglichen, können verfrühte Microservices die Produktentwicklung verlangsamen.
Ein pragmatischer Ansatz
Ein praktischer Architekturansatz für frühe Produkte folgt oft dieser Reihenfolge:
- Mit einem modularen Monolithen starten
- Klare Domänengrenzen definieren
- API-artige Schnittstellen intern etablieren
- Services erst extrahieren, wenn operativer Druck es erfordert
Diese Strategie erlaubt es Systemen, natürlich zu wachsen, ohne unnötige Komplexität einzuführen.
Fazit
Die Entscheidung zwischen Monolith und Microservices sollte sich an operativen Realitäten orientieren, nicht an Architektur-Trends.
Für die meisten Seed-Stage-Produkte bietet ein modularer Monolith die beste Grundlage für schnelle Entwicklung und stabile Skalierung.
Microservices werden später relevant, wenn Teamgröße, Systemlast und organisatorische Struktur die zusätzliche Infrastruktur rechtfertigen.