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.


Whitepaper "Wohin mit den Monollithen - Optionen der Modernisierung für eine evolutionäre Applikationswelt"

Das Whitepaper erläutert die grundlegende Problematik der Modernisierung von Altsystemen und gibt wertvolle Hinweise durch ein Aufzeigen der unterschiedlichen Handlungsoptionen bei der Transformation (sprich Modernisierung) dieser meist monolithischen Altsysteme.

Das Whitepaper steht hier zum Download zur Verfügung.

Deutsch, 15 Seiten, PDF 1,5 MB, kostenlos


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)

Newsletter Anmeldung

Smarte News aus der IT-Welt

Sie möchten wöchentlich über die aktuellen Fachartikel auf it-daily.net informiert werden? Dann abonnieren Sie jetzt den Newsletter!

Newsletter eBook

Exklusiv für Sie

Als Newsletter-Abonnent erhalten Sie das Booklet „Social Engineering: High Noon“ mit zahlreichen Illustrationen exklusiv und kostenlos als PDF!

 

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

SQL

Schweizer Taschenmesser für SQL-Datenbanken

Per Drag & Drop intuitiv und flexibel Anwendungen für SQL-Datenbanken gestalten: Die Low-Code-Plattform GAPTEQ unterstützt den Aufbau vom einfachen Web-Formular bis hin zur komplexen Business-Applikation und Extranet-Lösung.
Programmieren

Gefährliche Designfehler und Schwachstellen in Legacy-Programmiersprachen für Industrieroboter

Trend Micro stellt neue Forschungsergebnisse vor, die auf Designschwächen in Legacy-Programmiersprachen hinweisen, welche in industriellen Systemen zum Einsatz kommen. Die Sicherheitsforscher veröffentlichen zudem neue Richtlinien für sicheres Programmieren,…
EngelbertStrauss

engelbert strauss schützt seine Identitäten

Um als Familienunternehmen weltweit erfolgreich zu sein, benötigt engelbert strauss eine leistungsfähige und sichere Informationstechnik, beispielsweise für den Online Shop, aber auch für die digitalen Beziehungen zu Kunden und Lieferanten.

Anzeige

Newsletter Anmeldung

Smarte News aus der IT-Welt

Sie möchten wöchentlich über die aktuellen Fachartikel auf it-daily.net informiert werden? Dann abonnieren Sie jetzt den Newsletter!

Newsletter eBook

Exklusiv für Sie

Als Newsletter-Abonnent erhalten Sie das Booklet „Social Engineering: High Noon“ mit zahlreichen Illustrationen exklusiv und kostenlos als PDF!