Microservices vs. Monolith: Die richtige Wahl treffen

Einführung

„Sollten wir Microservices verwenden?” ist eine der häufigsten Architekturfragen, die mir gestellt werden. Die Antwort lautet fast immer „es kommt darauf an”, aber das hilft nicht weiter. Dieser Artikel bietet einen konkreten Rahmen für diese Entscheidung.

Die ehrliche Wahrheit

Die meisten Teams, die zu früh auf Microservices setzen, bereuen es. Der zusätzliche Komplexitätsaufwand ist erheblich, und die Vorteile zeigen sich erst ab einer bestimmten Größenordnung.

Ich habe gesehen:

• Ein 5-köpfiges Startup mit 20 Microservices, das Mühe hat, Features auszuliefern
• Ein 200-köpfiges Unternehmen mit einem gut strukturierten Monolithen, das schneller agiert als die Konkurrenz

Die Architektur sollte zu Ihrem Kontext passen, nicht zu Ihren Ambitionen.

Wann Monolithen gewinnen

Kleine bis mittlere Teams (< 50 Entwickler:innen)

Bei einem kleineren Team:

• Der Kommunikationsaufwand ist gering
• Gemeinsame Code-Verantwortung funktioniert
• Die Koordination von Deployments ist überschaubar
• Man kann sich den operativen Aufwand verteilter Systeme nicht leisten

Produkte in einer frühen Phase

Solange man noch herausfindet:

• Welche Features Nutzer:innen wollen
• Wo die Domänengrenzen liegen
• Welche Performance-Anforderungen bestehen

Ein Monolith erlaubt schnellere Iteration und einfaches Refactoring.

Einfache Domänen

Wenn Ihre Geschäftslogik unkompliziert ist und keine natürlichen Grenzen hat, erzeugt das Erzwingen von Microservices künstliche Komplexität.

Wann Microservices gewinnen

Große Teams (50+ Entwickler:innen)

Bei größerer Skalierung:

• Teams brauchen Autonomie, um schnell voranzukommen
• Die Koordination von Deployments wird zum Engpass
• Unterschiedliche Systemteile haben unterschiedliche Skalierungsanforderungen

Klare Domänengrenzen

Wenn Sie haben:

• Eigenständige Geschäftsfähigkeiten (Zahlungen, Inventar, Versand)
• Unterschiedliche Anforderungen an Dateneigentümerschaft
• Teams, die an Geschäftsdomänen ausgerichtet sind

Unterschiedliche technische Anforderungen

Wenn Teile Ihres Systems brauchen:

• Unterschiedliche Sprachen oder Frameworks
• Unterschiedliche Skalierungseigenschaften
• Unterschiedliche Deployment-Häufigkeiten
• Unterschiedliche Zuverlässigkeitsanforderungen

Der Entscheidungsrahmen

Bewerten Sie Ihre Situation anhand dieser Faktoren:

Teamgröße und -struktur

Domänenkomplexität

Deployment-Bedürfnisse

Skalierungsanforderungen

Interpretation:

• Punktzahl > 3: Starker Kandidat für einen Monolithen
• Punktzahl -2 bis 3: Beides funktioniert, Team-Präferenz berücksichtigen
• Punktzahl < -2: Starker Kandidat für Microservices

Der modulare Monolith: Das Beste aus beiden Welten

Bevor Sie zu Microservices wechseln, erwägen Sie einen modularen Monolithen:

src/
├── modules/
│   ├── users/
│   │   ├── api/
│   │   ├── domain/
│   │   └── infrastructure/
│   ├── orders/
│   │   ├── api/
│   │   ├── domain/
│   │   └── infrastructure/
│   └── payments/
│       ├── api/
│       ├── domain/
│       └── infrastructure/
└── shared/
    └── kernel/

Vorteile:

• Klare Grenzen ohne Netzwerk-Overhead
• Später leicht in Services extrahierbar
• Ein einziges Deployment, einfacherer Betrieb
• Erzwungene Modulgrenzen durch die Code-Struktur

Migrationspfad

Wenn Sie mit einem Monolithen starten und später migrieren müssen:

1. Extraktionskandidaten identifizieren

Suchen Sie nach Modulen, die:

• Klare Grenzen haben
• Unabhängige Skalierung benötigen
• Unterschiedliche Deployment-Anforderungen haben
• Von einem bestimmten Team verantwortet werden

2. Strangler-Fig-Muster

Nicht neu schreiben – schrittweise extrahieren:

1. Eine Fassade vor den Monolithen setzen
2. Eine Fähigkeit in einen Service extrahieren
3. Traffic zum neuen Service leiten
4. Wiederholen

3. Bei den Rändern beginnen

Extrahieren Sie Services, die:

• Weniger Abhängigkeiten haben
• Weniger kritisch sind (geringeres Risiko)
• Klare Schnittstellen haben

Häufige Fehler

Verfrühte Zerlegung

Aufteilung, bevor man die Domäne verstanden hat, führt zu falschen Grenzen. Services wieder zusammenzuführen ist viel schwieriger, als einen Monolithen aufzuteilen.

Verteilter Monolith

Wenn Ihre Services:

• Zusammen deployt werden müssen
• Eine Datenbank teilen
• Überall synchrone Abhängigkeiten haben

Dann haben Sie einen verteilten Monolithen – die gesamte Komplexität, aber keinen der Vorteile.

Betriebskosten ignorieren

Microservices erfordern:

• Service Discovery
• Verteiltes Tracing
• Log-Aggregation
• Container-Orchestrierung
• Mehr Komplexität im Bereitschaftsdienst

Stellen Sie sicher, dass Sie sich diesen Mehraufwand leisten können.

Ein Praxisbeispiel

Ein Unternehmen, das ich beraten habe, hatte 30 Entwickler:innen und 15 Microservices. Sie hatten Probleme mit:

• Langsamer Feature-Entwicklung (Änderungen betrafen mehrere Services)
• Häufigen Integrationsproblemen
• Komplexer Deployment-Koordination
• Hohem operativem Aufwand

Wir haben auf 4 Services konsolidiert, ausgerichtet an den Teamgrenzen:

• Kernplattform (gemeinsam genutzt)
• Kundenorientiertes Produkt
• Interne Tools
• Datenpipeline

Ergebnis:

• 40 % schnellere Feature-Auslieferung
• 60 % weniger Produktionsvorfälle
• Zufriedenere Entwickler:innen

Fazit

Bei der Debatte Microservices vs. Monolith geht es nicht darum, was „besser” ist – sondern darum, was zu Ihrem Kontext passt.

Beginnen Sie mit einem gut strukturierten Monolithen. Fügen Sie klare Modulgrenzen hinzu. Extrahieren Sie erst dann Services, wenn Sie einen konkreten Grund haben: Team-Autonomie, unabhängige Skalierung oder unterschiedliche technische Anforderungen.

Die beste Architektur ist die, mit der Ihr Team Nutzer:innen schnell und zuverlässig Mehrwert liefern kann. Manchmal sind das Microservices. Oft nicht.