Beim Vergleich Microservices vs Monolith geht es um eine Frage. Teilen Sie Ihre Anwendung in viele unabhängige Dienste oder halten Sie sie als eine Einheit zusammen? Viele erfahrene Architekten raten, mit einem Monolithen zu starten. Microservices lohnen sich, wenn Größe, Teams und Betrieb sie tragen. So treffen Sie die Entscheidung für Ihre Webanwendung.

Microservices vs Monolith: Was ist der Unterschied?

Eine monolithische Architektur baut und betreibt eine Anwendung als eine Einheit. Microservices zerlegen dieselbe Anwendung in kleine Dienste, die unabhängig voneinander laufen. Einen Monolithen liefern Sie als Ganzes aus, Microservices einzeln.

Wie lautet die kurze Antwort?

  • Ein Monolith läuft als ein Prozess und wird als Ganzes gebaut und ausgeliefert.
  • Microservices laufen als eigene Prozesse und lassen sich einzeln ausliefern.
  • Dazwischen liegt der modulare Monolith. Er trennt Module klar, liefert aber weiter als eine Einheit aus.

Woher stammen die Begriffe?

Der Begriff Monolith stammt aus der Unix-Welt und beschreibt Systeme, die zu groß werden. Martin Fowler und James Lewis beschrieben 2014 den Microservice-Stil. Sie verstehen darunter eine Anwendung als Suite kleiner Dienste, die je in einem eigenen Prozess laufen und über leichtgewichtige Mechanismen kommunizieren. Eine formale Definition gibt es laut den Autoren nicht, nur gemeinsame Merkmale.

Was zeichnet die monolithische Architektur aus?

Alle Funktionen liegen in einer Codebasis und in einem Deployment. Einen Monolithen betreiben Sie einfacher als viele einzelne Dienste. Das gilt vor allem am Anfang eines Projekts.

Was ist ein Monolith?

Fowler und Lewis beschreiben den typischen Monolithen als serverseitige Anwendung. Sie verarbeitet Anfragen, führt die Fachlogik aus und liest Daten aus einer gemeinsamen Datenbank. Alles läuft in einem Prozess. Jede Änderung erfordert einen neuen Build und ein neues Deployment der gesamten Anwendung.

Welche Stärken hat ein Monolith?

Sie können einen Monolithen auf dem Entwicklerrechner starten und testen. Mit einer Deployment-Pipeline liefern Sie Änderungen kontrolliert in die Produktion. Zum Skalieren starten Sie mehrere Instanzen hinter einem Load Balancer. Aufrufe innerhalb eines Prozesses sind außerdem günstiger als Aufrufe über das Netzwerk.

Wo stößt ein Monolith an Grenzen?

Mit wachsender Größe hängen die Änderungszyklen zusammen. Eine kleine Änderung erfordert den Build und das Deployment der gesamten Anwendung. Die modulare Struktur lässt sich oft nur mit Mühe halten. Skalieren können Sie nur die ganze Anwendung und nicht den Teil mit dem höheren Bedarf.

Wie sich das im Alltag zeigt, beschreibt der Beitrag Von monolithisch zu modular. Typische Symptome sind lange Build-Zyklen, unbeabsichtigte Abhängigkeiten und eingeschränkte Team-Autonomie.

Was zeichnet Microservices aus?

Eine Microservice-Architektur teilt eine Anwendung in kleine Dienste, die entlang von Geschäftsfähigkeiten entstehen. Jeder Dienst läuft in einem eigenen Prozess und lässt sich unabhängig ausliefern. Microservices können Komplexität in die Verbindungen zwischen Diensten verlagern.

Welche Merkmale haben Microservices?

Fowler und Lewis nennen neun gemeinsame Merkmale. Dazu gehören die folgenden.

  • Die Anwendung besteht aus Diensten statt aus Bibliotheken im selben Prozess.
  • Die Dienste folgen Geschäftsbereichen und nicht technischen Schichten.
  • Jeder Dienst verwaltet seine Daten selbst.
  • Dienste sprechen über einfache Mechanismen wie HTTP-APIs oder Nachrichten miteinander.
  • Ein automatisierter Prozess liefert jeden Dienst einzeln aus.
  • Die Anwendung verkraftet den Ausfall einzelner Dienste.

Welche Stärken bringen Microservices mit?

Dienste lassen sich einzeln ausliefern. Eine Änderung erfordert in der Regel nur das Deployment des betroffenen Dienstes. Jeder Dienst bildet eine feste Modulgrenze, und verschiedene Teams können verschiedene Dienste verantworten. Dienste dürfen in unterschiedlichen Programmiersprachen entstehen. Skalieren lässt sich gezielt der Dienst mit dem höheren Bedarf.

Wie groß ist ein Microservice?

Eine feste Größe gibt es nicht. Fowler und Lewis sehen in der Praxis eine große Bandbreite. Die größten Dienste folgen der Idee des Two-Pizza-Teams, also einem Team mit höchstens einem Dutzend Personen. Daneben gibt es Setups, in denen ein Team von etwa sechs Personen mehrere Dienste betreut. Entscheidend ist die Verantwortung für einen Geschäftsbereich und nicht die Zeilenzahl.

Wie unterscheiden sich beide im Vergleich?

Der größte Unterschied liegt nicht im Code, sondern im Betrieb und in der Organisation. Der größte Unterschied liegt im Betrieb und in der Teamorganisation. Die Tabelle fasst die wichtigsten Kriterien zusammen.

Kriterium Monolith Microservices
Struktur Eine Anwendung, Module im selben Prozess Viele Dienste, jeder in einem eigenen Prozess
Auslieferung Die gesamte Anwendung Jeder Dienst einzeln über automatisierte Pipelines
Datenhaltung Meist eine gemeinsame Datenbank Jeder Dienst verwaltet seine Daten selbst
Konsistenz Transaktionen über die Datenbank Abstimmung ohne verteilte Transaktionen, oft mit eventueller Konsistenz
Skalierung Die ganze Anwendung als Einheit Gezielt je Dienst
Fehlerbehandlung Aufrufe im Prozess Jeder Aufruf kann scheitern und braucht eine Reaktion
Teams Häufig nach Technikschichten getrennt Nach Geschäftsbereichen in funktionsübergreifenden Teams
Betrieb Eine Anwendung überwachen Viele Dienste mit eigenem Monitoring

Wie unterscheiden sich Deployment und Betrieb?

Einen Monolithen liefern Sie als Ganzes aus. Dafür genügt eine Pipeline. Bei Microservices brauchen Sie viele Pipelines und eine starke Automatisierung. Fowler und Lewis geben zu, dass mehr Dienste in komplexeren Topologien schwerer auszuliefern sind. Kleine Schritte, Feature Flags und eine saubere Pipeline helfen in beiden Fällen, wie der Beitrag zu Continuous Deployment in der Praxis zeigt.

Wie unterscheiden sich Daten und Konsistenz?

Ein Monolith nutzt meist eine gemeinsame Datenbank und Transaktionen. Das sichert die Konsistenz, koppelt die Teile aber zeitlich eng. Microservices verwalten ihre Daten je Dienst. Verteilte Transaktionen sind schwer umzusetzen, deshalb koordinieren Teams ohne Transaktionen und akzeptieren zunächst eine eventuelle Konsistenz. Fehler gleichen sie durch Ausgleichsoperationen aus.

Wie unterscheiden sich Skalierung und Ausfallsicherheit?

Beim Monolithen skalieren Sie die gesamte Anwendung. Bei Microservices skalieren Sie nur den Dienst mit dem höheren Bedarf. Dafür kann jeder Aufruf zwischen Diensten scheitern. Die Anwendung muss den Ausfall einzelner Dienste tolerieren. Fowler und Lewis nennen das einen Nachteil gegenüber dem Monolithen, weil es zusätzliche Komplexität bedeutet.

Welche Microservices Nachteile gibt es?

Die Microservices Nachteile fehlen in vielen Vergleichen. Fowler nennt sie die Microservice Premium. Sie erhöht Kosten und Risiko eines Projekts und bringt es laut Fowler oft in ernsthafte Schwierigkeiten. Sein Microservices Guide sammelt die Details. Die Nachteile treffen vor allem Teams ohne reife Automatisierung und Betriebserfahrung.

Warum steigt die Komplexität?

Aufrufe über das Netzwerk sind teurer als Aufrufe im Prozess. Deshalb brauchen Schnittstellen eine gröbere Granularität. Verantwortung zwischen Diensten zu verschieben ist schwerer, weil Sie Prozessgrenzen überschreiten. Fowler und Lewis warnen außerdem vor einem Effekt. Setzen sich die Komponenten nicht sauber zusammen, wandert die Komplexität nur in die Verbindungen.

Welche Folgen hat die verteilte Datenhaltung?

Jeder Dienst besitzt seine Daten, daher gibt es keine übergreifenden Transaktionen. Teams arbeiten mit eventueller Konsistenz und Ausgleichsoperationen. Das ist laut Fowler und Lewis für viele Teams eine neue Herausforderung. Es entspricht aber oft der Geschäftspraxis, solange Korrekturen weniger kosten als verlorene Aufträge.

Welche Voraussetzungen brauchen Teams?

Fowler sagt, dass Sie ohne bestimmte Grundkompetenzen nicht auf Microservices setzen sollten. Als Hürde nennt er unter anderem ein reifes Betriebsteam für viele regelmäßig neu ausgelieferte Dienste. Dazu passt die Beobachtung von Fowler und Lewis, dass erfolgreiche Teams stark auf Continuous Delivery und Automatisierung setzen. Auch die Teamstruktur muss zur Architektur passen, wie der Beitrag zur Architektur-Modernisierung zeigt.

Was lehrt der Fall Prime Video?

Das Prime-Video-Team beschrieb 2023, wie es einen Teildienst zur Überwachung von Videostreams zu einem Monolithen zusammenführte. Der erste Aufbau nutzte verteilte Serverless-Komponenten. Laut Team sanken die Infrastrukturkosten danach um über 90 %, und der Dienst skalierte besser. Als Ursachen nennt der Bericht bei InfoQ unter anderem Kosten durch den Datenaustausch zwischen den Komponenten und Grenzen bei der Orchestrierung.

Der Dienst ist nur ein Baustein der Plattform und kein Beweis gegen Microservices insgesamt. Der Fall zeigt aber, dass eine zu feine Zerlegung teuer werden kann.

Wann ist welche Architektur sinnvoll?

Die Wahl hängt von Teamgröße, Betriebsreife und Anforderungen an die Skalierung ab. Starten Sie einfach und teilen Sie erst, wenn ein konkretes Problem es verlangt.

Wann reicht ein Monolith aus?

  • Ein kleines Team verantwortet die Anwendung.
  • Die Anforderungen an die Skalierung bleiben überschaubar und betreffen die Anwendung als Ganzes.
  • Sie haben noch keine Erfahrung mit dem automatisierten Betrieb vieler Dienste.
  • Das Produkt ist neu, und die Fachgrenzen sind noch unklar.

Fowler beobachtet bei Monolith First, dass fast alle erfolgreichen Microservice-Geschichten mit einem Monolithen begannen, der zu groß wurde. Er räumt ein, dass dieser Rat nicht ideal ist. Eine gute Schnittstelle im Prozess ist selten eine gute Service-Schnittstelle.

Wann lohnen sich Microservices?

  • Mehrere Teams arbeiten parallel und behindern sich an einer Codebasis.
  • Teile der Anwendung haben sehr unterschiedliche Anforderungen an die Skalierung.
  • Die Fachgrenzen sind klar und stabil.
  • Automatisierte Auslieferung und Betrieb sind eingespielt.

Wann passt ein modularer Monolith?

Der modulare Monolith trennt Module klar, liefert aber weiter als eine Einheit aus. Fowler und Lewis erwähnen den Rat, einen Monolithen modular zu halten und erst bei Bedarf zu teilen. Der Beitrag Von monolithisch zu modular nennt ihn einen pragmatischen Einstieg, der nicht sofort die Komplexität von Microservices mitbringt.

Wie gelingt der Umstieg vom Monolithen?

Der Umstieg gelingt schrittweise und nicht in einem Big Bang. Lösen Sie Teile schrittweise ab, statt alles auf einmal zu ersetzen. Das beschreibt das Strangler-Fig-Pattern, das Fowler als Strangler Fig Application eingeführt hat. Dabei wächst ein neues System langsam um das alte herum, bis dieses ersetzt ist.

Welche Schritte gehören zum Umstieg?

  1. Analysieren Sie die Codebasis und erkennen Sie die fachlichen Domänen.
  2. Erkennen und reduzieren Sie Abhängigkeiten.
  3. Definieren Sie Modulgrenzen und Schnittstellen.
  4. Passen Sie die Tests an die modulare Struktur an.
  5. Setzen Sie schrittweise um und starten Sie mit einem unkritischen Modul.
  6. Prüfen Sie getrennte Deployments als optionalen letzten Schritt.

Die Schritte stammen aus dem Beitrag Von monolithisch zu modular. Wie sich neue Teile mit Feature Flags und vertikalen Schnitten sicher ausliefern lassen, erklärt der Beitrag zu Continuous Deployment.

Welche Stolpersteine drohen bei der Migration?

Das größte Risiko beschreibt die Architektur-Modernisierung als „Death Valley der Migration“. Altes und neues System laufen dann parallel, sind eng verwoben, und keines funktioniert vollständig. Typisch sind doppelte Datenhaltung, Funktionen über mehrere Systeme verteilt und steigende Komplexität für die Entwickler.

Der Ausweg liegt in klaren Grenzen zwischen altem und neuem System. Die Integration läuft über definierte APIs und Events, nicht über geteilte Datenbanken. Wie Sie gewachsene Systeme dabei Schritt für Schritt entwirren, zeigt der Bereich Legacy-Software modernisieren.

Fazit

Microservices vs Monolith ist keine Glaubensfrage. Ein Monolith ist der einfachere Start und kann für viele Anwendungen ausreichen. Microservices lohnen sich, wenn mehrere Teams, unterschiedliche Skalierung und reifer Betrieb zusammenkommen. Der modulare Monolith verbindet beide Welten und erlaubt einen schrittweisen Weg.

Sie möchten Ihre Architektur einordnen oder den Umstieg planen? Vereinbaren Sie ein kostenloses Erstgespräch mit uns.

Häufige Fragen

Die richtige Antwort hängt immer vom Kontext Ihres Projekts ab.

Sind Microservices besser als ein Monolith?

Nein, nicht grundsätzlich. Fowler und Lewis berichten, dass viele Teams Microservices als überlegen erlebten und andere als Last, die die Produktivität bremst. Der Kontext entscheidet.

Ab welcher Teamgröße lohnen sich Microservices?

Eine feste Zahl gibt es nicht. Als Orientierung beschreiben Fowler und Lewis Dienste, die ein Team mit höchstens einem Dutzend Personen verantwortet. Wichtig ist, dass mehrere Teams ohne gegenseitige Blockaden arbeiten können.

Kann ein Monolith skalieren?

Ja. Sie starten mehrere Instanzen hinter einem Load Balancer. Dabei skalieren Sie die ganze Anwendung und nicht einzelne Teile.

Lässt sich ein Monolith später aufteilen?

Ja. Das gelingt schrittweise über einen modularen Aufbau und das Strangler-Fig-Pattern. Bei Laravel schaffen Packages gute Voraussetzungen für modulare Strukturen.

Quellen & weiterführende Literatur