Monolithen und Microservices sind keine Gegensätze

Microservices sind in – Monolithen sind out. Diese einfache Formel wird der Programmier-Realität nicht gerecht. Denn nach wie vor kämpfen Microservices mit diversen Schwächen, während monolithische Architekturen immer noch eine ganze Reihe systembedingter Vorzüge besitzen. Clevere Programmierer nutzen deshalb mit modernem Software Engineering die komplementären Stärken beider Ansätze. 

Microservices-Architekturen sind nicht umsonst aktuell so beliebt, denn ihre Vorteile sind evident: Sie sind sauber strukturiert, granular skalierbar, ressourcenschonend, leicht erweiterbar und unterstützen die agile Software-Entwicklung in Teams. Dieser Habenseite stehen allerdings einige gravierende Nachteile gegenüber. Der für IT-Abteilungen vielleicht wichtigste ist die Komplexität von Microservice-Strukturen. Denn das Microservice-Portfolio gerät schnell in einen unübersichtlichen Wildwuchs, der nur mit viel Aufwand hinsichtlich Transparenz, Verwaltung und Kommunikation in den Griff zu bekommen ist. Das bindet zwar produktive Ressourcen, ist aber auch deshalb unumgänglich, weil mit der wachsenden Zahl von Microservices das Sicherheitsrisiko steigt. Denn mit ihren APIs, über die sie mit der Außenwelt kommunizieren, sind sie ein beliebtes Angriffsziel von Cyberattacken.

Mit den Nachteilen von Microservices wurden prinzipiell bereits die Vorteile monolithisch aufgebauter Software-Architekturen beschrieben. Das ergibt sich aus der Tatsache, dass beide sich in ihren Eigenschaften und Merkmalen fast komplementär zueinander verhalten. Monolithen sind architektonisch einfacher, leichter auszurollen und häufig performanter als Microservices. Letzteres gilt, wenn eine App mit einer Microservices-Architektur zum Beispiel 20 bis 30 API-Aufrufe an 20 bis 30 unterschiedliche Microservices benötigt, um eine einzelne Eingabemaske zu laden, was zulasten der Performance geht. Demgegenüber kommunizieren die Software-Komponenten eines Monolithen in der Regel wesentlich performanter miteinander. Monolithen haben jedoch auch einige gravierende Nachteile: Sie skalieren nur „an einem Stück“, gelten deshalb als Ressourcenfresser und als schwerfällig, wenn es um die agile Einführung neuer Technologien wie das IoT oder KI geht.

 

Software Engineering statt Wasserfall-Methodik

Allerdings: Die schlechte Reputation monolithischer Software, stammt aus einer Zeit, als Programmierer noch nach der Wasserfall-Methodik entwickelt haben, nach dem Motto: Anfangen, runterschreiben und debuggen; Hauptsache, der Code läuft fehlerfrei. In vielen Organisationen sind die nach Methode Wasserfall entwickelten Programme noch im Einsatz. Die Software funktioniert tadellos, ist aber schlecht dokumentiert und nur unter größten Schwierigkeiten erweiterbar. Am besten, man fasst sie nach Programmstart nie mehr an. Diese Nachteile lassen sich jedoch nahezu vollständig vermeiden, wenn Monolithen konsequent nach den Prinzipien des modernen Software Engineering entwickelt werden. Das Software- und Consulting-Unternehmen Consol empfiehlt eine strukturierte Software-Entwicklungsmethodik, die monolithisch startet, jedoch bei Bedarf auch die Vorteile von Microservices nutzen kann. Auf diese Weise lässt sich das Beste aus beiden Welten vereinen.

Sinnvoll ist, auch im Monolithen eine klare vertikale Trennung nach Funktionalitäten vorzunehmen, die über Schnittstellen lose miteinander gekoppelt sind. Modularisierungs-Frameworks wie OSGi oder Jigsaw können Programmierer dabei unterstützen, diese Trennung im Sourcecode einzuhalten. Programmierer mappen sozusagen eine Microservices-Architektur auf den Monolithen, vermeiden aber die damit verbundenen Nachteile. Die Komponenten werden gemeinsam bereitgestellt (Deployment), in einem gemeinsamen Prozess betrieben und skalieren auch nur „am Stück“, das heißt über weitere Instanzen des Gesamt-Deployments. Die Inbetriebnahme bleibt schnell und die Skalierbarkeit ist für sehr viele Anwendungsfälle durchaus ausreichend. Sollte sich später im Betrieb herausstellen, dass eine Software-Komponente zeitweilig einen besonders hohen Skalierungsbedarf hat, lässt sie sich dank der internen Modularisierung immer noch extrahieren und als separaten Microservice betreiben.

 

Monolithen schonen Ressourcen

Die berüchtigten Ressourcen-Exzesse existierender monolithischer Applikationen sind eher auf veraltete Plattformen und Legacy-Konzepte als auf die Architektur zurückzuführen. In vielen Fällen können Monolithen ebenfalls sparsam im Ressourcenverbrauch sen, vorausgesetzt, sie bedienen sich moderner Entwicklungsplattformen und Prinzipien, etwa durch die Verwendung externer Coaching-Dienste, wie zum Beispiel Redis. So lassen sie sich auch auf Cloud-Plattformen wie Kubernetes ausrollen und problemlos zwischen den Cluster-Knoten bewegen. Auch hier geraten Monolithen gegenüber Microservices kaum ins Hintertreffen. Vorausgesetzt, der Fokus der Software-Entwickler liegt von Anfang an auf einer klaren Struktur, bewusster Ressourcenverwaltung und schnellem Startup sowie Shutdown. Entpuppt sich eine Komponente im Nachhinein trotzdem als Ressourcenfresser, kann sie relativ einfach extrahiert und der Ressourcenverbrauch reduziert werden.

 

Zwölf Faktoren für die App-Methodik

Die Grundsätze klar strukturierter Software-Entwicklung, an die sich Monolithen halten sollten, sind mittlerweile ausgereift und in der Praxis erprobt. Die Zwölf-Faktor-App-Methodik ist eine Sammlung von Best Practices zur Entwicklung von Software-as-a-Service-Applikationen für die Private und die Public Cloud. Wesentliche Bestandteile der Empfehlungen sind eine saubere Kapselung der einzelnen Sourcecode-Komponenten und klare Schnittstellen zu Betriebssystemen und Services. Die Methodik empfiehlt, implizite Abhängigkeiten und Bibliotheken und System-Tools zu vermeiden und alle vorhandenen Abhängigkeiten explizit zu deklarieren. Orientieren sich Software-Entwickler konsequent an den Best Practices der Zwölf-Faktoren-App-Methodik, werden auch monolithische, in Containern betriebene Anwendungen flexibel, agil, cloud-fähig und ressourcenschonend.

 

Moderne Release-Prozesse schaffen flexible Monolithen

Vollautomatisierte Tests, unveränderliche Deployments und Infrastruktur-Automation eignen sich auch für monolithische Architekturen. Da man nur einen Prozess braucht, im Vergleich zu einer Microservices-Umgebung, die viele Prozesse benötigt, spart ein Monolith sogar Aufwand. Zwar gibt es an einem Monolithen mehr zu testen als an einem Microservice, was dir Laufzeit des Prozesses in die Länge treibt. Durch Parallelisierung ist dies in der Regel aber in den Griff zu bekommen.

Eine weitere Voraussetzung dafür, flexible Monolithen zu entwickeln, ist neben der Berücksichtigung der technischen Best Practices auch der Abbau von organisatorischen Hindernissen im Unternehmen. Träge Freigabeprozesse für Releases oder für den Einsatz moderner Software-Entwicklungsplattformen, mangelnde Kommunikation und fehlendes Vertrauen zwischen Development und Operations haben in der Vergangenheit monolithischen Anwendungen oft zu schaffen gemacht. Ein Monolith darf niemals die Entschuldigung dafür sein, DevOps-Prinzipien zu vernachlässigen oder ganz zu verhindern.

 

(Abb. 1): Flexible Monolithen vereinen das Beste aus beiden Welten. Bei Bedarf lassen sich funktionale Komponenten leicht auslagern und granular skalieren.

 

 

 

Oliver Weise ist Software-Architekt beim Münchner IT-Dienstleister Consol am Standort Düsseldorf.

Redaktion


Leave a Reply