Spring GDS 25. Jubiläum
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Ein Monolith ist eine Anwendung, die als einzelne Einheit gebaut und deployt wird. Die Benutzeroberfläche, die Geschäftslogik und der Datenzugriff leben alle in einer Codebasis, kompilieren zusammen und liefern zusammen aus. Wenn Sie deployen, deployen Sie das Ganze. Für den größten Teil der Softwaregeschichte wurden Anwendungen schlicht so gebaut, und für sehr viele Projekte ist es weiterhin die richtige Wahl.
Der übliche Vergleichspunkt sind Microservices, bei denen eine Anwendung in viele kleine Services geteilt wird, die unabhängig laufen und deployen. Der Monolith hält alles an einem Ort, was ihn anfangs leichter zu entwickeln, einfacher Ende-zu-Ende zu testen und schneller zu durchdenken macht, weil es kein Netzwerkspringen zwischen Teilen gibt. Der Preis ist, dass er mit der Zeit schwerer wird. Eine kleine Änderung bedeutet, die ganze Anwendung neu zu deployen, und die Arbeit eines Teams kann mit der eines anderen in derselben Codebasis kollidieren. Ein Startup, das sein erstes Produkt ausliefert, profitiert fast immer von einem Monolithen und stellt die Frage neu, sobald Größe und Teamumfang die einzelne Einheit knirschen lassen.
Die ehrliche Einordnung ist, dass "Monolith" kein Schimpfwort und "Microservices" keine Trophäe ist. Microservices lösen echte Skalierungs- und Organisationsprobleme, fügen aber operative Komplexität hinzu, die kleine Teams bezahlen, ohne den Nutzen zu bekommen. Viele Firmen, die alles aufzuteilen eilten, haben Arbeit seither in einen gut organisierten Monolithen zurückgeholt. Die Architektur sollte zur Größe des Problems passen, nicht zur Größe des Ehrgeizes.
Wir starten die meisten Produkte als Monolith und sagen das klar, selbst wenn ein Kunde nach Microservices fragt. Ein sauberer, modularer Monolith liefert schneller, kostet weniger im Betrieb und lässt sich weit leichter ändern, solange das Produkt noch seine Form sucht. Wir haben mehr als ein Projekt übernommen, bei dem verfrühtes Aufteilen ein kleines Team in Infrastruktur ertrinken ließ, und die Lösung war, zu konsolidieren, nicht weiter zu zersplittern.
Wenn Skalierung oder Teamstruktur es wirklich verlangen, teilen wir bewusst und lösen die Teile heraus, die eigenständig skalieren oder deployen müssen, statt alles auf einmal neu zu schreiben. Die individuellen Webanwendungen, die wir bauen, sind so architektiert, dass diese Grenze später ohne Abriss gezogen werden kann. Wir treffen die Entscheidung auf Basis der Evidenz, mit dem Kunden, und empfehlen mit gutem Gewissen die langweilige Antwort, wenn sie die richtige ist.
Unsicher, ob Monolith starten oder aufteilen? Vermessen wir zuerst das Problem.
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Eine Marke in ein funktionierendes Geschäft verwandeln.
Eine halbe Million Menschen. Eine App. Null Chaos.















