Wann ein Monolith die richtige Antwort ist

Die Frage hinter dem Kapitel

Die Stile in diesem Kapitel werden alle als eine Einheit deployt. Kapitel 6 trägt dieselben Fragen über ein Netzwerk, wo jeder Aufruf fehlschlagen, langsam sein oder doppelt ankommen kann. Bevor wir diese Linie überschreiten, lohnt es sich, direkt zu fragen: Wann ist ein Monolith die richtige Antwort? Einen großen Teil der 2010er-Jahre lautete die Standardantwort der Branche „selten“, und viele Teams teilten junge Systeme in Microservices auf, weil große, berühmte Unternehmen es so gemacht hatten. Ein Jahrzehnt Erfahrung hat zu einer ausgewogeneren Sicht geführt, und dieser Abschnitt legt sie dar.

Das Wort Monolith erfordert Sorgfalt. Wie Abschnitt 5.1 erklärt hat, beschreibt es das Deployment (eine Einheit, die zusammen gebaut, getestet und ausgeliefert wird), nicht die innere Qualität. Ein Monolith kann ein gut strukturiertes modulares System oder ein Big Ball of Mud sein, und dasselbe gilt für eine Menge von Services. Viele der Probleme, die man Monolithen anlastet, sind in Wahrheit Probleme mangelnder Modularität, und wer ein schlecht modularisiertes System in Services aufteilt, erhält einen verteilten Big Ball of Mud, und der ist schlimmer.

MonolithFirst und die Microservice Premium

Im Mai 2015 beschrieb Martin Fowler die Microservice Premium: Microservices bringen eigene, reale Kosten mit sich (automatisiertes Deployment vieler Einheiten, Monitoring, Umgang mit Teilausfällen, Eventual Consistency, versionierte APIs zwischen Teams), und diese Kosten bremsen ein Team, solange das System nicht komplex genug ist, damit Microservices sie wieder einspielen. Sein Rat lautete, standardmäßig auf einen einzigen, gut modularisierten Monolithen zu setzen und erst dann zu Microservices zu wechseln, wenn die Komplexität es verlangt.

Einen Monat später, in einem Artikel mit dem Titel MonolithFirst (Juni 2015), ergänzte er zwei Beobachtungen aus den Projekten, die er gesehen hatte: Fast alle erfolgreichen Microservice-Systeme hatten als Monolith begonnen, der zu groß wurde und dann aufgeteilt wurde, und fast alle von Grund auf als Microservices gebauten Systeme waren in ernste Schwierigkeiten geraten. Ein Grund ist, dass gute Servicegrenzen schwer zu finden sind, bevor man die Domäne versteht, und eine falsche Grenze zwischen Services weit teurer zu verschieben ist als eine falsche Grenze zwischen Modulen. Er beschrieb mehrere Wege: einen Monolithen bauen und später Services an seinen Rändern abtrennen; einen bewusst wegwerfbaren Monolithen bauen; oder mit wenigen grobgranularen Services beginnen und sie weiter aufteilen, sobald sich die Grenzen gefestigt haben.

Der Majestic Monolith und die Gegenposition

Im Februar 2016 veröffentlichte David Heinemeier Hansson, der Schöpfer von Ruby on Rails, „The Majestic Monolith“ im Blog Signal v. Noise. Er beschrieb Basecamp, damals von einem Team aus etwa einem Dutzend Programmierern gebaut, als eine integrierte Anwendung, die Web-, Mobil-, Desktop- und E-Mail-Clients bedient, und argumentierte, kleine Teams sollten auf einen gut gemachten Monolithen setzen, statt die Architektur von Organisationen mit Tausenden Engineers zu kopieren. Sein Kernsatz lautete Don't distribute your computing!, es sei denn, man muss es wirklich.

Nicht alle Fachleute sind sich einig. Ebenfalls im Juni 2015 argumentierte Stefan Tilkov auf Fowlers Website in „Don't start with a monolith“, dass es oft schwieriger als erwartet ist, einen Monolithen später aufzuteilen, weil seine Teile über gemeinsame Bibliotheken, Domänenobjekte und die Datenbank eng zusammenwachsen. Ist das System eindeutig groß genug, um getrennte Teile zu rechtfertigen, und ist die Domäne gut verstanden, empfahl er, von Anfang an getrennte Subsysteme zu entwerfen. Die beiden Positionen liegen weniger weit auseinander, als es klingt: Beide sagen, dass die Grenzen das Schwierige sind, und ein Monolith, dessen Module vom ersten Tag an durchgesetzt werden (Abschnitt 5.3), beantwortet den Großteil von Tilkovs Bedenken.

Reale Fälle weisen in beide Richtungen, haben aber eine gemeinsame Lehre. Segment beschrieb 2018, wie es mehr als 140 kleine Services wieder zu einem einzigen Service zusammengelegt hatte, nachdem Betriebsaufwand und auseinanderlaufende gemeinsame Bibliotheken die Auslieferung gebremst hatten; Amazon Prime Video verlagerte 2023 eine Monitoring-Workload von verteilten Serverless-Komponenten in einen einzigen Prozess (siehe Abschnitt 1.3). Ebenso gewinnen Organisationen mit Hunderten von Teams, wie die Großfälle aus Abschnitt 6.3, durch Services echte Unabhängigkeit. Die Lehre heißt Passung: Der Deployment-Stil muss zur Organisation, zur Reife der Domäne und zu den geforderten Qualitäten passen.

Wann ein Monolith die richtige Antwort ist

Ein kleines Team. Bei einem bis wenigen Teams sind die Kommunikationskosten, die Microservices beseitigen, gering, ihre Betriebskosten aber dieselben wie für eine große Organisation. Ein Monolith erlaubt es allen, das ganze System zu verstehen und zu ändern.

Eine unsichere Domäne oder ein frühes Produkt. Solange Sie noch herausfinden, was das Produkt ist, werden sich Grenzen verschieben. Eine Grenze zwischen Modulen zu verschieben ist ein Refactoring; sie zwischen Services zu verschieben ist eine Migration mit Daten, APIs und Deployments.

Hohe Konsistenzanforderungen. Eine einzige Datenbanktransaktion über Bestellungen, Zahlungen und Lagerbestand ist in einem Monolithen einfach und korrekt. Über Services hinweg braucht sie Sagas, Outboxes und Kompensation (Abschnitt 6.7).

Begrenzte Betriebskapazität. Jeder Service braucht seine eigene Pipeline, sein Monitoring, sein Alerting, seine Skalierungsregeln und Bereitschaftswissen. Ein Team ohne Plattform dafür verbringt seine Zeit mit Klempnerarbeit.

Performancekritische Interaktionen. Prozessinterne Aufrufe dauern Nanosekunden bis Mikrosekunden; Netzwerkaufrufe dauern Millisekunden und können fehlschlagen. Gesprächige Interaktionen zwischen Teilen der Domäne sind innerhalb eines Prozesses weit günstiger.

In all diesen Fällen ist die empfohlene Form ein modularer Monolith, kein unstrukturierter. Er hält die Option offen, Services herauszulösen, wie Abschnitt 5.3 erklärt.

Einen Monolithen skalieren

Eine verbreitete Annahme lautet, Monolithen könnten nicht skalieren. Sie skalieren weiter, als die meisten Systeme es je brauchen, mithilfe der X-Achse des von Martin Abbott und Michael Fisher beschriebenen Scale Cube (viele identische Kopien betreiben) zusammen mit einigen Standardtaktiken. Kapitel 9 behandelt jede davon ausführlich (Abschnitt 9.1).

Horizontale Replikate hinter einem Load Balancer. Betreiben Sie viele identische Kopien der Anwendung und verteilen Sie die Anfragen auf sie. Das funktioniert nur, wenn die Anwendung zustandslos ist: Sessions, hochgeladene Dateien und Caches müssen in gemeinsamen Speichern liegen, damit jedes Replikat jede Anfrage bedienen kann (Abschnitt 9.2). Es bringt außerdem Redundanz: Fällt ein Replikat aus, steht der Dienst nicht mehr still.

Read Replicas. Die meisten Systeme lesen weit mehr, als sie schreiben. Datenbank-Read Replicas kopieren die Änderungen des Primärsystems und bedienen Lesezugriffe wie Bestellhistorie und Berichte, um den Preis der Replikationsverzögerung: Ein Replikat kann einen Sekundenbruchteil hinterherhinken (Abschnitt 7.4).

Caching. Speisekarten, Produktseiten und Konfiguration ändern sich selten und werden ständig gelesen; sie im Arbeitsspeicher oder in einem gemeinsamen Cache vorzuhalten nimmt der Datenbank den Großteil der Last ab (Abschnitt 7.6). Statische Assets kommen in ein CDN.

Background Worker. Langsame oder stoßweise Arbeit (E-Mails, PDF-Rechnungen, Importe, Auszahlungen) kommt in eine Queue und wird von Worker-Prozessen abgearbeitet. Worker laufen meist mit derselben Codebasis und einem anderen Startbefehl, sodass das System eine Codebasis bleibt, die Web- und die Worker-Rolle aber getrennt skalieren (Abschnitt 9.3).

Größere Maschinen und Partitionierung. Vertikale Skalierung der Datenbank ist oft der einfachste nächste Schritt. Bei sehr großen Systemen lassen sich die Daten nach Mandant oder Region partitionieren, mit einer vollständigen Kopie des Monolithen pro Partition (die Z-Achse des Scale Cube). Stack Overflow ist ein bekanntes Beispiel dafür, wie weit ein weitgehend monolithisches Design reichen kann: Laut dem eigenen Bericht seiner Engineers verarbeiteten seine Load Balancer an einem Tag im Februar 2016 etwa 209 Millionen HTTP-Anfragen, wobei die zentrale Q&A-Anwendung (eine mandantenfähige Anwendung für alle Q&A-Sites) auf neun primären Webservern lief und vier SQL-Server-Maschinen das gesamte Netzwerk bedienten.

Anzeichen, dass es Zeit für eine Aufteilung ist

Eine Aufteilung sollte eine Reaktion auf Belege sein, nicht auf Moden. Die Anzeichen, dass eine Deployment-Einheit zur Einschränkung geworden ist, sind überwiegend organisatorischer und betrieblicher Art:

Konkurrenz zwischen Teams. Mehrere Teams ändern denselben Code und warten aufeinander; Merge-Konflikte, Abstimmungsmeetings und von anderen Teams verursachte kaputte Builds nehmen zu, wenn die Organisation wächst. Sind die Module bereits gut abgegrenzt und hält die Konkurrenz an, fehlt womöglich die Unabhängigkeit im Deployment.

Deployment-Warteschlangen. Releases werden zu Release-Zügen gebündelt, weil jede Änderung einen erneuten Test des ganzen Systems erfordert; eine kleine Korrektur wartet tagelang hinter fremder Arbeit; die fehlgeschlagene Änderung eines Teams blockiert das Release aller.

Stark abweichende Skalierungs- oder Verfügbarkeitsanforderungen. Ein Modul (etwa die Echtzeit-Kurierverfolgung) braucht zur Spitzenzeit das Fünfzigfache der Kapazität des Rests oder muss laufen, wenn alles andere ausgefallen ist. Den ganzen Monolithen für die Anforderungen eines Moduls zu skalieren wird teuer.

Anderer Sicherheits- oder Compliance-Umfang. Kartendaten oder Gesundheitsakten können eine separate, streng kontrollierte Einheit rechtfertigen, um den Rest des Systems aus dem Prüfungsumfang herauszuhalten.

Andere Technologieanforderungen. Etwa ein Machine-Learning-Modell, das sich am besten aus Python bereitstellen lässt, innerhalb eines Java-Monolithen.

Manche Gründe sind für sich genommen keine guten Gründe: „Monolithen sind Legacy“, der Wunsch, eine neue Technologie einzusetzen, oder langsamer Code (ein Designproblem, das eine Aufteilung nicht behebt und durch zusätzliche Netzwerkaufrufe sogar verschlimmern kann).

Wie man aufteilt, wenn es so weit ist

Teilen Sie schrittweise auf, ein Modul nach dem anderen, beginnend mit dem Modul, das sowohl die klarste Grenze als auch den stärksten Grund zum Herauslösen hat. Modularisieren Sie zuerst, wenn der Code noch nicht modular ist: Wer einen Service aus einem Knäuel herauslöst, zieht das Knäuel mit. Lösen Sie dann entlang von Bounded Contexts heraus (Abschnitt 5.7): Setzen Sie eine Netzwerk-API vor die bestehende API des Moduls, verlagern Sie seine Daten in eine eigene Datenbank, ersetzen Sie prozessinterne Ereignisse durch einen Message Broker und gemeinsame Transaktionen durch explizite Sagas. Leiten Sie den Verkehr schrittweise auf den neuen Service um und behalten Sie den alten Weg, bis sich der neue bewährt hat.

Das ist der Strangler-Fig-Ansatz samt seinen Verwandten, behandelt in Abschnitt 11.6. Das Ziel ist oft nicht „alles Microservices“, sondern ein Monolith mit einigen herausgelösten Services dort, wo die Belege es verlangt haben; die servicebasierte Architektur aus Abschnitt 6.2 ist ein verbreiteter, pragmatischer Endzustand.

Die Bewertungen fassen die Urteile aus den einzelnen Abschnitten zusammen und gehen von typischen Implementierungen aus. Domain-Driven Design erscheint nicht als Spalte, weil es eine Methode zum Finden von Grenzen ist, die jeder dieser Stile nutzen kann. Reale Systeme kombinieren Stile: Ein modularer Monolith, dessen Module innen hexagonal sind, mit einem Pipes-and-Filters-Importjob und einem Microkernel für Steuerregeln, ist völlig normal.