Beim Monolithen bleiben bis 150 Entwickler:innen: Warum Microservices 30–50 % kosten

Setzen Sie standardmässig auf einen modularen Monolithen. Lösen Sie einzelne Microservices erst heraus, wenn Sie einen konkreten Grund auf Organisationsebene haben: ein Team, das über rund 150 Entwickler:innen hinausgewachsen ist, Arbeitslasten mit wirklich unterschiedlichem Skalierungsverhalten oder eine regulatorische Grenze wie PCI oder SOC 2, die Isolation verlangt. Microservices kosten im Betrieb real, oft geschätzt auf 30 to 50 percent of engineering capacity, sobald Sie die Netzwerkgrenze überschreiten. Die Beweislast liegt deshalb bei dem Team, das aufteilen will, nicht bei dem, das zusammenhält.

---

Kurz gefasst:

• Der Schritt zu Microservices ist teuer: Für den Betrieb braucht es 30 bis 50 Prozent mehr Entwicklungskapazität, besonders wenn Services eine Datenbank teilen oder gemeinsam ausgeliefert werden.

• Damit Microservices den Koordinationsaufwand, unterschiedliche Skalierung und regulatorische Vorgaben wirklich aufwiegen, braucht es meist ein Team von mehr als 150 Entwickler:innen.

• Kleinere Teams unter 30 Personen sollten bei einer monolithischen oder modularen Architektur bleiben: weniger Komplexität, schnellere Lieferung und kein Betriebsaufwand für Microservices.

• Migrieren Sie schrittweise mit dem Strangler-Fig-Muster: Beginnen Sie bei fachlichen Kontexten mit geringer Kopplung und verlagern Sie die Datenhoheit nicht zu früh.

• Führen Sie eine ehrliche Architekturprüfung durch: Teamkapazität, Reifegrad von CI/CD und fachliche Kontexte, bevor Sie sich für Microservices entscheiden oder einen Monolithen aufbrechen.

Inhaltsverzeichnis

• Monolith oder Microservices: die Definitionen, die Sie vor der Entscheidung brauchen

• Deployment, Daten und Kopplung: Wo sich die beiden Ansätze wirklich unterscheiden

• Abwägungen, die in echten Projekten tatsächlich auftauchen

• Wann Monolith, wann modular, wann Microservices

• So migrieren Sie, ohne einen verteilten Monolithen zu bauen

• Die Steuer auf verteilte Systeme: Was Microservices wirklich kosten

• Wie Ampersand diese Entscheidung mit Kund:innen angeht

• Warum „Monolith zuerst“ dem Branchenhype weiterhin überlegen ist

• Holen Sie sich eine ehrliche Architekturprüfung, bevor Sie etwas aufteilen

• Quellen

• FAQ

Monolith oder Microservices: die Definitionen, die Sie vor der Entscheidung brauchen

Die Hälfte der Diskussionen über „Microservices oder Monolith“ löst sich auf, sobald sich alle darauf einigen, was die Begriffe bedeuten. Ein klassischer Monolith ist eine einzige auslieferbare Einheit, meist eine Codebasis, ein Build, eine Datenbank, in der alle Module im selben Prozess laufen und dasselbe Schema teilen. Das ist der schnellste Weg zu einem funktionierenden Produkt, und so hat praktisch jedes erfolgreiche Softwareunternehmen begonnen.

Ein modularer Monolith behält diese einzige auslieferbare Einheit, erzwingt aber interne Grenzen: Module kommunizieren über definierte Schnittstellen, besitzen ihre eigenen Datentabellen auch innerhalb der gemeinsamen Datenbank und liessen sich theoretisch später ohne Neuentwicklung auseinandernehmen. Es bleibt eine Sache, die ausgeliefert wird, eine Sache, die überwacht wird, und ein Transaktionsmodell. Aber der Code verwandelt sich nicht in ein Knäuel, während er wächst.

Microservices bedeuten unabhängig auslieferbare Dienste, jeder mit eigenem Datenspeicher, die über das Netzwerk kommunizieren statt über Funktionsaufrufe im selben Prozess. Microsoft’s Azure architecture guidance bezeichnet das als entscheidendes Merkmal: Wenn ein Service nicht ausgeliefert werden kann, ohne ein Release mit drei anderen Teams abzustimmen, ist er noch kein echter Microservice.

Prüfen Sie Ihre eigene Codebasis anhand dieser Merkmale:

• Können Sie ein Modul ausliefern, ohne die ganze Anwendung neu zu deployen?

• Besitzt jede Fachdomäne ihre eigenen Tabellen, oder wird alles über dasselbe Schema hinweg verknüpft?

• Rufen sich Module über Funktionsaufrufe der Programmiersprache auf, oder über HTTP/gRPC/Message-Queues?

• Baut und testet Ihre CI/CD-Pipeline das System als eine Einheit, oder als viele unabhängige?

Deployment, Daten und Kopplung: Wo sich die beiden Ansätze wirklich unterscheiden

Die Unterschiede, auf die es ankommt, sind nicht philosophisch. Sie zeigen sich an vier konkreten Stellen: wie Sie Code ausliefern, wie Sie Daten speichern, wie Komponenten miteinander sprechen und wie Ihre Teams darum herum organisiert sind.

Deployment und Release-Kopplung. Ein Monolith wird als eine Einheit ausgeliefert. Jede Änderung, ob sie das Abrechnungsmodul oder die Anmeldeseite betrifft, fährt im selben Build und im selben Release mit. Microservices entkoppeln das: Ein Zahlungsteam kann zehnmal pro Tag ausliefern, während das Lagerteam einmal pro Woche ausliefert, und keines blockiert das andere. Diese Unabhängigkeit ist der wichtigste Grund, warum grosse Organisationen die Aufteilung anstreben.

Datenhoheit. Monolithen betreiben typischerweise eine logische Datenbank, was Abfragen und Transaktionen über Domänengrenzen hinweg trivial macht. Sie verknüpfen einfach Tabellen. Microservices drängen zu einer Datenbank pro Service, oft mit unterschiedlichen Speichertechnologien für unterschiedliche Anforderungen (polyglotte Persistenz). Damit fallen einfache Verknüpfungen weg, und Sie müssen stattdessen in eventueller Konsistenz, Sagas und API-Komposition denken. Microservices katalogisiert diese Muster, weil fast jedes Team sie zuerst auf dem harten Weg neu erfindet.

Kopplung und Fehlerverhalten. Funktionsaufrufe im Prozess scheitern selten und scheitern schnell. Netzwerkaufrufe zwischen Services bringen eine völlig neue Fehlerkategorie: Timeouts, Teilausfälle, Wiederholungen und die Notwendigkeit von Circuit Breakern. Das Netzwerk wird Teil Ihrer Architektur, ob Sie es geplant haben oder nicht.

Teamverantwortung und Conway's Law. Diese Achse wird unterschätzt. Architektur spiegelt meist die Kommunikationsstruktur der Organisation, die sie baut. Ein Team von 12 Entwickler:innen, das ein Produkt in neun Services aufteilt, betreibt keine gute Architektur, sondern kämpft gegen sein eigenes Organigramm. Die Zerlegung sollte den Teamgrenzen folgen, nicht ihnen vorausgehen.

Abwägungen, die in echten Projekten tatsächlich auftauchen

Die Vor- und Nachteile beider Ansätze sind nicht abstrakt. Sie treffen Ihren Kalender, Ihr Budget und Ihre Pikettdienste.

1. Monolithen gewinnen beim Tempo bis zum Markt. Eine Codebasis, eine Deployment-Pipeline, ein Ort für den Haltepunkt. Eine Anfrage von Anfang bis Ende zu debuggen heisst, einen Stacktrace zu lesen, statt verteilte Traces über fünf Services hinweg zusammenzusetzen.

2. Monolithen gewinnen bei den anfänglichen Infrastrukturkosten. Eine Datenbank, eine Hosting-Rechnung, kein Service Mesh, kein Monitoring-Stack pro Service. Für die meisten Startups sollte allein das die Debatte früh beenden.

3. Microservices gewinnen bei der unabhängigen Skalierung. Wenn Ihre Bildverarbeitung in Spitzenzeiten um das 50-Fache ansteigt, während der Service für Nutzerprofile konstant bleibt, können Sie nach der Aufteilung den teuren Teil skalieren, ohne alles andere mitzuskalieren.

4. Microservices gewinnen bei Teamautonomie und Fehlerisolation. Eine abstürzende Empfehlungs-Engine muss den Checkout nicht mitreissen, wenn es getrennte Services mit getrennten Fehlerbereichen sind.

5. Das grösste Risiko ist der verteilte Monolith. Services werden auf dem Papier aufgeteilt, aber sie werden weiterhin gemeinsam ausgeliefert, teilen eine Datenbank oder rufen sich in langen Ketten synchron auf. Sie erben den ganzen Betriebsaufwand von Microservices, ohne den Vorteil der Unabhängigkeit.

6. Die Zersplitterung ist real. Mehr Services bedeuten mehr Repositories, mehr Pipelines, mehr Dashboards und mehr Stellen, an denen sich eine Junior-Entwicklerin um 2 Uhr morgens während eines Vorfalls verliert.

Wann Monolith, wann modular, wann Microservices

Die Teamgrösse sagt am zuverlässigsten voraus, welche Architektur für Sie tatsächlich funktioniert, zuverlässiger als das Verkehrsvolumen oder sogar die technische Komplexität.

• Unter rund 30 Entwickler:innen: Bleiben Sie monolithisch, idealerweise modular. Sie haben nicht die Leute für ein Plattformteam, und der Koordinationsaufwand zwischen zwei Personen ist ohnehin praktisch null.

• Rund 30 bis 150 Entwickler:innen: Für die meisten Teams ist das das Gebiet des modularen Monolithen, mit gezielter Herauslösung von einem oder zwei Services, die ein wirklich anderes Skalierungsverhalten oder eine harte regulatorische Grenze haben.

• Über rund 150 Entwickler:innen: Microservices beginnen sich zu rechnen, weil die Koordinationskosten von Dutzenden Teams, die über ein einziges Release ausliefern, die Kosten für den Betrieb verteilter Infrastruktur übersteigen. Das HLD Handbook beschreibt das als ein organisatorisches Muster genauso wie ein technisches.

Über die Teamgrösse hinaus sprechen drei Signale aus der Arbeitslast dafür, dass eine Herauslösung sich lohnt: unterschiedlicher Skalierungsbedarf zwischen Komponenten, Latenzanforderungen, die je Funktion stark auseinandergehen, und stossweiser Verkehr, der Sie zwingen würde, den gesamten Monolithen überzudimensionieren, nur um einen einzigen heissen Pfad zu bewältigen.

Regulatorische Isolation ist der andere legitime Auslöser. Wenn der Geltungsbereich von PCI DSS oder die Grenzen von SOC 2 verlangen, dass Zahlungsdaten niemals denselben Prozess oder dasselbe Netzwerksegment wie alles andere berühren, dann ist das eine echte architektonische Randbedingung und keine Vorliebe.

Bevor Sie etwas herauslösen, gehen Sie diese Checkliste zur Bereitschaft durch:

• Haben Sie ein Plattformteam, und sei es ein kleines, das sich der gemeinsamen Infrastruktur widmet?

• Ist Ihre CI/CD-Pipeline so weit automatisiert, dass sie unabhängige Deployments ohne manuelle Freigaben trägt?

• Haben Sie echte Beobachtbarkeit: verteiltes Tracing, zentrale Logs und Dashboards auf Service-Ebene?

• Sind Ihre fachlichen Kontexte wirklich klar, oder raten Sie, wo die Nahtstellen liegen?

Praxistipp: Wenn Sie mindestens drei dieser vier Fragen zur Bereitschaft nicht mit „ja“ beantworten können, kostet die Herauslösung Sie in den ersten sechs Monaten mehr, als sie einspart. Schliessen Sie zuerst die Lücken, oder bleiben Sie noch eine Weile modular.

So migrieren Sie, ohne einen verteilten Monolithen zu bauen

Fast jede erfolgreiche Migration zu Microservices started as a monolith und bewegte sich Stück für Stück, nie als Neuentwicklung auf leerem Blatt. Das Strangler-Fig-Muster ist der Standardansatz, und es funktioniert, weil es Sie nie zwingt, das Unternehmen auf eine Umstellung mit einem Knall zu verwetten.

1. Setzen Sie eine Routing-Schicht vor den Monolithen. Ein API-Gateway oder Reverse Proxy sitzt zwischen den Clients und Ihrem System und leitet zunächst 100 % des Verkehrs an den bestehenden Monolithen weiter.

2. Wählen Sie einen fachlichen Kontext, den Sie zuerst herauslösen. Nehmen Sie etwas mit geringer Kopplung zum Rest des Systems, einem klar verantwortlichen Team und Datenbedarf, der keine ständigen Verknüpfungen mit anderen Domänen erfordert. Benachrichtigungen oder Suche sind häufige erste Kandidaten, die zentrale Abrechnung ist es selten.

3. Bauen Sie den neuen Service und betreiben Sie ihn parallel. Leiten Sie einen Teil des Verkehrs an den neuen Service, während der Monolith den Rest weiter bearbeitet, und vergleichen Sie die Ergebnisse, bevor Sie vollständig umschalten.

4. Verlagern Sie die Datenhoheit zuletzt, nicht zuerst. Behalten Sie die Datenbank des Monolithen als Quelle der Wahrheit, bis der neue Service sich als stabil erwiesen hat, und übertragen Sie dann die Hoheit samt Datenübernahme.

5. Wiederholen Sie das, einen fachlichen Kontext nach dem anderen, und nehmen Sie Monolith-Code aus dem Betrieb, sobald jede Herauslösung sich stabilisiert hat.

Achten Sie auf das Antimuster, das die ganze Branche immer wieder neu entdeckt: Services, die im Architekturdiagramm „unabhängig“ sind, in der Praxis aber alle gemeinsam ausgeliefert werden müssen. Die Faustregel des HLD Handbook ist deutlich: Zählen Sie, wie viele Services für ein beliebiges Release im Gleichschritt ausgeliefert werden müssen. Sind es die meisten, haben Sie einen verteilten Monolithen gebaut und wären mit einer Zusammenlegung besser bedient. Vertragstests zwischen Services und Feature-Flags beim Rollout fangen die meisten Rückschritte ab, bevor sie in die Produktion gelangen.

Die Steuer auf verteilte Systeme: Was Microservices wirklich kosten

Die Prozessgrenze zu überschreiten ist nicht gratis, und die Rechnung ist höher als das, was die meisten Teams einplanen. Die Schätzung des HLD Handbook setzt die Steuer auf verteilte Systeme bei rund 30 bis 50 % der Entwicklungskapazität an, sobald Sie Microservices in Produktion betreiben. Diese Zahl deckt Werkzeuge für Beobachtbarkeit, die Disziplin bei der Versionierung über Servicegrenzen hinweg und die Pikettlast beim Debuggen von Fehlern ab, die sich über fünf Services statt über einen Stacktrace erstrecken.

Diese Steuer zeigt sich in konkreten Positionen:

• CI/CD-Pipelines pro Service statt einer gemeinsamen Pipeline.

• Verteiltes Tracing und zentrale Protokollierung, weil „schau in die Logs“ jetzt heisst, fünf verschiedene Log-Ströme zu prüfen.

• Eine Plattform- oder SRE-Funktion, die sich der gemeinsamen Infrastruktur, dem Service Mesh und den Deployment-Werkzeugen widmet.

• Saga- und Outbox-Muster, um Transaktionen zu steuern, die früher ein einzelner Datenbank-Commit waren.

Es gibt Gegenmittel, vor allem Plattform-Engineering, das die wiederkehrenden Teile automatisiert, und Muster für Beobachtbarkeit, die von Tag eins an eingebaut und nicht nach einem Ausfall nachgerüstet werden. Werkzeuge, die wiederkehrende Betriebsarbeit übernehmen, können einen Teil dieser Steuer abfedern, aber sie beseitigen sie nicht. Wenn Ihr Team diese laufende Plattforminvestition nicht besetzen kann, lautet die ehrliche Antwort: monolithisch oder modular bleiben, bis Sie es können.

Wie Ampersand diese Entscheidung mit Kund:innen angeht

Ein erfahrenes Entwicklungsteam behandelt das zuerst als organisatorische und erst danach als technische Frage, denn genau dort gehen die meisten Entscheidungen zur Herauslösung schief. In einem Kundenprojekt mit einer wachsenden Plattform und Dutzenden internen Werkzeugen bestand der Ansatz darin, sich auf eine modulare Architektur zu konsolidieren, statt in Services zu zerfallen, für deren Betrieb das Team nicht besetzt war. Weil erfahrene Leute vom ersten Gespräch an dabei waren, wurde das Migrationsrisiko benannt, bevor Code geschrieben war, und nicht erst, nachdem eine Neuentwicklung ins Stocken geraten war. Die laufende monatliche Betreuung hielt das System danach gesund, ohne ein eigenes Plattformteam zu verlangen, das die Kundin nicht hatte.

Warum „Monolith zuerst“ dem Branchenhype weiterhin überlegen ist

Die verbreitete Meinung zu diesem Thema ist durch einen Überlebensfehler verzerrt. Alle erinnern sich an Netflix und Amazon, die an Konferenzen über Microservices sprechen. Niemand erinnert sich an die Hunderten Teams, die diese Architektur kopiert haben, ohne den Verkehr, die Personalstärke oder die Plattforminvestition, die dazugehören. Amazon hat nicht mit Microservices begonnen. Es wurde nach Jahren von Wachstumsschmerzen mit dem Monolithen dazu, und erst, als die Organisation eine einzige auslieferbare Einheit wirklich überwachsen hatte.

Die Lücke, die ich immer wieder sehe, liegt zwischen dem, was Microservices versprechen, und dem, was Teams tatsächlich betreiben können. Ein Startup mit 20 Personen, das neun Services einführt, kauft keine Skalierbarkeit, es kauft neun Dinge, die gepatcht, überwacht und alarmiert werden müssen, meist ohne dass jemand ausschliesslich dafür zuständig ist. Die Steuer auf verteilte Systeme fragt nicht um Erlaubnis. Sie zeigt sich innerhalb von zwei Quartalen in langsamerer Auslieferung von Funktionen, praktisch immer.

Wenn Sie eines mitnehmen: Machen Sie Teamgrösse und organisatorische Reife zum Entscheidungskriterium, nicht die Begeisterung für das Muster. Ein modularer Monolith ist kein Trostpreis. Für die meisten Unternehmen ist er einfach die richtige Architektur, auf unbestimmte Zeit.

Holen Sie sich eine ehrliche Architekturprüfung, bevor Sie etwas aufteilen

Ampersand Labs ist die Alternative dazu, sich durch eine Entscheidung zur Herauslösung zu raten: Erfahrene Entwickler:innen prüfen Ihre tatsächliche Codebasis und Teamstruktur, bevor sie etwas empfehlen, statt standardmässig zur gerade angesagten Architektur zu greifen. Das ist wichtig, weil die Kosten einer Fehlentscheidung nicht theoretisch sind. Teams, die zu früh herauslösen, zahlen das nächste Jahr die Steuer auf verteilte Systeme, statt Funktionen zu liefern.

Eine Architekturprüfung kann Ihre fachlichen Kontexte, den Reifegrad Ihrer CI/CD und die tatsächliche Kapazität Ihres Teams für Plattformarbeit betrachten und dann einen modularen Monolithen, eine eng gefasste Migration oder eine gezielte Herauslösung einzelner Services empfehlen, wo die Daten das wirklich stützen. Für Teams, die diesen Punkt schon hinter sich haben, kann die laufende monatliche Betreuung die Betriebslast abdecken, die Microservices erzeugen, ohne dass Sie ein vollständiges Plattformteam anstellen müssen. Weil erfahrene Leute ab dem ersten Gespräch dabei sind, erhalten Sie eine klare Antwort darauf, ob Sie überhaupt etwas aufteilen müssen. Beginnen Sie mit einem technischen Audit oder einem kurzen Erstgespräch, um herauszufinden, wo Ihre Architektur wirklich steht.

Quellen

• started as a monolith

• 30 to 50 percent of engineering capacity

• Microsoft’s Azure architecture guidance

• Microservices

FAQ

Sind Monolithen besser als Microservices?

Keines von beiden ist allgemein besser. Monolithen sind bei kleineren Teams und Produkten in der Frühphase meist im Vorteil, während sich Microservices auszahlen, sobald eine Organisation über einen einzigen Release-Zug hinausgewachsen ist und die nötige Plattformarbeit besetzen kann.

Ist Amazon monolithisch oder auf Microservices gebaut?

Amazon läuft heute auf Microservices, begann aber als Monolith und migrierte über Jahre schrittweise, während die Entwicklungsorganisation und der Verkehr wuchsen, nicht als Entwurfsentscheidung von Tag eins.

Was ist ein Beispiel für einen Monolithen?

Eine typische E-Commerce-Anwendung mit einer Codebasis, die Produktkatalog, Checkout und Benutzerkonten gegen eine einzige gemeinsame Datenbank abwickelt, ist ein klassischer Monolith, und so beginnen die meisten erfolgreichen Produkte.

Was sind die drei Arten von Microservices?

Microservices werden üblicherweise nach Funktion gruppiert: Domänen-Services, die bestimmte Geschäftslogik besitzen (etwa Abrechnung oder Lagerbestand), Integrations-Services, die externe Systeme anbinden, und Infrastruktur- oder Plattform-Services (etwa ein API-Gateway), die die anderen unterstützen.

Wann sollte ein Startup einen modularen Monolithen statt Microservices wählen?

Die meisten Teams mit weniger als rund 30 Entwickler:innen sollten standardmässig auf einen modularen Monolithen setzen, da sie selten die Leute haben, um die Arbeit an Plattform und Beobachtbarkeit zu besetzen, die Microservices verlangen.

Empfohlen

• Atelier Crincoli: Die ganze Goldschmiede-Werkstatt in einem System, damit kein Stück und kein Termin verloren geht.

• Interims-CTO Zürich, Tech Lead auf Zeit und in Teilzeit

• Habitects AG: Die technische Verantwortung für eine Plattform für Badrenovationen, bis durch eine Fusion hindurch.

• Migration von Altsystemen und Replatforming Zürich