Vor- und Nachteile der Architekturansätze

Monolithische versus Microservices-Architektur – wer hat die Nase vorn?

Michael Thomas

© Shutterstock.com/Draw

Microservices bieten potentiell große Vorteile, doch haben die traditionelleren monolithischen Lösungen deshalb zwangsläufig ausgedient? Wir werfen einen kurzen Blick auf die Grundzüge der verschiedenen Architekturansätze sowie darauf, für welche Einsatzzwecke sie sich am ehesten eignen.

Sind Microservices wirklich der Weg in die schöne neue Architekturwelt? Zahlreiche Stimmen sehen das anders. Das IT-Urgestein Martin Fowler beispielsweise ist bekennender Microservice-Skeptiker: Ihm zufolge werfen sich viele Entwicklungsteams den Microservices allzu bereitwillig in die Arme, ohne dabei die Folgen zu bedenken. Statt dessen, so Martin weiter, sollte man sich zunächst die Frage stellen, ob eine Microservice-Architektur für das gegebene System überhaupt eine gute Wahl ist. Pauschal beantworten lässt sich diese Frage Martin zufolge nämlich nicht, dafür hängt sie von zu vielen Faktoren ab. So führen Microservices, mit dem Ziel, ein komplexes System zu handhaben, gleichzeitig ihre ganz eigene (für verteilte Systeme übliche) Komplexitätsebene ein, was sich beispielsweise in den Stichworten automatische Bereitstellung, Monitoring oder Eventual Consistency niederschlägt – all diese erfordern einen gewissen Zeitaufwand.

Fowlers generelle Empfehlung lautet daher: Mann sollte nur dann ernsthaft über Microservices nachdenken, wenn das System für eine monolithische Lösung zu komplex ist. Seiner Ansicht nach trifft genau dies auf den Großteil der Softwaresysteme jedoch nicht zu. Sollte man tatsächlich auf Microservices angewiesen sein, plädiert Fowler für eine Monolith-first-Strategie – dazu gleich mehr.

Monolithischer Kern versus rein serviceorientierte Architektur

Florian Motlik (Codeship) stimmt Fowler was die Komplexität von Microservices angeht zwar zu, sieht in ihnen jedoch eine generell sinnvolle Lösung für kleine Codebasen. Im Hinblick auf reine Monolithen sieht er denn auch deutlich größere Probleme. So merkt er beispielsweise an, dass auch Monolithen mit der Zeit einen Overhead ansammeln – ein Problem, das auch Fowler in Bezug auf die Einhaltung von Modulgrenzen einräumt. Weitere Probleme sieht Motlik in den Bereichen Skalierung und Refaktorisierung, sowie bei Code-Reviews und dem Aufbau einer für eine große Codebasis geeigneten, komplexen Infrastruktur. Dem stehen, so Motlik weiter, in der Praxis vor allem zwei Mircoservice-Ansätze gegenüber: Microservice-Architekturen mit monolithischem Kern einerseits, rein serviceorientierte Architekturen andererseits.

Lesen Sie auch: Monolithe zerstören und Hypes die Luft rauslassen

Bei Architekturen mit monolithischem Kern verbleibt die Hauptgeschäftslogik bzw. die Kernfunktionalität im Monolithen, während kleinere Subsysteme, die durch Nachrichten getriggert werden können, in eine eigene Anwendung verschoben werden. Dieser Ansatz bietet sich Motlik zufolge vor allem dann an, wenn alle für einen Job notwendigen Daten durch die ihn auslösende Nachricht übermittelt werden können. Bei der Konzentrierung auf einen Monolithen, der andere kleine Services steuert, kann der Großteil der Vorteile einer monolithischen Infrastruktur (mit nur wenig zusätzlichen Wartungskosten für die kleineren Services) erhalten bleiben. Verschiebt man die Services in die Cloud, so kann der Verwaltungsaufwand für die Infrastruktur weiter reduziert werden. Motlik sieht in diesem Ansatz noch einen weiteren Vorteil: Wenn man möchte, kann man diesen Architekturtyp über die Zeit hinweg in eine rein serviceorientierte Architektur umwandeln. Auf diesem Wege werden auch die bei einer rein serviceorientierten Infrastruktur zunächst auftretenden Produktivitätseinbußen begrenzt.

Bei einer rein serviceorientierte Architektur existiert im Gegensatz zur Architektur mit monolithischem Kern keine Hauptcodebasis, die für die Steuerung der restlichen Services verantwortlich wäre. Stattdessen kontrolliert jeder Service seine eigene Geschäftsfunktion (und seine Daten); alle Services spielen in der Gesamtinfrastruktur annähernd die gleiche Rolle. Bei Architekturen mit monolithischem Kern sind es in der Regel die Anwendungen, die eine Anfrage erhalten, die die Modelle enthalten, mit der Datenbank kommunizieren und den Großteil der Geschäftsfunktionen ausführen. Bei einer rein serviceorientierten Architektur hingegen kontaktiert eine Anwendung jeweils andere Services und erhält eine einheitliche Antwort – ohne dabei die gesamte Geschäftslogik zu beinhalten. Motlik zufolge bieten rein serviceorientierte Architekturen auf lange Sicht gesehen bedeutende Vorteile im Hinblick auf die Skalierung sowie die Zusammensetzung der Infrastruktur. Genau wie Fowler ist er jedoch der Ansicht, dass die Verwaltung der Infrastruktur dem Team deutlich mehr abverlangt als bei anderen Lösungen.

Weitere Vor- und Nachteile, Praxisbeispiele

Im Hinblick auf die Frage, wann welcher Architektureinsatz zum Einsatz kommen sollte, hat Asaf Yigal (Logz.io) einige Stimmen aus der Praxis zusammengetragen. David Fullerton von Stack Exchange beispielsweise bezeichnet monolithische Lösungen als „langweile Architektur, die zu aufregenden Ergebnissen führt“. Stack Exchange fährt offenbar gut mit monolithischer Architektur, die Skalierung scheint keine Probleme zu bereiten: Fullerton zufolge wickelt Stack Exchange 4 Milliarden Requests pro Monat und 800 Millionen SQL-Abfragen am Tag ab. Ein Hauptvorteil monolithischer Architekturen ist Yigal zufolge, dass sie eine klare und schnelle Entwicklungsrichtung aufweisen; bereits eingespielte Teams können in ihrem Rahmen direkt produktiv und zielgerichtet zusammenarbeiten. Des Weiteren, so Yigal, gestaltet sich die Bereitstellung schnörkellos. Auch die Skalierung ist relativ einfach: Das Team muss mittels Load Balancer mehrere Kopien auf mehreren virtuellen oder dedizierten Servern laufen lassen.

Und wie sieht es bei Microservice-Architekturen aus? James Barrese (PayPal) zufolge ist sein Unternehmen zu Microservices gewechselt, um mehr Updates in kürzeren Abständen realisieren zu können. Demnach eignen sich Microservices besser für unabhängig arbeitende, projektorientierte Teams, die mitunter über die ganze Welt verteilt sind und auf verschiedenen Plattformen arbeiten. Einzelne Teammitglieder können sich zu Experten für bestimmte Funktionen entwickeln, wodurch immer kürzere Upgrade-Releasezyklen ermöglicht werden. Fehler produzierende Komponenten können einfacher isoliert und bei Bedarf offline genommen werden. Last but not least müssen Unternehmen nicht in einen bestimmten Entwicklungsstack investieren.

PricewaterhouseCoopers, die u. a. in der Unternehmens- und Managementberatung tätig sind, sehen in Microservices denn auch die Zukunft der Softwarearchitektur: Monolithische Architekturen seien für die heutzutage mitunter erforderlichen, schnellen Funktionalitätsänderungen schlichtweg nicht geeignet. Yigals Einschätzung zufolge sind die Monolithe allerdings alles andere als tot, u. a. da sie die effektivste Lösung für einen schnellen Prototypenbau darstellen. Yigal ist der Ansicht, dass eine Kombination beider Ansätze derzeit der beste Weg ist – zumindest bis zu dem Tag, an dem leistungsstarke AIs zur Verfügung stehen werden.

Aufmacherbild: Black monolith in the desert von Shutterstock / Urheberrecht: Draw

Verwandte Themen:

Geschrieben von
Michael Thomas
Michael Thomas
Michael Thomas studierte Erziehungswissenschaft an der Johannes Gutenberg-Universität Mainz und arbeitet seit 2013 als Freelance-Autor bei JAXenter.de. Kontakt: mthomas[at]sandsmedia.com
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: