Ergänzung zu modernen Architekturmustern

Microservices und Monolithen schließen sich nicht aus

| Autor / Redakteur: Oliver Weise * / Stephan Augsten

Mit der nötigen Flexibilität geht es auch mit einem Monolithen hoch hinaus.
Mit der nötigen Flexibilität geht es auch mit einem Monolithen hoch hinaus. (Bild gemeinfrei: Maximilian Keppeler / Unsplash)

Microservices stehen in der Gunst der Software-Entwickler zurzeit weit oben, aber sie haben auch Nachteile. Monolithische Anwendungen wiederum 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, 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 monolithisch aufgebauter 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 meist 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.

Monolith und Microservices lassen sich durchaus miteinander kombinieren, um so in den Genuss der jeweiligen Vorzüge zu kommen.
Monolith und Microservices lassen sich durchaus miteinander kombinieren, um so in den Genuss der jeweiligen Vorzüge zu kommen. (Bild: ConSol)

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 separater 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, cloudfä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.

Oliver Weise, Consol: „Ein flexibler, beweglicher Monolith kann durchaus heute noch in der modernen IT bestehen und ist bei kleineren Projektvorhaben oft noch immer die beste Wahl.“
Oliver Weise, Consol: „Ein flexibler, beweglicher Monolith kann durchaus heute noch in der modernen IT bestehen und ist bei kleineren Projektvorhaben oft noch immer die beste Wahl.“ (Bild: ConSol Software)

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.

* Oliver Weise ist Software-Architekt bei Consol.

Kommentare werden geladen....

Kommentar zu diesem Artikel

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46185077 / Microservices)