© Excellent backgrounds/Shutterstock.com
Von der Entstehung eines Monolithen und dem Versuch, ihn zu zerlegen

(Try to) Kill your Monolith


Bei der Entwicklung von Softwaresystemen und -architekturen gibt es verschiedene Ansätze und Paradigmen, die jeweils kontextabhängige Vor- und Nachteile haben. Zu gerne folgen wir bei der Beurteilung von Architekturen entweder unseren persönlichen Vorlieben oder wir verurteilen Lösungen, die nicht mehr State of the Art oder zu komplex sind, um sie mit überschaubarem Aufwand zu überblicken. Eine objektive Beurteilung einer gewachsenen Architektur kann aber nur auf einer strukturierten und sachlichen Analyse basieren.

Im Rahmen dieses Artikels geht es uns darum, den Leser auf eine wertungsfreie, zum Teil fiktive historische Reise mitzunehmen. In deren Rahmen beschreiben wir die Entstehung und das Wachstum eines Monolithen sowie die Herausforderungen beim Versuch, ihn zu modernisieren und zu zerlegen.

State of the Art sind derzeit Microservices-basierte Architekturen. Monolithische Architekturen sind verpönt, obwohl sie durchaus auch Vorteile haben können. Die Beurteilung einer Architektur bzw. eines größeren, historisch gewachsenen Systems ist insofern schwierig, als bei der Beurteilung nicht nur technische, sondern auch wirtschaftliche, organisatorische und fachliche Aspekte sowie die historischen Rahmenbedingungen berücksichtigt werden müssen.

Die Historie spielt bei der Bewertung eine wichtige Rolle. Designentscheidungen folgen nicht selten aktuellen Trends und basieren auf den zum jeweils aktuellen Zeitpunkt verfügbaren technischen Mitteln. Technologien, die heute angesagt sind, sind es ein paar Jahre später häufig nicht mehr – auch wenn sie ihren Zweck weiterhin gleichwertig erfüllen. Eine heute richtig wirkende Lösung könnte sich in Zukunft aufgrund eines sich im Kern veränderten Produkts als nicht mehr richtig erweisen. In diesem Fall muss bei der Bewertung differenziert werden: Liegt der Fehler im ursprünglichen Design oder beim Versäumnis einer Anpassung des Systems an die evolutionären Produktänderungen? Bei einem Versäumnis könnten die Ursachen organisatorischer Natur sein.

Als Beispiele dienen hier das Fehlen von Regeln und Maßnahmen zur Erfassung und Beseitigung technischer Schulden oder ein zu hoher erzwungener Durchsatz bei der Umsetzung neuer Anforderungen und das damit verbundene ständige Stricken mit der heißen Nadel. Oder aber ein Design wirkt nur falsch, weil eine hohe fachliche Komplexität auf das technische Design ausstrahlt und es schwerer greifbar macht. Hierbei verhält es sich wie in der Physik mit dem Energieerhaltungsprinzip: Kom...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang