Monolith oder Microservices

Ich steh gerade vor einem neuen Projekt und frage mich, ob wir uns mit Microservices wirklich einen Gefallen tun würden – oder ob das am Anfang nur schicke verteilte Komplexität ist. Monolith klingt erstmal „alt“, aber ein sauber modularisierter Monolith ist doch oft viel schneller gebaut, getestet und deployt.

Ab wann war bei euch der Punkt erreicht, an dem ihr **wirklich** aufteilen musstet? Und was waren die ersten Probleme: Deployments, Teamgröße, Performance, unterschiedliche Tech-Stacks? Würde gern echte Erfahrungen hören, nicht nur die üblichen Architektur-Folien 🙂

Ich würde fast immer mit einem modularen Monolithen starten. Microservices lösen selten ein technisches Problem, das man nicht auch erstmal innerhalb eines Prozesses lösen kann – dafür kommen Netzwerkfehler, verteiltes Debugging, Versionskompatibilität und deutlich mehr Betriebsaufwand dazu. „Wir könnten einzelne Teile unabhängig deployen“ ist für mich erst dann ein gutes Argument, wenn das im Alltag tatsächlich nötig ist.

Bei uns wurde die Aufteilung erst sinnvoll, als mehrere Teams ständig auf denselben Releases blockiert waren und ein Teilbereich wirklich eigene Skalierungs- bzw. Verfügbarkeitsanforderungen hatte. Vorher war der größte Schmerz nicht Performance, sondern die Disziplin im Monolithen: klare Modulgrenzen, keine direkten Datenbankzugriffe quer durch Module und idealerweise Tests, die diese Grenzen auch prüfen. Wenn man das nicht hinbekommt, werden Microservices meistens nur ein verteiltes Spaghetti-System.

Sehe ich ähnlich wie DenkMal: Ein modularer Monolith ist oft der beste Start, **wenn** die Modulgrenzen ernst genommen werden. Also keine gemeinsame „God-DB“, keine quer durch alle Pakete importierten Interna und idealerweise klare Schnittstellen zwischen den Modulen. Sonst wird die spätere Aufteilung tatsächlich schmerzhaft.

Bei uns war nicht die reine Last der Auslöser, sondern unterschiedliche Änderungs- und Betriebszyklen: Ein Importdienst musste separat skaliert und deployt werden, während der Rest der Anwendung relativ stabil blieb. Dann kann man erstmal genau diesen Teil herauslösen, statt direkt zehn Services zu bauen. Wichtig fand ich vorher schon Logs, Metriken und Tracing – ohne vernünftige Beobachtbarkeit macht verteiltes Debugging echt keinen Spaß. Wie plant ihr denn beim modularen Monolithen die Datenbankgrenzen?毛片高清免费视频

Ich würde noch den Deployment- und Betriebsaufwand stärker gewichten. Bei uns lief ein modularer Monolith anfangs super, aber irgendwann wurde die Build- und Testpipeline zum Flaschenhals: Jede kleine Änderung hat die komplette Testsuite angestoßen und musste durch denselben Releaseprozess. Das war nerviger als die reine Laufzeit-Performance.

Wir haben dann aber nicht gleich alles in Microservices zerlegt, sondern nur einen relativ klar abgegrenzten Benachrichtigungsdienst ausgelagert. Der hatte eigene Retry-Logik, andere Skalierungsanforderungen und durfte bei einem Ausfall nicht die Hauptanwendung blockieren. Das hat gut funktioniert – allerdings auch nur, weil wir vorher Logging, Metriken und Tracing halbwegs im Griff hatten. Ohne vernünftige Korrelation-IDs wäre die Fehlersuche echt zur Geisterjagd geworden.

Die „keine God-DB“-Regel finde ich dabei besonders wichtig. Ein Service, der offiziell unabhängig ist, aber ständig direkt Tabellen eines anderen Services liest, ist im Grunde nur ein verteilter Monolith mit zusätzlicher Latenz 😄 Ich würde deshalb bei einer möglichen Aufteilung schon im Monolithen Datenzugriffe über Modul-APIs kapseln, auch wenn das erstmal etwas mehr Boilerplate bedeutet.

Was ich interessant fände: Wie strikt trennt ihr die Module im Monolithen technisch? Nutzt ihr dafür Sprach-/Framework-Mechanismen, eigene Packages mit Architekturtests oder einfach Team-Konventionen? Bei uns haben Konventionen allein irgendwann nicht mehr gereicht.