Vor- und Nachteile im Überblick

Microservices: Fluch oder Segen?

Michael Thomas

© Shutterstock / faithie

Erst kürzlich hatte sich der Veteran der Softwarearchitektur Martin Fowler in die Diskussion um Microservices eingemischt und davor gewarnt, sie als Basis eines Systems zu verwenden. Da seine Meinung zum Thema jedoch nicht abgeschlossen ist, legte er nun mit einer Gegenüberstellung der Vor- und Nachteile von Microservices nach. Denn, wie Fowler ausführt, sind Microservices kein Allheilmittel, sondern verursachen wie jeder Architekturstil auch gewisse Kosten, die im Blick behalten werden müssen.

Klar abgesteckte Modulgrenzen

Zum Einstieg etwas Positives: Einen gewaltigen Pluspunkt für Microservices sieht Fowler in den klar abgegrenzten Modulen. Besteht ein System aus voneinander entkoppelten Teilen, so ist es deutlich einfacher, Änderungen an ihm vorzunehmen, da man zum einen nicht das komplette System überblicken muss und zum anderen die zu ändernden Teile recht leicht aufzufinden sind. Dieser Umstand gewinnt Fowler zufolge insbesondere dann an Gewicht, wenn die Software und die Entwicklerteams – die mitunter auf geographisch weit auseinander liegende Standorte verteilt sind und nur eingeschränkt miteinander kommunizieren – an Größe gewinnen. Zwar kann laut Fowler auch ein monolithisches System über eine brauchbare modulare Struktur verfügen, allerdings sei dies eher eine Seltenheit.

API Confernce 2019
 Maik Schöneich

gRPC – Ein neuer heiliger Gral?

mit Maik Schöneich

Oliver Drotbohm

REST Beyond the Obvious – API Design for Ever Evolving Systems

mit Oliver Drotbohm (Pivotal Software, Inc.)

 

Software Architecture Summit 2019
Stephan Pirnbaum

Lasst uns einen Monolithen (z)erlegen

mit Stephan Pirnbaum (buschmais GbR)

Scott Davis

Making Your Mobile Web App Talk

mit Scott Davis (ThoughtWorks)

Ein Schlüsselelement von Microservices ist das dezentralisierte Datenmanagement, was bedeutet, dass jeder Service seine eigene Datenbank verwaltet und jeder andere Service den Weg über dessen API nehmen muss, um sie zu erreichen, was den Bedarf an sogenannten Integration Databases, die als Datenspeicher für mehrere Anwendungen dienen und bei größeren Systemen eine Quelle problematischer Verknüpfungen sein können, eliminiert.

Sind die Grenzen nicht richtig abgesteckt, kann die Modularität Fowler zufolge jedoch auch zum Nachteil werden, was für eine Monolith-First-Strategie sprechen würde.

Ob und wie gut ein System auf Modularität reagiert, kann laut Fowler erst dann abgeschätzt werden, wenn eine gewisse Zeit verstrichen ist. Da Microservices ein recht junges Phänomen sind, werden seiner Einschätzung nach also einige Jahre ins Land gehen, bevor man mit Sicherheit sagen kann, dass sie zu besserer Modularität führen. Außerdem seien, so Fowler, Early Adopter meist gewitzter als durchschnittliche Teams – ob diese also mit Microservices bessere Ergebnisse erzielen, bleibe also ebenfalls abzuwarten.

Verteilung

Microservices nutzen ein verteiltes System, um die Modularität zu verbessern. Doch ein Nachteil verteilter Software ist Fowler zufolge der Umstand, dass sie eben verteilt ist; es ergibt sich eine größere Komplexität.

Eine der aufgworfenen Kosten betrifft die Performance: Eine große Anzahl von Remote-Services, die selbst wiederum auf Remote-Services zurückgreifen, kann sich Fowlers Ansicht nach zu einem beträchtlichen Latenzproblem addieren. Dies könne zwar durch feinkörnigere Calls abgemildert werden, allerdings werde dadurch das Programmiermodell verkompliziert. Auch durch Asynchronität könne den Performanceproblemen zu Leibe gerückt werden, doch gestalte sich deren Realisierung schwierig, was auch für das Debugging gelte.

Neben der Performance spielt laut Fowler auch die Zuverlässigkeit eine große Rolle: Denn Remote Calls können jederzeit scheitern. Mit Microservices wachse deshalb die Zahl der potentiellen Fehlerquellen. Zwar könne man, so Fowler, sein Design dahingehend ausrichten, die größere Komplexität bleibe jedoch.

Konsistenz

Auch die Konsistenz schlägt Fowlers Ansicht nach bei Microservices negativ zu Buche. Als Beispiel nennt er eine Website, an der man Änderungen vornimmt, die nicht unmittelbar nach einem Refresh der Seite, sondern erst mit einer deutlichen Verzögerung angezeigt werden. Können derartige Inkonsistenzen bei Websites noch unter „ärgerlich, aber verschmerzbar“ verbucht werden, können sie, wenn beispielsweise die Geschäftslogik aufgrund inkonsistenter Informationen falsche Entscheidungen trifft, deutlich schwerwiegendere Folgen haben.

Auch aufgrund ihres dezentralisierten Datenmanagements können Microservices Fowler zufolge für Konsistenzprobleme verantwortlich sein: Während man bei einem Monolithen ganze Teile in einem Rutsch updaten kann – wobei anzumerken ist, dass sie keineswegs frei von Inkonsistenzproblemen sind – müssen bei Microservices mehrere verschiedene Ressourcen aktualisiert werden.

Unabhängige Bereitstellung

Eine der großen Umwälzung in der IT-Landschaft der letzten 10 Jahre sind, Continuous Delivery und Co. sei Dank, die regelmäßigen, manchmal täglichen Releases. Diese Entwicklung ist laut Fowlwe eng mit der Microservices-Bewegung verflochten.

Bei der Bereitstellung von Monolithen könnw, so Fowler weiter, eine noch so kleine Änderung alles zum Einsturz bringen. Da eines der Schlüsselprinzipien von Microservices darin besteht, dass Services Komponenten sind und damit unabhängig voneinander getestet und bereitgestellt werden können, ziehen bei ihrem Einsatz eventuelle Probleme im Gegensazu dazu nicht das komplette System in Mitleidenschaft.

Eine rasche Anwendungsbereitstellung und die rasche Bereitstellung von Infrastruktur sind Fowler zufolge Grundvoraussetzungen für Microservices; wolle man mehr als die Basics umsetzen, müsse man auf Continuous Delivery zurückgreifen. Der Vorteil dabei sei, dass man rasch auf Veränderungen im Markt reagieren und Features potentiell schneller verfügbar machen könne als die Mitbewerber

Betriebskomplexität

Die Möglichkeit, kleine unabhängige Einheiten bereitzustellen ist Folwer zufolge zwar positiv für die Entwicklung, das Handling von zahllosen sich schnell wandelnden Microservices stelle den Bereich Operations allerdings vor eine nicht zu unterschätzende Herausforderung. Dieser Umstand macht Fowlers Ansicht nach die Automatisierung und Kollaboration, die von Continuous Delivery gefördert wird, bei Microservices zur Grundvoraussetzung.

Auch durch die höheren Anforderungen, die die Verwaltung und Überwachung der Services mit sich bringen, so Fowler weiter, wird die Betriebskomplexität gesteigert. Die Befürworter der Microservices würden zwar darauf hinweisen, dass diese aufgrund ihrer Größe leichter zu verstehen sind, dabei bestehe allerdings die Gefahr, dass Komplexität nicht eliminiert, sondern sozusagen in die Verbindungen der Services untereinander „ausgelagert“ werde, was beispielsweise das Debugging erschwere.

Der Umgang mit der höheren Betriebskomplexität erfordert Fowler zufolge neue Skills und Tools, insbesondere bei letzteren sieht er jedoch noch dringenden Verbesserungsbedarf. Noch dringlicher sieht er jedoch den Wandel hin zu einer DevOps-Kultur, die eine engere Zusammenarbeit zwischen allen Akteuren des Softwareentwicklungsprozesses fördert.

Technologische Diversität

Da Microservices unabhängige Einheiten darstellen, haben Entwickler bei der Wahl der eingesetzten Technologien quasi freie Hand. So können Fowler zufolge zahllose verschiedene Sprachen, Bibliotheken, Frameworks und Datenspeichertechnologien zum Einsatz kommen, weshalb Entwickler in der Lage sind, jeweils das beste Werkzeug für eine anstehende Aufgabe auszuwählen.

Den größten Vorteil sieht Fowler dabei in dem Umstand, dass im Gegensatz zu Monolithen beispielsweise verschiedene Versionen einer Bibliothek gleichzeitig zum Einsatz kommen können. Allerdings, so Fowler weiter, bestehe die Gefahr, dass die Diversität ein für die Organisationen lähmendes Ausmaß annimmt. Aus diesem Grund verlassen sich die meisten auf eine relativ eng begrenzte Auswahl an Technologien, die bevorzugterweise mit gemeinsamen Tools, beispielsweise im Bereich Monitoring, bearbeitet werden können.

Einen letzten Pluspunkt stellt Fowlers Meinung nach die Möglichkeit des Experimentierens dar. Denn im Gegensatz zu Monolithen, bei denen die frühe Festlegung auf eine bestimmte Sprache oder ein bestimmtes Framework nur schwer zu revidieren sei, eröffneten Microservices Spielräume, in denen die unterschiedlichsten Technologien ausprobiert werden können.

Fazit

Microservices sind kein Allheilmittel. Nicht jedes System, nicht jede Lösung profitieren von ihnen, vielmehr müssen die Kosten und der Nutzen von Microservices jeweils individuell abgewogen werden. Was in der einen Organisation funktioniert, kann in der anderen zum Desaster werden.
Microservices, so Fowler, drängen der Produktivität Kosten auf, die nur in komplexeren Systemen wieder wett gemacht werden können. Wenn man der Komplexität des Systems auch mit einer monolithischen Architektur beikommen könne, solle man dehalb keine Microservices nutzen.

Aufmacherbild: Open Source Technology or Technologies as Abstract von Shutterstock / Urheberrecht: kentoh

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
4000
  Subscribe  
Benachrichtige mich zu: