Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren
Die Softwareentwicklung unterscheidet zwischen solitären Kompaktbauten, so genannten Monolithen, und Baukastensystemen, so genannten Microservice-Architekturen. Für beide Architekturprinzipien finden sich Liebhaber, aber nur das letztere wird auf Dauer dem digitalen Fortschritt standhalten – sagen wir. Warum, das erklären wir im Kontext des letzten JUGH-Treffens zum Thema.
Was ist ein Monolith in der Softwareentwicklung?
Monolithische Systeme sind große, in sich geschlossene Softwarearchitekturen, die alle nötigen Funktionen zu einem Full-Service-Gesamtpaket schnüren: Datenzugriff, Nutzeroberfläche, Schnittstellen – alles ist unter einem Dach gebündelt. Der Softwaremonolith ist autark und läuft komplett unabhängig von anderen Applikationen. Design und Philosophie folgen der ganzheitlichen Auffassung, dass das System eigenverantwortlich ist und aus sich selbst heraus funktionstüchtig sein soll. Beispiele für solche Systeme sind etwa die „Datensilos“ der digitalen Finanzwirtschaft, die als Monolithen sensible Daten vor dem Zugriff anderer Systeme schützen sollen. Aber auch viele Großrechner und Textprozessoren sind monolithisch konzipiert.
Die Autonomie von Monolithen hat aber Grenzen: So sind sie in aller Regel an bestimmte Hardware oder Betriebssysteme gebunden und nicht mit artfremden Programmiersprachen kompatibel.
Kennzeichnend für monolithische Systeme ist zudem das Fehlen jeglicher Modularität. Alles ist eins und eins ist alles. Daraus resultiert eine gewisse Schwerfälligkeit hinsichtlich der Anpassung von Softwareteilen und eine ungünstige Intransparenz, die durch die enge Verstrickung aller Teile verursacht wird und für die Fehlersuche im Störungsfall ausgesprochen hinderlich sein kann. Das ist einer der wesentlichen Gründe, warum der Trend schon seit einigen Jahren weg von Monolithen hin zu Microservices geht.
Was sind Microservices?
Im Gegensatz zu monolithischen Softwarearchitekturen bieten Microservices ein hohes Maß an Modularität: Jeder Softwarebaustein und jeder Prozess ist als Einzelstück funktionstüchtig. Das hat ganz erheblichen Vorteile in Sachen Effizienz, da die einzelnen Module wiederverwertet werden können. Statt für jede Applikation das Rad neu zu erfinden, bieten Microservices einen ganzen Baukasten an Softwareteilen, die mit geringfügigen Anpassungen in anderen Kontexten wiederverwendet werden können.
Software, die aus Microservices zusammengesetzt ist, lässt sich zudem viel besser warten und weiterentwickeln, da sich die einzelnen Bestandteile minimal-invasiv testen, verbessern, austauschen und deployen lassen. Microservices sind also ein wahrer Segen, wenn es um die Skalierung oder um die Anpassung der Infrastruktur geht.
Ihr entscheidender Trumpf ist die geringe Verflochtenheit: Microservices werden nur so fest wie nötig aber so gering wie möglich miteinander verwoben, so dass im Falle einer „Operation am offenen Herzen“ viel weniger Abhängigkeiten, Wechselwirkungen und Dominoeffekte zu bedenken sind. Das Fehlerrisiko sinkt damit substanziell.
Modularität ist also wünschenswert. Insbesondere vor dem Hintergrund immer volatiler werdender Märkte bieten Microservice-Architekturen Unternehmen die besseren Voraussetzungen, um digital handlungsfähig zu bleiben und mit der Dynamik der Digitalisierung Schritt zu halten.
Ein weiterer wichtiger Vorteil von Microservices ist ihre technologische Unabhängigkeit: Sie sind auf jeder Hardware, allen Betriebssystemen lauffähig und mit allen Programmiersprachen kompatibel.
Gibt es ein Aber?
Kritiker von Microservice-Architekturen wenden häufig ein, dass sie bei Tests oder der Inbetriebnahme mit einer höheren Komplexität einhergehen. Das ist zwar richtig, müssen hier schließlich nicht nur ein System, sondern viele kleine Systeme getestet und ausgerollt werden. Doch ist dies erstmal geschehen, amortisieren sich diese initial anfallenden Mehrarbeiten schnell und rechnen sich über den gesamten Lebenszyklus einer Software ohne Zweifel. Vergleiche dazu auch die Beiträge von JAXenter und Heise zum Thema.
Migrationsbericht: Vom Monolithen zu Microservices
Die Migration von monolithischen Anwendungen hin zu einer Microservice-Architektur stellt oftmals eine große Herausforderung dar. In diesem JUGH-Vortrag teilen Andreas Weigel und Jakob Fels ihre Erfahrungen in einem agil arbeitenden Softwareteam, das genau vor dieser Aufgabe stand und das sie bei dieser Transformation begleitet haben. In ihrem Vortrag gehen sie auch darauf ein, wie sie auf die Komplexität einer verteilten Anwendung reagiert haben. Dabei spielen nämlich nicht nur technische Faktoren wie Monitoring oder Logging eine Rolle, sondern auch organisatorische Fragen, die mit den Herausforderungen cross-funktionaler Teams aufgeworfen werden.
Empfehlung der Redaktion: Wer sich für modulare Softwareentwicklung interessiert, dem sei auch dieser JUGH-Vortrag ans Herz gelegt: Apache Kafka und das MicroProfile.
(jw)
Informationen zur Java User Group Hessen (JUGH):
Die Java User Group Hessen (JUGH) ist Teil des internationalen Netzwerkes von Java Communities, die sich der weltweiten Verbreitung von Java-Know-how verschrieben haben. Im Sommer 2009 wurde sie von Entwicklern der Micromata GmbH ins Leben gerufen und kann seither auf eine ganze Reihe spannender Workshops und Vorträge zum Thema Java zurückblicken. Die JUGH trifft sich einmal im Monat (in der Regel immer am letzten Donnerstag) in Kassel. Eine Voranmeldung ist meistens nicht nötig, der Eintritt ist frei. Kontakt: jugh@micromata.de. Weitere Informationen sind unter www.jugh.de erhältlich.
