Der Monolith muss weg – oder doch nicht?

Eine der größten Herausforderungen für Softwarehersteller in der Produktentwicklung stellt die hohe Komplexität eines gewachsenen, monolithischen Systems dar. Dieser Herausforderung wollen wir uns in diesem Artikel annehmen und Euch dabei helfen zu entscheiden, ob es Zeit ist den berühmten ersten Schritt zu wagen.

Der Unterschied – Monolith vs. verteilte Architektur

Zunächst gilt es zu klären, wie eine Alternative zum Status Quo aussehen könnte. Monolithische Ansätze werden auch als klassische oder traditionelle Ansätze bezeichnet. Sie enthalten in einem großen Gesamtsystem alle Funktionalitäten. Das heißt, alle Funktionen werden in einem einzigen Prozess umgesetzt.

Bei verteilten Architekturen (z. B. Microservices, Client-Server oder SOA) hingegen, wird die Software in einzelne Teilsysteme strukturiert, die jeweils eine bestimmte Gruppe von Funktionalitäten beinhalten. Diese Teile werden in einzelne Prozesse gekapselt. Dadurch können die Services unabhängig voneinander entwickelt und betrieben werden. Folglich können die individuellen Teilsysteme ohne negative Auswirkungen auf andere Teilsysteme ausgeführt werden bzw. sind bei einem Ausfall nur Teile des Gesamtsystems betroffen.

Eine schwere Entscheidung

Um ein gewachsenes System in eine verteilte Architektur zu überführen, werden beispielsweise Refactorings genutzt. Solche Initiativen können sich u. U. über lange Zeiträume hinweg ziehen. Manchmal bringen sie im ersten Schritt nicht die gewünschte Leichtigkeit und Flexibilität. Bevor Ihr Euch für den einen oder den anderen Pfad entscheidet, solltet Ihr gut überlegen, welche Architektur wirklich zu Euch passt und wie dabei vorzugehen ist.

Wir haben unseren Kollegen Jakob dazu befragt. Jakob ist ein erfahrener Softwareentwickler und hat bereits sowohl in komplexen Systemen gearbeitet, als auch in modernen Softwarearchitekturen und war Teil großer Refactoring-Initiativen.

Seine Antworten haben wir hier für Euch kurz und knapp zusammengefasst:

Wann kann ich beim Monolithen bleiben?

• Wenn Ihr ein neues System entwickelt, kann im ersten Schritt eine monolithische Architektur gewählt werden. Es ist grundsätzlich erstmal einfacher einen Monolithen zu konzipieren, da keine zusätzliche Infrastruktur nötig ist.
• Wenn Euer System eine bestimmte Größe nicht überschreitet, ist ein Monolith übersichtlicher. Ihr habt sofort einen Gesamtüberblick über Euer System.
• Beim monolithischen Ansatz könnt Ihr bei domänenübergreifenden Prozessen einzelne Komponenten einfacher referenzieren.
• Bleibt bei Eurem System, wenn die Erweiterung mit neuen Features keine große Rolle spielt.
• Hat Eure Architektur keinen negativen Einfluss auf die Softwarekomplexität, ist es nicht notwendig große Aufwände in einen Umbau zu stecken.

Was sind Anzeichen dafür, dass Dein System zu komplex geworden ist?

• Wenn neue Features viel Zeit für die Entwicklung und Auslieferung benötigen.
• Wenn Dein Entwicklungsteam ständig mit der Wartung des Systems beschäftigt ist.
• Das Gesamtsystem ist so groß und komplex, dass neue Mitarbeiter eine lange Zeit zum Einarbeiten benötigen.
• Wenn ständige Systemüberlastungen zu einer niedrigen Performance führen.
• Die Lokalisation von Fehlern im Code gestaltet sich so aufwendig, dass dafür unnötig viel Zeit beansprucht wird.

Mal andersrum gefragt, was sind die Nachteile eines Monolithen?

• Bei domänenübergreifenden Prozessen besteht die Gefahr, wenn die Domänen nicht ausreichend gekapselt sind, dass der Code unreflektiert wiederverwendet wird. Schleichen sich beim Code Fehler ein, sind weitere, abhängige Teile des Codes von Fehlern betroffen. Das führt dazu, dass die eingeschlichenen Fehler schwer zu identifizieren sind, da das gesamte System untersucht werden muss.
• Ab einer bestimmten Größe wird das System schwerer zu warten. Mit steigender Komplexität steigt auch die Wartungsintensität an und es dauert länger neue Features zu liefern.
• Um einen Monolithen zu verstehen, muss man das Gesamtsystem verstehen. Es reicht nicht einen Teil zu verstehen, weil alle Teile des Codes potenziell miteinander agieren. Das kann zu langen Onboarding Phasen neuer Mitarbeiter führen.

Für eine vollständige Betrachtung, haben wir Jakob gefragt „Was sind die Vorteile einer verteilten Architektur?“.

• Das Onboarding neuer Mitarbeiter ist viel schneller und einfacher, weil es genügt sich mit einem Teil aller verfügbaren Komponenten zu beschäftigen. Eine Domäne ist in einem Stück Software gekapselt und liefert eine Schnittstelle nach außen.
• Einfaches Onboarding führt dazu, dass verschiedene Teams unabhängig voneinander verschiedene Domänen bearbeiten können.
• Falls eine Komponente des Systems ausfällt, können alle anderen Komponenten ohne negative Abhängigkeiten weiterarbeiten. Beispielsweise, wenn es in einem Onlineshop Probleme mit der Bezahlung von Bestellungen gibt, können trotzdem weiterhin neue Bestellungen aufgegeben werden.
• Die Modernisierung einzelner Komponenten ist einfacher, weil andere Komponenten davon nicht betroffen sind.
• Eine intelligente modularisierte Architektur z. B. in Microservices bringt ein Grundlevel an Komplexität mit, wird aber im Gegensatz zum Monolithen über die Zeit nicht immer komplexer. Das führt zu Schnelligkeit und Flexibilität. Neue Features können in kurzer Zeit geliefert werden und es ist weniger Zeit für die Wartung des Gesamtsystems nötig.

Gibt es auch Nachteile verteilter Architekturen? Was sind Deine Erfahrungen? 

• Es ist zusätzliche Infrastruktur nötig, um einen Überblick über das Gesamtsystem zu erhalten. Einzelne Softwarekomponenten müssen orchestriert werden. Dafür gibt es allerdings mittlerweile sehr gute Werkzeuge.
• Je größer das System wird, desto mehr Erfahrung sollte ein Softwareentwickler haben, um das System zu verstehen.
• Einzelne Domänen und deren Interaktionen müssen von Anfang an bekannt sein. Das heißt, es gibt einen höheren architektonischen Aufwand, bevor das System implementiert werden kann.

Jakob, abgesehen von den Gründen für oder gegen einen bestimmten Architekturstil, mit welchem Stil arbeitest du lieber? Und warum?

Zum Abschluss dieses kleinen Exkurses fasst Jakob nochmal seinen persönlichen Standpunkt für Euch zusammen:

Ich persönlich arbeite lieber in verteilten Architekturen, weil es einfacher ist sich in einzelne Teile hineinzudenken. Während der Programmierung habe ich einen definierten Bereich innerhalb dessen ich mich bewegen darf.

Wenn Unternehmen merken, dass ihr Monolith nicht mehr funktioniert, dann gibt es immer die Frage, ob man das komplette System austauschen sollte oder nur einzelne Teile. Ich bin immer dafür erst einzelne kritische Komponenten im Monolithen zu identifizieren und diese dann in Microservices oder andere modulare Strukturen zu überführen.

Einen wichtigen Hinweis habe ich noch. Auch in modularisierten Strukturen müsst Ihr aufpassen, dass Ihr nicht einen verteilten Monolithen baut, in dem plötzlich doch wieder alle Komponenten voneinander abhängen.

Für diejenigen, die sich tiefer in die Thematik einlesen wollen, habe ich noch zwei Empfehlungen von zwei Vorreitern der Entwicklung. „Microservices: Grundlagen flexibler Softwarearchitekturen“ von Eberhard Wolff sowie den Artikel von James Lewis zu Microservices.

Fazit - Wann sollten Softwarehersteller den Schritt zu einer verteilten Architektur machen?

Wenn das Gesamtsystem eine solche Komplexität angenommen hat, dass die Wartung des Systems und die Liefergeschwindigkeit neuer Features beeinträchtigt sind, wird es höchste Zeit zum Handeln. Aber Vorsicht, bevor es zu Aktionismus kommt, sollten die richtigen Weichen gestellt werden. Ein strukturiertes Vorgehen und ein objektiver Blick von außen können dabei den Erfolg des Vorhabens bestimmen.

Bist noch unsicher, ob ihr diesen Schritt gehen sollt? Dann lade Dir unsere Leitfaden herunter, lerne die einzelnen Ausprägungen einer Modularisierung kennen und nutze unsere Handlungsempfehlungen für eine erfolgreiche Umsetzung.