Consol modernisiert das klassische Architekturmodell Monolithische Applikationen mit Microservice-Ambitionen tanzen

Microservices sind nicht immer die richtige Wahl, ist Consol überzeugt. Insbesondere bei eher kleinen Software-Projekten biete ein Development-Ansatz, der monolithisch starte und bei Bedarf auch die Vorteile von Microservices nutzen könne, gewisse Vorteile.

Anbieter zum Thema

Schneider Electric GmbH

VMware Global Inc Zweigndl. Deutschland

Fujitsu Technology Solutions GmbH

ConSol Consulting & Solutions Software GmbH

Microservices sind sauber strukturiert, granular skalierbar, ressourcenschonend, leicht erweiterbar und unterstützen die agile Software-Entwicklung in Teams – dessen ist sich die Consol Consulting & Solutions Software GmbH bewusst. Doch in einigen Fällen stellten monolithische Applikationen die bessere Wahl gegenüber einer Microservices-Architektur dar.

So könnten stark verteilte Microservices-Architekturen einen gewissen Overhead hinsichtlich Verwaltung und Kommunikation verursachen. Oliver Weise, Software-Architekt bei Consol, erklärt, wie Programmierer beide Welten kombinieren und flexible und Cloud-fähige Software „am Stück“ entwickeln:

1. Prinzip: Sourcecode sauber nach Funktionalitäten strukturieren

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. 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.

Für sehr viele Anwendungsfälle ist diese Skalierbarkeit 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.

2. Prinzip: Ressourcen-Exzesse vermeiden

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, zum Beispiel „Redis“.

So lassen sie sich auch auf Cloud-Plattformen wie Kubernetes ausrollen und problemlos zwischen den Cluster-Knoten bewegen. Vorausgesetzt, der Fokus der Software-Entwickler liegt von Anfang an auf 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.

3. Prinzip: Best Practices der 12-Faktor-App-Methodik berücksichtigen

Die 12-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 12-Faktor-App-Methodik, werden auch monolithische, in Containern betriebene Anwendungen flexibel, agil, Cloud-fähig und ressourcenschonend.

4. Prinzip: Den Monolithen zum Tanzen bringen

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. „Ein flexibler, beweglicher Monolith kann durchaus heute noch in der modernen IT bestehen und ist bei kleineren Projektvorhaben oft noch immer die beste Wahl“, betont der Software-Architekt Weise.

(ID:46063101)