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

Setzen Sie standardmässig auf einen modularen Monolithen. Lösen Sie erst dann Microservices heraus, wenn es einen konkreten Grund auf Ebene der Organisation gibt: ein Team, das über rund 150 Entwickler:innen hinausgewachsen ist, Arbeitslasten mit wirklich unterschiedlichen Skalierungsprofilen oder eine regulatorische Grenze wie PCI oder SOC 2, die Isolation verlangt. Microservices kosten im Betrieb echtes Geld, oft geschätzt auf 30 to 50 percent of engineering capacity, sobald Sie die Netzwerkgrenze überschreiten. Die Beweislast liegt deshalb beim Team, das aufteilen möchte, und nicht bei jenem, das die Dinge 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 sich Dienste 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 bleiben besser bei einer monolithischen oder modularen Architektur: weniger Komplexität, schnellere Lieferung, kein Betriebsaufwand für Microservices.
• Migrieren Sie schrittweise nach dem Strangler-Fig-Muster: Beginnen Sie bei Fachbereichen mit geringer Kopplung und verschieben Sie die Datenhoheit nicht zu früh.
• Prüfen Sie in einem ehrlichen Architektur-Review die Teamkapazität, die Reife Ihrer CI/CD und Ihre fachlichen Grenzen, bevor Sie sich für Microservices entscheiden oder einen Monolithen aufbrechen.

Inhalt

• Monolith oder Microservices: Diese Begriffe müssen vor dem Entscheid klar sein
• Auslieferung, 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
• Migrieren, ohne einen verteilten Monolithen zu bauen
• Die Steuer auf verteilte Systeme: Was Microservices wirklich kosten
• Wie Ampersand diesen Entscheid mit Kund:innen angeht
• Warum «Monolith zuerst» dem Hype der Branche weiterhin überlegen ist
• Holen Sie sich ein ehrliches Architektur-Review, bevor Sie etwas aufteilen
• Quellen
• FAQ

Monolith oder Microservices: Diese Begriffe müssen vor dem Entscheid klar sein

Die Hälfte aller Diskussionen über «Microservices vs. Monolith» löst sich auf, sobald sich alle einig sind, was die Begriffe bedeuten. Ein klassischer Monolith ist eine einzige auslieferbare Einheit: in der Regel eine Codebasis, ein Build, eine Datenbank, in der jedes Modul im selben Prozess läuft und dasselbe Schema nutzt. Das ist der schnellste Weg zu einem funktionierenden Produkt, und so hat fast jedes erfolgreiche Softwareunternehmen angefangen.

Ein modularer Monolith behält diese eine auslieferbare Einheit, erzwingt aber interne Grenzen: Module sprechen über definierte Schnittstellen miteinander, besitzen ihre eigenen Tabellen auch innerhalb der gemeinsamen Datenbank und liessen sich theoretisch später ohne Neuentwicklung herauslösen. Es bleibt eine Sache, die Sie ausliefern, eine, die Sie überwachen, und ein Transaktionsmodell. Der Code verheddert sich aber nicht, während er wächst.

Microservices sind unabhängig auslieferbare Dienste, jeder mit eigenem Datenspeicher, die über das Netzwerk kommunizieren statt über Funktionsaufrufe im selben Prozess. Der Microsoft’s Azure architecture guidance nennt genau das als entscheidendes Merkmal: Wenn ein Dienst nicht ausgeliefert werden kann, ohne die Freigabe 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 jeder Fachbereich eigene Tabellen, oder wird alles über dasselbe Schema hinweg verknüpft?
• Rufen sich Module über Funktionsaufrufe der Programmiersprache auf, oder über HTTP, gRPC oder Nachrichtenwarteschlangen?
• Baut und testet Ihre CI/CD-Pipeline das System als eine Einheit oder als viele unabhängige Einheiten?

Auslieferung, 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 ablegen, wie Komponenten miteinander sprechen und wie Ihre Teams rund um all das organisiert sind.

Auslieferung und gekoppelte Releases. Ein Monolith wird als Ganzes 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 liefert, und keines blockiert das andere. Diese Unabhängigkeit ist der wichtigste Grund, weshalb grosse Organisationen die Aufteilung angehen.

Datenhoheit. Monolithen laufen typischerweise auf einer logischen Datenbank, was Abfragen und Transaktionen über Fachbereiche hinweg trivial macht. Sie verknüpfen einfach Tabellen. Microservices drängen zu einer Datenbank pro Dienst, oft mit unterschiedlichen Speichertechnologien für unterschiedliche Bedürfnisse (Polyglot Persistence). Damit fallen einfache Verknüpfungen weg, und Sie müssen stattdessen in Eventual Consistency, Sagas und API-Komposition denken. Microservices führt diese Muster katalogartig auf, weil fast jedes Team sie zuerst auf die harte Tour neu erfindet.

Kopplung und Fehlerbilder. Funktionsaufrufe im selben Prozess scheitern selten und scheitern schnell. Netzwerkaufrufe zwischen Diensten führen eine völlig neue Fehlerkategorie ein: Zeitüberschreitungen, Teilausfälle, Wiederholungsversuche und die Notwendigkeit von Circuit Breakern. Das Netzwerk wird Teil Ihrer Architektur, ob Sie das eingeplant haben oder nicht.

Teamverantwortung und Conways Gesetz. Diese Achse wird regelmässig unterschätzt. Architektur spiegelt meistens die Kommunikationsstruktur der Organisation, die sie baut. Ein Team mit 12 Entwickler:innen, das ein Produkt in neun Dienste aufteilt, betreibt keine gute Architektur, es kämpft gegen das eigene Organigramm. Die Zerlegung sollte den Teamgrenzen folgen und ihnen nicht 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 zum Markt. Eine Codebasis, eine Deployment-Pipeline, eine Stelle, an der Sie einen Haltepunkt setzen. Eine Anfrage von Anfang bis Ende zu debuggen heisst, einen Stack-Trace zu lesen, statt verteilte Traces über fünf Dienste zusammenzusetzen.
2. Monolithen gewinnen bei den anfänglichen Infrastrukturkosten. Eine Datenbank, eine Hosting-Rechnung, kein Service Mesh, kein Überwachungs-Stack pro Dienst. 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 ausschlägt, während der Dienst für Benutzerprofile flach bleibt, können Sie nach der Trennung nur den teuren Teil hochfahren, statt für alles andere mitzuzahlen.
4. Microservices gewinnen bei Teamautonomie und Fehlerisolation. Eine abstürzende Empfehlungs-Engine muss den Bestellabschluss nicht mitreissen, wenn beide getrennte Dienste mit getrennten Fehlerbereichen sind.
5. Das grösste Risiko ist der verteilte Monolith. Die Dienste sind auf dem Papier getrennt, werden aber weiterhin gemeinsam ausgeliefert, teilen sich eine Datenbank oder rufen sich in langen Ketten synchron auf. Sie erben sämtliche Betriebskosten von Microservices, ohne den Vorteil der Unabhängigkeit zu erhalten.
6. Wildwuchs ist real. Mehr Dienste bedeuten mehr Repositories, mehr Pipelines, mehr Dashboards und mehr Orte, an denen sich eine Nachwuchskraft um 2 Uhr nachts während eines Vorfalls verlieren kann.

Wann Monolith, wann modular, wann Microservices

Die Teamgrösse sagt am zuverlässigsten voraus, welche Architektur bei Ihnen tatsächlich funktioniert, zuverlässiger als das Verkehrsaufkommen oder sogar die technische Komplexität.

• Unter rund 30 Entwickler:innen: Bleiben Sie monolithisch, idealerweise modular. Sie haben schlicht nicht die Leute für ein Plattformteam, und der Koordinationsaufwand zwischen zwei Personen ist ohnehin praktisch null.
• Rund 30 bis 150 Entwickler:innen: Das ist für die meisten Teams das Gebiet des modularen Monolithen, mit gezielter Auslagerung von ein oder zwei Diensten, die wirklich ein anderes Skalierungsprofil oder eine harte regulatorische Grenze haben.
• Über rund 150 Entwickler:innen: Ab hier rechnen sich Microservices, weil der Koordinationsaufwand von Dutzenden Teams in einem einzigen Release-Zyklus höher ist als die Kosten für den Betrieb verteilter Infrastruktur. Das HLD Handbook beschreibt das ebenso sehr als organisatorisches wie als technisches Muster.

Neben der Anzahl Personen sprechen drei Signale aus der Arbeitslast dafür, dass sich eine Auslagerung lohnt: unterschiedliche Skalierungsbedürfnisse zwischen Komponenten, stark abweichende Latenzanforderungen je Funktion und stossweiser Verkehr, der Sie zwingen würde, den gesamten Monolithen überzudimensionieren, nur um einen einzigen heissen Pfad zu bedienen.

Regulatorische Isolation ist der zweite legitime Auslöser. Wenn der Geltungsbereich von PCI DSS oder die Grenzen von SOC 2 verlangen, dass Zahlungsdaten nie denselben Prozess oder dasselbe Netzsegment wie alles andere berühren, ist das eine echte architektonische Vorgabe 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 um die gemeinsame Infrastruktur kümmert?
• Ist Ihre CI/CD-Pipeline so weit automatisiert, dass unabhängige Deployments ohne manuelle Freigaben möglich sind?
• Haben Sie echte Beobachtbarkeit: verteiltes Tracing, zentrale Protokolle und Dashboards pro Dienst?
• Sind Ihre fachlichen Grenzen wirklich klar, oder raten Sie, wo die Nahtstellen liegen?

Profi-Tipp: Wenn Sie mindestens drei dieser vier Fragen nicht mit «ja» beantworten können, kostet Sie die Auslagerung in den ersten sechs Monaten mehr, als sie einspart. Schliessen Sie zuerst die Lücken, oder bleiben Sie noch eine Weile modular.

Migrieren, 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 weiter, nie als Neuentwicklung auf der grünen Wiese. Das Strangler-Fig-Muster ist der übliche Ansatz, und es funktioniert, weil es Sie nie zwingt, die Firma auf eine einzige grosse Umschaltung zu verwetten.

1. Setzen Sie eine Routing-Schicht vor den Monolithen. Ein API-Gateway oder ein Reverse Proxy sitzt zwischen den Clients und Ihrem System und leitet anfangs 100 % des Verkehrs an den bestehenden Monolithen weiter.
2. Wählen Sie einen einzigen Fachbereich für die erste Auslagerung. Nehmen Sie etwas mit geringer Kopplung zum Rest des Systems, einem klar verantwortlichen Team und Datenbedürfnissen, die keine ständigen Verknüpfungen mit anderen Bereichen erfordern. Benachrichtigungen oder Suche sind häufige erste Kandidaten, die Kernabrechnung ist es selten.
3. Bauen Sie den neuen Dienst und lassen Sie beide parallel laufen. Leiten Sie einen Teil des Verkehrs auf den neuen Dienst, während der Monolith den Rest weiterhin bedient, und vergleichen Sie die Ergebnisse, bevor Sie vollständig umschalten.
4. Verschieben Sie die Datenhoheit zuletzt, nicht zuerst. Behalten Sie die Datenbank des Monolithen als massgebliche Quelle, bis sich der neue Dienst als stabil erwiesen hat, und übertragen Sie danach die Hoheit samt Nachladen der Daten.
5. Wiederholen Sie das, ein Fachbereich nach dem anderen, und mustern Sie Code im Monolithen aus, sobald sich eine Auslagerung stabilisiert hat.

Achten Sie auf das Anti-Muster, das die ganze Branche immer wieder neu entdeckt: Dienste, 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 Dienste für ein beliebiges Release im Gleichschritt ausgeliefert werden müssen. Wenn es die meisten sind, haben Sie einen verteilten Monolithen gebaut und fahren mit einer Zusammenführung besser. Vertragstests zwischen den Diensten und Feature Flags während des Rollouts fangen die meisten Regressionen ab, bevor sie den Produktivbetrieb erreichen.

Die Steuer auf verteilte Systeme: Was Microservices wirklich kosten

Die Prozessgrenze zu überschreiten ist nicht gratis, und die Rechnung fällt höher aus, als die meisten Teams einplanen. Die Schätzung des HLD Handbook beziffert die Steuer auf verteilte Systeme auf rund 30 bis 50 % der Entwicklungskapazität, sobald Sie Microservices produktiv betreiben. Diese Zahl deckt Werkzeuge für Beobachtbarkeit, Disziplin bei der Versionierung über Dienstgrenzen hinweg und die Belastung im Pikett ab, wenn Fehler über fünf Dienste hinweg statt in einem Stack-Trace gesucht werden müssen.

Diese Steuer zeigt sich in konkreten Posten:

• CI/CD-Pipelines pro Dienst statt einer gemeinsamen Pipeline.
• Verteiltes Tracing und zentrale Protokollierung, weil «schau in die Logs» jetzt heisst, fünf verschiedene Protokollströme zu prüfen.
• Eine Plattform- oder SRE-Funktion, die sich um gemeinsame Infrastruktur, Service Mesh und Deployment-Werkzeuge kümmert.
• Saga- und Outbox-Muster für Transaktionen, die früher ein einziger Datenbank-Commit waren.

Gegenmassnahmen gibt es, vor allem Plattform-Engineering, das die wiederkehrenden Teile automatisiert, und Muster für Beobachtbarkeit, die von Anfang an eingebaut und nicht erst nach einem Ausfall nachgerüstet werden. Werkzeuge, die wiederkehrende Betriebsarbeit übernehmen, können einen Teil dieser Steuer auffangen, sie aber nicht abschaffen. Wenn Ihr Team diese laufende Investition in die Plattform nicht stemmen kann, lautet die ehrliche Antwort: monolithisch bleiben, oder modular, bis es geht.

Wie Ampersand diesen Entscheid mit Kund:innen angeht

Ein erfahrenes Entwicklungsteam behandelt das zuerst als organisatorische und erst danach als technische Frage, denn genau dort gehen die meisten Entscheide zur Auslagerung schief. In einem Mandat mit einer wachsenden Plattform und Dutzenden internen Werkzeugen bestand der Ansatz darin, sich auf eine modulare Architektur zu konzentrieren, statt in Dienste zu zersplittern, für deren Betrieb die Leute fehlten. Weil ab dem ersten Gespräch erfahrene Personen dabei waren, wurde das Migrationsrisiko benannt, bevor Code geschrieben wurde, und nicht erst, als eine Neuentwicklung ins Stocken geriet. Die laufende monatliche Betreuung hielt das System danach gesund, ohne dass es ein eigenes Plattformteam brauchte, das die Kundschaft gar nicht hatte.

Warum «Monolith zuerst» dem Hype der Branche weiterhin überlegen ist

Die verbreitete Meinung zu diesem Thema ist durch einen Überlebensirrtum verzerrt. Alle erinnern sich an Netflix und Amazon, die an Konferenzen über Microservices sprachen. Niemand erinnert sich an die Hunderte von Teams, welche die Architektur kopierten, ohne den Verkehr, die Leute oder die Investition in die Plattform, die es dafür braucht. Amazon startete nicht mit Microservices. Das Unternehmen wurde nach Jahren mit den Wachstumsschmerzen eines Monolithen dazu, und erst, als die Organisation eine einzige auslieferbare Einheit wirklich überwachsen hatte.

Die Lücke, die mir immer wieder begegnet, liegt zwischen dem, was Microservices versprechen, und dem, was Teams personell tatsächlich betreiben können. Ein Startup mit 20 Personen, das neun Dienste einführt, kauft keine Skalierbarkeit ein, sondern neun Dinge, die gepatcht, überwacht und im Pikett bedient werden müssen, meist ohne dass jemand ausschliesslich dafür zuständig wäre. Die Steuer auf verteilte Systeme fragt nicht um Erlaubnis. Sie zeigt sich in langsamerer Lieferung von Funktionen innerhalb von zwei Quartalen, und zwar fast immer.

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

, Davide Morotti

Holen Sie sich ein ehrliches Architektur-Review, bevor Sie etwas aufteilen

Ampersand Labs ist die Alternative dazu, sich durch einen Entscheid über die Auslagerung zu raten: Erfahrene Entwickler:innen sehen sich Ihre tatsächliche Codebasis und Ihre Teamstruktur an, bevor sie überhaupt etwas empfehlen, statt einfach auf die gerade angesagte Architektur zu setzen. Das ist wichtig, weil die Kosten eines Fehlentscheids nicht theoretisch sind. Teams, die zu früh auslagern, zahlen im folgenden Jahr die Steuer auf verteilte Systeme, statt Funktionen zu liefern.

Ein Architektur-Review kann Ihre fachlichen Grenzen, die Reife Ihrer CI/CD und die tatsächliche Kapazität Ihres Teams für Plattformarbeit prüfen und danach einen modularen Monolithen, eine klar abgegrenzte Migration oder gezielte Auslagerung einzelner Dienste empfehlen, dort wo die Fakten das hergeben. Für Teams, die diesen Punkt bereits hinter sich haben, kann die laufende monatliche Betreuung den Betriebsaufwand abdecken, den Microservices verursachen, ohne dass Sie ein komplettes Plattformteam anstellen müssen. Weil ab dem ersten Gespräch erfahrene Personen 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?

Keiner der beiden Ansätze ist grundsätzlich besser. Monolithen liegen bei kleineren Teams und Produkten in einer frühen Phase vorne, während sich Microservices auszahlen, sobald eine Organisation einem gemeinsamen Release-Zyklus entwachsen ist und die nötige Plattformarbeit personell abdecken kann.

Läuft Amazon monolithisch oder auf Microservices?

Amazon läuft heute auf Microservices, startete aber als Monolith und migrierte über Jahre schrittweise, während die Entwicklungsorganisation und der Verkehr wuchsen. Es war keine Entwurfsentscheidung vom ersten Tag an.

Was ist ein Beispiel für einen Monolithen?

Eine typische E-Commerce-Anwendung mit einer Codebasis, die Produktkatalog, Bestellabschluss und Benutzerkonten auf einer einzigen gemeinsamen Datenbank abbildet, ist ein klassischer Monolith, und so beginnen die meisten erfolgreichen Produkte.

Welches sind die drei Arten von Microservices?

Microservices werden üblicherweise nach Funktion gruppiert: Fachdienste, die eine bestimmte Geschäftslogik besitzen (etwa Abrechnung oder Lagerbestand), Integrationsdienste, die externe Systeme anbinden, sowie Infrastruktur- oder Plattformdienste (etwa ein API-Gateway), welche die übrigen unterstützen.

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

Die meisten Teams unter rund 30 Entwickler:innen sollten standardmässig einen modularen Monolithen wählen, weil sie selten die Leute haben, um die Arbeit an Plattform und Beobachtbarkeit abzudecken, die Microservices verlangen.

Empfohlen

• Atelier Crincoli: Die ganze Goldschmiede-Werkstatt in einem System, damit kein Stück und kein Termin verloren geht.
• Interim CTO Zürich, Tech Lead auf Mandats- & Teilzeitbasis
• Habitects AG: Verantwortung für die Technik einer Plattform für Badsanierungen, bis über eine Fusion hinaus.
• Migration von Altsystemen & Replatforming Zürich