Microservices versus Monoliths

Wichtige Ziele moderner Softwareentwicklung sind kurze Releasezyklen, das schnelle Reagieren auf neue Technologietrends und eine hohe Verfügbarkeit der Software. Wenn monolithische Applikationen über längere Zeit weiterentwickelt und gewartet werden müssen, wird es zunehmend schwieriger, diese Anforderungen zu erfüllen. Da auch wir bei unseren Projekten bzw. in der Produktentwicklung immer wieder auf genau diese Schwierigkeiten stoßen, wurde im Sommer letzten Jahres beschlossen, das iMath Forschungsprojekt dazu zu nutzen, eine alternative Architekturform genauer zu untersuchen, nämlich die der Microservices. Innerhalb des letzten halben Jahres habe ich mich im Rahmen meiner Bachelorarbeit „Microservices versus Monoliths“ mit den Unterschieden und Vor- und Nachteilen beider Architekturformen auseinandergesetzt.

Im Gegensatz zu Monolithen, bei denen sämtliche Funktionalitäten als eine Einheit gebaut, getestet und deployed werden müssen, unterteilen Microservices eine Applikation in kleine unabhängige Services. Diese Services sind nur lose gekoppelt, was heißt, dass sie ausschließlich über das Netzwerk kommunizieren.

Durch diese Eigenschaften von Microservices ergeben sich eine Reihe von Vorteilen. Auf lange Sicht bieten Microservices eine bessere Wartbarkeit, da jeder Service unabhängig von anderen weiterentwickelt werden kann. Außerdem ist durch die lose Kopplung zwischen Services ein unabhängiges Deployment möglich. Ein weiterer Vorteil ist, dass die einzelnen Services leichter austauschbar sind. Solange das Interface eines Services sich nicht verändert, macht es keinen Unterschied, welche Bibliotheken, Frameworks oder Programmiersprachen im Hintergrund verwendet werden.

Die Kehrseite der Microservice Architektur ist jedoch der große Overhead und die neuen Herausforderungen, die diese Architekturform mit sich bringt. Microservices sind ein verteiltes System, was bedeutet, dass Kommunikation über das Netzwerk stattfindet. Diese Art der Kommunikation ist fehleranfällig. Eine weitere Herausforderung ist das Deployment und der Betrieb von Microservices. Vor allem bei größeren Systemen mit vielen einzelnen Services muss ein hoher Grad an Automatisierung angestrebt werden. Das gilt sowohl für das Deployment als auch für die Überwachung der Services im Betrieb.

Um diese Herausforderungen bewältigen zu können, ist es wichtig auf ein Framework zu setzen, das viele dieser Anforderungen bereits implementiert. Im Java Bereich eignet sich dazu das Spring Framework. Es stellt Libraries für die Implementierung von REST Services, Messaging Systemen, Service Discovery, Distributed Tracing, Fault Tolerance und vieles mehr zur Verfügung und bietet damit die Grundvoraussetzungen für die Implementierung von Microservices.

Fazit: Klar ist, dass Microservices einen deutlichen Overhead mit sich bringen, der aber mit dem Einsatz der richtigen Tools bewältigbar ist. Trotzdem muss das Software-Projekt einen gewissen Umfang aufweisen, damit die Vorteile der Microservice Architektur die zusätzlichen Herausforderungen aufwiegen.

ABF-Microservices-versus-Monoliths
Milena L.

Unsere Kollegin Milena L. studiert Software Engineering an der FH Hagenberg.

Ihre Bachelorarbeit hat den Titel „Microservices versus Monoliths“ und untersucht die Unterschiede dieser beiden Architekturformen.

Manche Fragen lassen sich am einfachsten persönlich klären.