Anzeige

Stonehenge

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.

 
Oliver Weise, Software-Architekt
Oliver Weise
Software-Architekt, Consol
(Bildquelle: Consol)

Artikel zu diesem Thema

Microservices
Feb 19, 2020

Sicherheit in Zeiten der Microservices

Wenn es um die Bereitstellung Cloud-basierter Anwendungen über Microservices geht,…
lamp with circuit
Jul 09, 2019

Microservices-Architekturen: Optimal monitoren mit Distributed Tracing

Heutige Websites – vor allem, wenn sie einen Shop beinhalten – bilden eine komplexe…

Weitere Artikel

E-Siegel

E-Siegel für Banken und Finanzdienstleister: Unverzichtbar bei der Digitalisierung

Der durch die Corona-Pandemie beschleunigte Zwang zur Digitalisierung macht auch vor Banken und Finanzdienstleistern nicht halt. Was Kunden aus anderen Lebenssituationen gewohnt sind, fordern sie auch von ihrer Bank.
Automatisierung

ThreatQuotient führt einen datengesteuerten Ansatz für SOAR und XDR ein

ThreatQuotient kündigt den ThreatQ TDR Orchestrator an, eine neue datengesteuerte Automatisierungsfunktion für eine effizientere und effektivere Erkennung und Bekämpfung von Bedrohungen.
Softwareentwicklung

Vorteile der Cloud-nativen Software-Entwicklung

Unternehmen, Organisationen und Behörden sind auf die schnelle Bereitstellung von Software-Lösungen angewiesen. Der IT-Dienstleister Consol listet die wichtigsten Vorteile auf, die für die Software-Entwicklung in der Cloud sprechen.
Lizenz

Microsoft schafft Open License ab

Zum 31. Dezember 2021 beendet Microsoft die Vertragsform „Open License“. Damit stellt der Software-Hersteller seine Kunden einmal mehr vor Herausforderungen. Eine offizielle Information darüber, was mit bereits eingesetzten Programmen geschieht, und welche…
Legacy-System

Legacy-Software kann unnötige Kosten verursachen

Avision zeigt auf, welche unnötigen Kosten bei Altanwendungen anfallen können – und wie sie sich vermeiden lassen. Besonders bei Legacy-Software ist die Versuchung oft groß, sie längere Zeit nicht anzufassen. „Die Software ist ja ohnehin da und kostet…

Anzeige

Jetzt die smarten News aus der IT-Welt abonnieren! 💌

Mit Klick auf den Button "Zum Newsletter anmelden" stimme ich der Datenschutzerklärung zu.