Wann ein Monolith reicht, wann man trennt. Conway's Law, Team-Topologien — und warum die Antwort nicht „Microservices" lautet.
Kategorie · DevOps & Infra
Zwei Architekturen, eine Abwägung.
Ein Monolith hält die gesamte Anwendung in einer Codebasis und einem Deployment. Microservices zerlegen sie in viele eigenständige Dienste, die getrennt entwickelt, ausgeliefert und skaliert werden.
Beides ist legitim. Die Trennung kostet Komplexität — Netzwerk, Datenkonsistenz, Betrieb — und dieser Preis muss durch einen echten Nutzen gerechtfertigt sein.
Wann man trennt.
Conway's Law besagt, dass Systeme die Kommunikationsstruktur ihrer Organisation abbilden. Microservices ergeben Sinn, wenn mehrere eigenständige Teams unabhängig liefern müssen, ohne sich gegenseitig zu blockieren.
Bis dahin baut man bei uns meist einen sauber strukturierten Monolithen — schneller zu entwickeln, einfacher zu betreiben, leichter zu verstehen. Trennen kann man später, gezielt entlang der Naht, die wirklich schmerzt.
Warum die Antwort nicht "Microservices" lautet.
Microservices als Standardentscheidung führen zu verteilten Monolithen: alle Nachteile der Verteilung, keiner ihrer Vorteile. Das ist der häufigste teure Fehler in diesem Feld.
Die richtige Frage ist nicht "Monolith oder Microservices", sondern "wo verläuft die Grenze, an der eigenständiges Liefern echten Wert schafft". Erst diese Grenze rechtfertigt den Schnitt.
