Der „tanzende Monolith“ ergänzt die moderne Microservices-Architektur

Microservices rangieren zurzeit weit oben in der Gunst der Software-Entwickler. Aber sie haben auch Nachteile und Monolithen sind besser als ihr Ruf. Smarte Programmierer vereinen das Beste aus beiden Welten.

Microservices-Architekturen punkten mit vielen überzeugenden Vorteilen: Sie sind sauber strukturiert, granular skalierbar, ressourcenschonend, leicht erweiterbar und unterstützen die agile Software-Entwicklung in Teams. Dem stehen allerdings einige nicht zu unterschätzende Nachteile entgegen, und das Unwort an dieser Stelle heißt Komplexität. Mit einem lose gekoppelten Microservices-Zoo handeln sich IT-Abteilungen in diesem stark verteilten System einen Overhead hinsichtlich Verwaltung und Kommunikation ein. Zudem steigt das Sicherheitsrisiko, denn jeder Microservice, der extern über eine API kommuniziert, kann – im Prinzip – von Cyberkriminellen als Einfallstor benutzt werden.

Die Vorteile der Microservices sind die Nachteile der monolithisch aufgebauten Software-Architekturen – und umgekehrt. Beide Ansätze verhalten sich fast komplementär zueinander. Monolithen sind leichter zu entwickeln, einfacher 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.
 

Vorteile realisieren, Nachteile vermeiden

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 und der Monolith fängt an zu tanzen.

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.

Ressourcen-Exzesse reduzieren

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 sein, vorausgesetzt, sie bedienen sich moderner Entwicklungsplattformen und Prinzipien, etwa durch die Verwendung externer Caching-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.

Best Practices der Zwölf-Faktor-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 zu 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-Faktor-App-Methodik, werden auch monolithische, in Containern betriebene Anwendungen flexibel, agil, cloud-fähig und ressourcenschonend. 

Der flexible, agile Monolith

Moderne Release-Prozesse mit vollautomatisierten Tests, unveränderlichen 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 die 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.