Für die meisten Schweizer Unternehmen ist die Antwort klarer als die Debatte vermuten lässt: Unter 100 Entwicklern ist ein modularer Monolith in der Regel die bessere Wahl. Microservices rechtfertigen ihren erheblichen Mehraufwand erst dann, wenn Teams tatsächlich unabhängig voneinander skalieren und deployen müssen. Das ist keine Meinung, sondern eine Schlussfolgerung aus realen Kostendaten und dem Rückzug vieler Unternehmen von einer zu früh eingeführten Microservices-Architektur.
Die grundlegenden Unterschiede auf einen Blick:
- Monolith: Eine einzige, zusammenhängende Anwendung mit gemeinsamer Codebasis, einem Deployment-Prozess und einer Datenbank. Einfach zu entwickeln, einfach zu betreiben.
- Microservices: Viele kleine, unabhängige Services, die über Netzwerkschnittstellen kommunizieren. Jeder Service hat eigene Logik, eigene Datenbank, eigenes Deployment.
- Modularer Monolith: Klar getrennte Module innerhalb einer Anwendung, die über definierte Schnittstellen kommunizieren und bei Bedarf zu eigenständigen Services extrahiert werden können.
- Skalierung: Beim Monolithen skaliert immer die gesamte Anwendung. Bei Microservices lässt sich jeder Service einzeln skalieren.
- Teamorganisation: Microservices folgen Conway’s Law: Die Architektur spiegelt die Teamstruktur wider. Bei kleinen Teams erzeugt das unnötige Komplexität.
Wie sich Monolith und Microservices direkt unterscheiden
| Kriterium | Monolith | Modularer Monolith | Microservices |
|---|---|---|---|
| Architekturstil | Einheitliche Codebasis | Getrennte Module, ein Deployment | Viele unabhängige Services |
| Skalierbarkeit | Nur als Ganzes | Begrenzt modular | Jeder Service einzeln |
| Entwicklungskomplexität | Gering | Mittel | Hoch |
| Deployment | Ein Prozess | Ein Prozess | Viele Pipelines |
| Wartung | Einfach bei kleinen Teams | Gut handhabbar | Erfordert DevOps-Reife |
| Teamgröße | Unter 10 Entwickler | 10–100 Entwickler | Über 100 Entwickler |
| Infrastrukturkosten | Gering | Gering bis mittel | 3,75x bis 6x höher |
Was spricht für den Monolithen, und was dagegen?
Ein klassischer Monolith hat einen entscheidenden Vorteil: Er ist einfach. Ein Entwicklerteam arbeitet an einer Codebasis, ein Deployment-Prozess, ein Datenbankschema. Für Startups, MVPs und erste Produktversionen ist das oft genau richtig, weil Geschwindigkeit vor Architektur geht.
Die Betriebskosten sind deutlich geringer. Wo Microservices Platform Engineers, Service-Meshes und verteiltes Monitoring erfordern, reicht beim Monolithen oft ein einziger Operations-Ingenieur.
Aber: Mit wachsender Codebasis und mehr Entwicklern wird der Monolith zum Problem. Jede Änderung erfordert ein vollständiges Neu-Deployment. Ein Fehler in einem Modul kann die gesamte Anwendung lahmlegen. Und technische Schulden häufen sich schnell an, weil Modulgrenzen in einer gemeinsamen Codebasis leicht umgangen werden.
- Vorteile: schnelle Entwicklung, geringer Betriebsaufwand, einfaches Debugging, niedrige Infrastrukturkosten
- Nachteile: begrenzte Skalierbarkeit einzelner Komponenten, wachsende Komplexität bei vielen Entwicklern, erschwertes unabhängiges Deployment
Was bringen Microservices wirklich, und was kosten sie?
Microservices ermöglichen echte Teamautonomie. Jedes Team besitzt seinen Service vollständig: Entwicklung, Deployment, Skalierung. Das ist bei großen Organisationen mit über 100 Entwicklern ein echter Vorteil, weil Conway’s Law die Architektur ohnehin erzwingt.
Dazu kommt technologische Freiheit. Ein Service kann in Python geschrieben sein, ein anderer in Java. Für ML-Workloads oder regulatorisch isolierte Komponenten wie Payment-Processing ist das relevant.
„Microservices verursachen Kosten für die Produktivität, die nur in komplexeren Systemen ausgeglichen werden können. Wenn Sie die Komplexität Ihres Systems mit einer monolithischen Architektur bewältigen können, sollten Sie keine Microservices verwenden.“
Martin Fowler, Microservice Trade-Offs
Der Preis ist hoch. Infrastrukturkosten liegen bei Microservices 3,75x bis 6x über dem Monolith-Äquivalent. Konkret: ein Enterprise-Monolith bei rund 15.000 Euro monatlich, eine vergleichbare Microservices-Architektur bei 40.000 bis 65.000 Euro. Dazu kommen 2–4 Platform Engineers, deren Jahresgehälter die Infrastrukturkosten oft übersteigen.
- Vorteile: unabhängige Skalierung, Teamautonomie, technologische Vielfalt, isolierte Fehlertoleranz
- Nachteile: erheblicher Betriebsaufwand, Netzwerkkomplexität, aufwendiges Monitoring, teure Infrastruktur, Continuous Delivery als Pflicht
Wie sich die Architekturlandschaft seit 2009 verändert hat
Netflix hat 2009 den Wechsel zu Microservices vollzogen, weil der Monolith mit der Nachfrage nicht mehr mithalten konnte. Das war der Startschuss für eine breite Bewegung. Zehn Jahre lang galt: Wer modern ist, baut Microservices.
„42 Prozent der Organisationen, die Microservices adoptiert haben, konsolidieren Services wieder. Nicht zurück zum Monolithen der 2000er Jahre, aber zu größeren, besser abgegrenzten Deployment-Einheiten.“
CNCF-Survey 2025, zitiert nach cloudmagazin.com
Amazon Prime Video ist das bekannteste Beispiel der Gegenbewegung: Die Migration eines Video-Qualitätsanalyse-Services von Microservices zurück zu einem einzelnen Prozess hat 90 % der Infrastrukturkosten eingespart. Der Grund war simpel: Alle Komponenten verarbeiteten denselben Video-Stream. Unabhängige Skalierung war nie nötig. 2026 ist die Debatte keine ideologische mehr.
Welche Architektur passt zu Ihrem Schweizer Unternehmen?
Die Entscheidung hängt von drei Faktoren ab: Teamgröße, Skalierungsbedarf und operative Reife. Für Schweizer IT-Verantwortliche lässt sich das auf konkrete Schwellenwerte herunterbrechen.
- Unter 10 Entwickler: Klassischer Monolith. Geschwindigkeit vor Architektur. MVP und erste Produktversionen profitieren von einfachen Strukturen.
- 10–100 Entwickler: Modularer Monolith. Module kommunizieren über definierte Schnittstellen, nutzen getrennte Datenbank-Schemas und können bei echtem Bedarf extrahiert werden.
- Über 100 Entwickler: Microservices, aber nur wenn unabhängige Skalierung tatsächlich gebraucht wird oder regulatorische Isolation es erzwingt.
Profi-Tipp: Beginnen Sie mit einem modularen Monolithen und extrahieren Sie Services erst dann, wenn ein Modul nachweislich unabhängig skaliert werden muss. Das spart Kosten und bewahrt Sie vor dem gefährlichsten Antipattern: dem Distributed Monolith.
Für den DACH-Mittelstand mit 10–50 Entwicklern liefert der modulare Monolith nach aktuellem Stand 90 % der architektonischen Vorteile zu einem Bruchteil der Kosten. Domain Driven Design und klar definierte Bounded Contexts helfen dabei, die Modulgrenzen von Anfang an sauber zu ziehen, ohne sofort den Overhead verteilter Systeme zu zahlen.
Wie Outwork Schweizer Unternehmen bei der Architekturwahl begleitet
Outwork berät Schweizer Unternehmen bei genau dieser Entscheidung: welche Architektur zum aktuellen Reifegrad passt und wie der Übergang aussieht, wenn Wachstum eine Anpassung erfordert. Mit über 1.200 aktiven Kunden kennt Outwork die typischen Fallstricke, die entstehen, wenn Teams zu früh auf Microservices setzen oder zu lange an einem gewachsenen Monolithen festhalten.
Profi-Tipp: Lassen Sie vor jeder Architekturentscheidung eine Kosten-Nutzen-Analyse durchführen, die Infrastruktur, Personalaufwand und Entwicklungsgeschwindigkeit gemeinsam bewertet. Outwork bietet dafür strukturierte Architekturberatung mit lokalem Schweizer Know-how.
Ob Sie eine bestehende Anwendung migrieren oder ein neues Projekt aufsetzen: Outwork begleitet Sie von der Konzeption bis zum Betrieb. Die Leistungen von Outwork umfassen Architekturberatung, Softwareentwicklung und den Aufbau skalierbarer Systeme für Schweizer Unternehmen jeder Größe.
Wie verändert die Architekturwahl das Testen?
Beim Monolithen laufen alle Tests in einer Umgebung. Integration, Unit-Tests und End-to-End-Tests greifen auf dieselbe Codebasis zu, was das Setup vereinfacht. Fehler lassen sich mit einem einzigen Debugger verfolgen.
Bei Microservices wird Testen deutlich aufwendiger. Jeder Service braucht eigene Tests, und Integrationstests müssen Netzwerkaufrufe zwischen Services simulieren oder echte Serviceinstanzen hochfahren. Contract-Tests wie Pact helfen dabei, Schnittstellenkompatibilität zwischen Services sicherzustellen. Ohne disziplinierte CI/CD-Pipelines und automatisierte Testabdeckung wird die Qualitätssicherung schnell zum Engpass.
Welche Fehler passieren bei der Microservices-Migration am häufigsten?
Der häufigste Fehler ist der Distributed Monolith: Services, die zwar über das Netzwerk kommunizieren, aber trotzdem gemeinsam deployed werden müssen und keine echte Autonomie haben. Das vereint die Komplexität von Microservices mit den Einschränkungen des Monolithen.
Viele Unternehmen unterschätzen den Migrationsaufwand erheblich. Bounded Contexts lassen sich in einem gewachsenen System schwer nachträglich definieren. Martin Fowler empfiehlt deshalb die „Monolith First“-Strategie: Zuerst einen gut strukturierten Monolithen bauen, Modulgrenzen verstehen, dann schrittweise extrahieren.
Weitere typische Fallstricke: fehlende Standardisierung bei Logging und Monitoring, unklare Service-Ownership und das Fehlen einer Plattform-Infrastruktur, bevor die ersten Services in Produktion gehen.
Sicherheit: Was unterscheidet beide Architekturen?
Ein Monolith hat eine einzige Angriffsfläche. Sicherheitskontrollen lassen sich zentral implementieren, Authentifizierung und Autorisierung greifen an einem Punkt. Das vereinfacht Audits und Compliance-Nachweise erheblich.
Bei Microservices multipliziert sich die Angriffsfläche mit jedem Service. Jede Netzwerkverbindung zwischen Services ist ein potenzieller Angriffspunkt. Zero-Trust-Architekturen, gegenseitige TLS-Authentifizierung und feingranulare Zugriffskontrollen sind Pflicht. Für regulatorisch sensible Bereiche wie Payment oder Gesundheitsdaten kann die physische Isolation einzelner Services aber auch ein Vorteil sein, weil PCI-DSS-Compliance auf einen klar abgegrenzten Service beschränkt bleibt.
Wichtige Erkenntnisse
Für Schweizer Unternehmen unter 100 Entwicklern ist der modulare Monolith in der Regel die wirtschaftlich und architektonisch überlegene Wahl gegenüber einer vollständigen Microservices-Architektur.
| Thema | Details |
|---|---|
| Architekturwahl nach Teamgröße | Unter 10 Entwickler: Monolith; 10–100: modularer Monolith; über 100: Microservices bei echtem Bedarf. |
| Kostenunterschied | Microservices verursachen in der Regel deutlich höhere Infrastrukturkosten als ein äquivalenter Monolith. |
| Rückkonsolidierungstrend | 42 % der Unternehmen, die zuvor auf Microservices umgestiegen sind, konsolidieren Services wieder in monolithische oder modulare Strukturen zurück. |
| Migrationsstrategie | Schrittweise Extraktion einzelner Services aus einem modularen Monolithen ist sicherer als ein Big-Bang-Wechsel. |
| Outwork als Partner | Outwork begleitet Schweizer Unternehmen bei Architekturentscheidungen mit lokalem Know-how und über 1.200 aktiven Kunden. |
Architektur ist keine Ideologie
Die Microservices-Debatte hat lange zu viel Ideologie und zu wenig Pragmatismus produziert. Wer 2026 noch pauschal empfiehlt, alles in Microservices aufzubrechen, ignoriert die Kostendaten und die Rückkehrbewegung, die sich in der Branche klar abzeichnet.
Was wirklich zählt: Passt die Architektur zum Problem, das sie lösen soll? Ein Payment-Service, der 50-mal mehr Rechenleistung braucht als der Rest der Anwendung, ist ein legitimer Kandidat für Extraktion. Eine Anwendung mit 15 Entwicklern, die „modern“ wirken will, ist es nicht.
Für den Schweizer Mittelstand bedeutet das konkret: Modulare Monolithen mit sauberen Bounded Contexts und Domain Driven Design als Grundlage. Microservices dann, wenn Conway’s Law die Entscheidung erzwingt, nicht wenn ein Architekt sie empfiehlt, weil Netflix sie nutzt. Die Frage ist nie Monolith oder Microservices als Prinzip. Die Frage ist immer: Welches Problem soll die Architektur lösen?
