Microservices, die niemand bestellt hat
Mittelstand baut Microservices, weil es modern klingt. In 80 Prozent der Fälle wäre ein Modulith die bessere Antwort. Hier ist die ehrliche Trennlinie.
Architektur statt Buzzword
Microservices sind kein Reifegrad
Sie sind eine Antwort auf ein konkretes Skalierungs- und Organisationsproblem. Wer das Problem nicht hat, kauft sich die Lösung trotzdem ein - inklusive Rechnung.
Der Conway-Trugschluss
Netflix, Amazon und Spotify haben Microservices, weil sie tausende Engineers in unabhängigen Teams parallel arbeiten lassen müssen. Wenn Ihr Backend-Team aus vier Personen besteht, replizieren Sie keine Architektur, sondern eine Organisationsstruktur, die Sie gar nicht haben. Conway’s Law funktioniert auch umgekehrt: Zerschnittene Systeme erzwingen zerschnittene Kommunikation, wo vorher ein Meeting gereicht hätte.
Verteilte Systeme verteilen vor allem Probleme
Sobald zwei Services über Netz reden, haben Sie Latenz, partielle Ausfälle, Idempotenz, verteilte Transaktionen, Versionierung, Schema-Drift und ein Observability-Setup, das selbst ein eigenes Team braucht. Was vorher ein Stacktrace war, ist jetzt eine Korrelations-ID quer durch fünf Logs. Das ist nicht „modern“, das ist Steuer.
Die Modulith-Alternative
Modulith - der Default, den Sie ignorieren
Ein gut strukturierter Monolith mit klaren Modulgrenzen schlägt verteilte Services in fast jeder mittleren Domäne - und lässt sich später zerteilen, wenn Sie es wirklich brauchen.
Laravel 13 ist ein guter Modulith
Wir bauen Domänen-Module mit eigenen Verzeichnissen unter app/Modules, eigenem Eventbus über Laravel-Events und klaren Grenzen über Service-Klassen und Form Requests. Datenbank-Transaktionen sind atomar, Queries laufen ohne Netz-Hop, Tests starten in unter zwei Sekunden. Wenn ein Modul tatsächlich eigenständig wachsen will, ziehen wir es heraus - kontrolliert, nicht prophylaktisch.
Konkrete Trennlinie aus 20 Jahren Projekten
Faustregel: solange ein einziges Postgres-Cluster Ihre Last verträgt und ein Team Ihren Code-Stand kennt, bleibt es ein Modulith. Spätestens wenn ein Subsystem grundlegend andere Last-Charakteristiken hat (z. B. Mediendurchsatz vs. transaktionale Aufträge), wird Trennung sinnvoll - nicht vorher.
Architektur-Review gewünscht?
Wir schauen ehrlich auf Ihre aktuelle Aufteilung - und sagen Ihnen, wo Modulith reicht.
Wann Microservices Sinn ergeben
Die drei sauberen Auslöser
Nicht jedes Microservices-Projekt ist Quatsch. Es gibt drei Auslöser, bei denen die Zerlegung wirklich trägt.
Echte unabhängige Skalierung
Wenn ein Subsystem nachweisbar andere Last-Profile hat - z. B. Video-Transkodierung, ML-Inference oder ein Reporting, das nachts CPU frisst - lohnt ein eigener Service. Dann skalieren Sie genau das, was teuer ist, ohne den Rest mitzuziehen. Das ist Hetzner-Hardware in Euro gesprochen, nicht in Folien.
Mehrere Teams, mehrere Release-Zyklen
Sobald drei oder mehr Teams unabhängig deployen wollen, ohne sich an gemeinsamen Migrations zu verkanten, ergibt Service-Trennung Sinn. Vorher ist es ein Branching- und Code-Review-Problem, kein Architektur-Problem - und Branching ist billiger als Kafka.
Regulatorische Isolation
Wenn ein Teilsystem unter härtere Compliance-Anforderungen fällt - DSGVO-sensible Felder, Zahlungsverkehr unter PSD2, medizinische Daten -, ist es schlauer, diesen Bereich physikalisch und logisch zu trennen. Das spart Audit-Aufwand und reduziert den Blast Radius eines Vorfalls erheblich.
Die versteckten Kosten
Was die Slides nicht zeigen
Jede Service-Grenze ist eine Rechnung - in Engineer-Stunden, Tooling-Lizenzen und Bereitschaft.
Ops-Overhead: das Service-Mesh-Trauma
Mit Microservices kommt nicht nur Kubernetes, sondern auch Service-Discovery, mTLS, Tracing, Circuit-Breaker, Retry-Budgets und ein Mesh, das mehr CPU kostet als die Hälfte Ihrer Business-Logic. Wir haben Setups gesehen, in denen Istio mehr Tickets erzeugte als das Produkt selbst. Ein Modulith braucht ein Postgres, einen Redis und einen Reverse-Proxy. Punkt.
Daten-Konsistenz: aus Transaktion wird Saga
Was im Monolith eine DB-Transaktion war, wird im verteilten System ein Saga-Pattern mit Kompensations-Schritten, Outbox-Tabellen und manueller Konfliktlösung. Eventual Consistency klingt entspannt, bis ein Kunde anruft, weil eine Bestellung halb existiert. Wenn Sie das nicht designen wollen, bauen Sie keine Microservices.
24/7-Bereitschaft mal N
Jeder produktive Service ist ein eigener Rufbereitschafts-Slot. Aus einer Pager-Rotation werden schnell sieben. Wer das nicht ehrlich in den Personalplan schreibt, betreibt am Ende zwölf Services mit drei Engineers - und keine schläft mehr durch.
Wie wir entscheiden
Unsere Entscheidungsmatrix
Drei Fragen, ehrlich beantwortet, ersparen Ihnen einen sechsstelligen Refactor.
Frage 1: Haben Sie ein echtes Skalierungsproblem?
Nicht „wir wachsen“, sondern „Komponente X ist nachweislich der Bottleneck“. Konkret: P95-Latenzen, CPU-Sättigung, Queue-Längen. Wenn Sie diese Zahlen nicht haben, haben Sie kein Skalierungsproblem - Sie haben ein Monitoring-Problem. Erst messen, dann zerteilen.
Frage 2: Haben Sie genug Köpfe für die Ops-Last?
Pi mal Daumen: pro produktivem Service rechnen wir 0,5 bis 1 Engineer-Tag pro Monat allein für Routine-Ops (Updates, Zertifikate, Patches, Log-Reviews). Bei zehn Services sind Sie also fünf bis zehn Tage pro Monat raus - egal wie viel Feature-Backlog wartet.
Frage 3: Sind die Domänen-Grenzen wirklich klar?
Wenn Sie Ihre Aggregate noch nicht sauber als Module im Monolith trennen können, werden Sie sie auch nicht sauber als Services trennen - Sie exportieren dann nur den Spaghetti-Code übers Netz. Erst Domain-driven aufräumen, dann eventuell verteilen. Nicht andersrum.
Artikel teilen
Lassen Sie uns reden
Bevor Sie in Microservices investieren, klären wir gemeinsam, ob Sie sie wirklich brauchen.
Wir schauen uns Ihr System ehrlich an, zeigen Ihnen wo ein Modulith reicht, wo eine Trennung trägt - und sagen es deutlich, wenn Sie gerade Ops-Schmerz für ein Buzzword einkaufen.