Anlässlich einer Vortragsreihe, die wir nun schon das dritte Jahr in der Fachhochschule Offenburg halten, haben wir im Zusammenhang mit der ATAM Methode die Probleme die monolithischen Architekturen mit sich bringen an einem realen Beispiel erläutert. Zur ATAM - einer Methode zur qualitativen Analyse von Software - möchte ich später noch mal einen Artikel posten.
Hier vorab noch zwei Zitate, die ich einfach mal so stehen lassen möchte.
«Beginnen wir nicht mit einem Monolithen, wenn unser Ziel eine Microservices-Architektur ist» - Stefan Tilkov
«Wenn wir nicht einmal einen anständigen Monolithen bauen können, wie kommen wir dann darauf, dass Microservices die Lösung sind?» - Simon Brown
Jedenfalls hat sich aus der Analyse eines Softwaresystems ein Problem herauskristallisiert, das die Wartbarkeit der Software massgeblich behindert. Man nennt das auch einen «historisch gewachsenen Monolithen». Und wohlgemerkt; diese Monolithen sind in der freien Wildbahn auch heute noch weiter verbreitet als saubere Micro Services Architekturen.
Das Zerlegen oder Modularisieren kann in Schichten (strukturieren eine Software horizontal technisch) und in Module (strukturieren eine Software vertikal meist fachlich) erfolgen. Dabei ist darauf zu achten, dass die neu entstehenden Komponenten keine Code-Monolithen, Test-Monolithen und Deployment-Monolithen sind. Letzteres d.h. unabhängiges Deployment von Komponenten ist die höchste Stufe der Modularisierung. Die Architekturstile Micro Services oder Modular Monoliths / Moduliths haben diese Eigenschaft.
Nun werde ich oft von Kunden gefragt, was die «optimale Granularität» einer Software sein sollte. Hier bietet sich die Standardantwort des Softwarearchitekten an: «Das kommt darauf an!?»
Ich möchte hier auf den «Monolith first Approach» von Martin Fowler verweisen. Erst wenn man erfahren hat, was die Software können soll, ist man in der Lage sie optimal zu modularisieren. Da ist eigentlich ein Monolith eine gute Ausgangsbasis. Zugegeben das funktioniert natürlich nur bei relativ statischen Anforderungen. Das ist aber heute in vielen Bereichen nicht die Regel.
Ein vollständiges Refactoring von bestehenden Monolithen ist meist auch nicht möglich. Meist fehlt der Geldgeber oder die Ressourcen. Die Grösse und damit die Komplexität der Software ist sicherlich ein Kriterium wie weit die Zerlegung gehen sollte.
Bei kleineren Systemen fährt man unter Umständen mit einem Monolithen oder sehr wenigen Modulen besser als mit Micro Services. Auch eine Zerlegung von grossen Systemen in hunderte Micro Services ist nicht zu empfehlen. Man tauscht die Komplexität des Monolithen gegen die Komplexität der Serviceintegration.
Das richtige Mass liegt wie so oft in der Mitte. Architekturentscheidungen sind spezifisch und auch nicht in Stein gemeisselt.
Hochschule Offenburg Informatik
Martin Fowler: The Monolith first approach
