09. November 2020 / von Martin Lehmann, Dr. Renato Vinga-Martins

Was bedeutet

Komplexität bei

Microservices ?

Wir brauchen doch gar keine Microservices, oder…?

Bei Accso wollen wir Microservices bereits in frühen Entscheidungsphasen und nicht nur technisch einschätzen können. Dafür haben wir eine Reihe von Einflussgrößen herausgearbeitet, die für oder gegen den Einsatz von Microservices sprechen, und in ein Spinnennetzdiagramm übertragen. Diese Darstellung haben wir in Vorträgen bei der Java User Group Frankfurt [1] bzw. beim Frankfurter Entwicklertag [2] bereits präsentiert und greifen diese Darstellung hier in dieser Serie aus fünf Beiträgen nochmal auf.

In diesem Beitragsteil geht es um organisatorisch-fachliche Einflussgrößen des Spinnennetzdiagramms in Abbildung 1, und zwar besonders um Komplexität und um Autonomie. Zum Abschluss dieser Blog-Serie werden wir anhand des vollständigen Spinnennetzdiagramms die zwei Architekturstile „Monolith“ und „Microservices“ einander gegenüberstellen und mittels der vorgestellten Einflusskriterien bewerten.

Architekturbewertung Microservices
Abbildung 1: Fachlich-organisatorische Einflusskriterien zur Architekturbewertung im Spinnennetzdiagramm
Deploymentstrategien Monolith vs Microservices
Abbildung 2: Die Deploymentstrategien von Monolith (links) und Microservices (rechts) bestimmen die Releasezyklen.
Geschäftspriorisierung Netflix
Abbildung 3: Die Geschäftspriorisierung bei Netflix fordert Flexibilität.
Geschäftspriorisierung Rewe
Abbildung 4: Die Geschäftspriorisierung bei REWE fordert Wachstum.

Microservice-Architekturen fördern Wachstum und Flexibilität

Wie in Abbildung 2 dargestellt, stehen Monolith und Microservices einander in der Diskussion als zwei Architekturextreme gegenüber. Der Monolith fasst fachliche Weiterentwicklung in einem Release bzw. dessen Deployment zusammen. Die komplexen Abhängigkeiten führen zu den bekannten langen Release-Zyklen: Zyklen von mehreren Monaten sind durchaus üblich. Die lose gekoppelten Microservices ermöglichen, jede Neuerung schnell, im Idealfall sofort in Produktion zu bringen. Die Frage ist, unter welchen Bedingungen wir uns entscheiden sollen, eher in Richtung der einen oder in Richtung der anderen Architektur zu gehen.

Es gibt viele Argumente für Microservices, das Thema ist in Literatur, Blogs, Büchern und Konferenzvorträgen ausgiebig beleuchtet worden [Fowler, Newman und Wolff]. Aber am Ende sind aus Geschäftssicht zwei Argumente entscheidend: das geschäftliche Wachstum und seine Änderungsgeschwindigkeit. Die Architektur muss uns deshalb ermöglichen, unsere Anwendungen auf Skalierbarkeit und Flexibilität hin zu optimieren.

Kosten und Nutzen sind abzuwägen

Aber die Vorteile einer Microservice-Architektur bekommen wir nicht umsonst. Unternehmen mit den Erfolgsstories wie Netflix priorisieren deshalb in der Regel deutlich ihre Geschäftsziele. Abbildung 3 zeigt beispielhaft, dass Netflix „Innovation“ an die erste Stelle setzt, vor „Zuverlässigkeit“ sowie vor „Effizienz“.

Auch für REWE ist (fachliches) Wachstum der Haupttreiber: 2014 ist REWE mit einer monolithischen Architektur gestartet und hat diese bis 2018 zu einer umfangreichen Microservice-Architektur umgebaut, wie Ansgar Brauner bei seinem JUG-Darmstadt-Vortrag am 16.01.2019 [3] anhand von Abbildung 4 dargestellt hat. In nur 5 Jahren ist die Entwicklermannschaft bei REWE auf 50 Teams gewachsen. Ein so starkes Wachstum kann nur mit einer ganz klaren Ausrichtung funktionieren.

Und um zu verstehen, was die Zielerreichung beeinflusst, betrachten wir den organisatorischen Rahmen.

Wie stellt sich Komplexität dar?

Eine Einflussgröße ist Komplexität. Wie in Abbildung 5 denken wir bei Komplexität normalerweise an etwas Riesiges mit vielen Verbindungen. Dieser Aspekt ist tatsächlich relevant, weil die Kommunikation mit der Anzahl der Kommunikationspartner zunimmt: Je mehr Entwickler und Teams die Anwendung implementieren, desto mehr Abstimmungsbedarf gibt es in der Regel. Autonom agierende Teams skalieren besser.

Doch das einfach konstruierte und verwirrend wirkende Doppelpendel ist ein Beispiel dafür, dass Größe allein nicht ausschlaggebend sein muss. Komplexes Verhalten gibt es auch in überschaubaren Szenarien. Der Bewegungsablauf des Doppelpendels in dem Video zeigt sehr schön das unvorhersehbare Verhalten, das durch Rückkopplungen entstehen kann.

Komplexität bedeutet Dynamik in nicht kontrollierbaren Wechselwirkungsketten.
Abbildung 5: Komplexität bedeutet Dynamik in nicht kontrollierbaren Wechselwirkungsketten.

Microservices adressieren Komplexität, indem sie Kopplung reduzieren

Allerdings betrachten wir im Zusammenhang mit Microservices die Komplexität vor allem aus einer Managementperspektive: Abbildung 6 von Martin Fowler zeigt den Produktivitätsverlauf von Microservices und Monolithen bei zunehmender Komplexität. Der Produktivitätsverlauf zeigt: Zunächst stehen Microservices gegenüber dem Monolithen schlechter dar. Der Grund dafür ist der Anfangsaufwand, den wir investieren müssen, um diesen Architekturstil zu lernen und um die notwendige Infrastruktur aufzubauen. Mit zunehmender Komplexität verlieren beide Architekturen an Produktivität. Der Verlust ist aber bei Microservices deutlich geringer, weil sie schließlich ihre Vorteile ausspielen können.

Fowlers Diagramm lässt sehr viel Interpretationsspielraum. Beispielsweise ist hier der Begriff Produktivität nicht klar definiert. Und es ist bekannt, dass es DIE Produktivität nicht gibt; in dieses Maß können viele Größen einfließen: der Geschäftswert, der Grad der Anforderungserfüllung, Lines of Code usw. Zehn Jahre vor diesem Diagramm hat Martin Fowler selbst geschrieben, dass es in der Software-Entwicklung so etwas wie Produktivität gar nicht gibt. Und in derselben Weise ist in dem Diagramm der Begriff Komplexität unscharf.

Aber auch wenn die beiden Begriffe keine klar definierbaren Metriken sind und deswegen ein Stück weit subjektiv bewertet werden, so verdeutlichen sie auf intuitive Weise den Zusammenhang und dass uns Microservices durch ihre Dekomposition im Umgang mit Komplexität helfen.

Microservices lohnen sich also erst bei komplexeren Vorhaben. Zum Beispiel wenn die Software allein wegen der schieren Größe zum Problem wird. Ein deutliches Indiz dafür ist das Gefühl, an einem gewissen Punkt unproduktiv zu werden und sich hauptsächlich mit Aufräumen zu beschäftigen. Doch mit Microservices entsteht ein beachtlicher Anfangsaufwand. Viele Aufgaben sind in einer Microservice-Architektur deutlich schwieriger: Aufgaben wie z. B. Debugging, Refactoring, Logging, Monitoring oder Security gehen beim Monolithen (mit einer Codebasis) verhältnismäßig einfach von der Hand, sind in einer verteilten Microservice-Architektur (mit vielen einzelnen Codebasen) viel mühsamer. Das ist der Preis für die Autonomie!

Das Diagramm enthält auch einen Hinweis: Der Team-Skill ist demnach ausschlaggebender als die Architekturentscheidung. Team-Skill ist zwar immer sehr wichtig, aber ist er auch wichtiger als die Architekturentscheidung? Wir halten diesen Hinweis für irreführend, weil er vom eigentlichen Thema ablenkt: Der Microservice-Vorteil entsteht durch die niedrigere Kopplung.

Aufgrund der Losen Kopplung bleiben Microservice-Architekturen trotz steigender Komplexität produktiv.
Abbildung 6: Aufgrund der Losen Kopplung bleiben Microservice-Architekturen trotz steigender Komplexität produktiv.

Microservice-Architekturen sind somit eine Lösung für komplexe Systeme. Im nächsten Teil dieser Serie beleuchten wir, wie man in komplexen Umgebungen mit Cynefin und PDCA gute Lösungen findet.

Autoren

Martin Lehmann Seit September 2010 als Cheftechnologe bei der Accelerated Solutions GmbH. Benutzt Java seit vielen Jahren und teilt gerne sein Wissen zu den Neuerungen in Java9, 10, 11 usw. wie beispielsweise zum Modulsystem Jigsaw.
Dr. Renato Vinga-Martins Renato ist seit November 2010 als Principal bei der Accelerated Solutions GmbH angestellt. Er hat über viele Jahre Erfahrungen in verschiedensten Portalprojekten gesammelt.
Weitere Artikel

Das könnte Sie auch interessieren