Seite 2: Argument #3: Konsistenz und Transaktionen

Inhaltsverzeichnis

Kommen wir zum dritten häufig genannten Argument gegen Microservices, nämlich zu den Herausforderungen im Bereich Konsistenz und Transaktionsmanagement. Ich hatte bereits kurz das CAP-Theorem angesprochen, und in verteilten Systemen steht hier das "A" (Verfügbarkeit) häufig weit über dem "C" (Konsistenz). Das ist deshalb so, weil die kontinuierliche und dauerhafte Lauffähigkeit des Gesamtsystems deutlich wichtiger ist, als die punktuell garantierte strenge Konsistenz.

Und das heißt übrigens nicht, dass verteilte Systeme nicht konsistent seien. Es heißt nur, dass sie nicht Strong-Consistent sind, sondern Eventual-Consistent. Mit anderen Worten: Es dauert manchmal einen kleinen Augenblick, bis die Konsistenz über mehrere Services hinweg tatsächlich hergestellt ist.

Dieser Punkt sorgt häufig für Aufregung, weil es dann rasch heißt, es ginge nicht ohne Strong-Consistency und so weiter. Und das stimmt auch – zumindest in einigen, ganz wenigen, gut begründeten Ausnahmefällen. In den meisten typischen Business-Anwendungen ist Eventual-Consistency hingegen vollkommen ausreichend. Und anders, als viele Entwicklerinnen und Entwickler häufig glauben, handelt es sich dabei nicht um ein technisches Problem oder eine technische Herausforderung. Stattdessen ist es eine Frage des Risikos und der Wahrscheinlichkeit, um die sich das Business kümmern muss.

Ein Beispiel: Falls es an einer Hochschule wegen Eventual-Consistency dazu kommen kann, dass der letzte Platz in einem Seminar doppelt vergeben wird, muss man sich die Frage stellen, wie schlimm das ist. Und diese Frage ist, wie zuvor erwähnt, nicht technischer, sondern ausschließlich fachlicher Natur. Um sie adäquat beantworten zu können, muss man zunächst wissen, wie häufig der Fall eintreten kann und was dann die Konsequenzen sind. Auf andere Art formuliert: Wie hoch ist das Risiko im Verhältnis zur Wahrscheinlichkeit und was geht im schlimmsten Fall schief? Wenn die Antwort darauf ist, dass einmal in fünf Jahren eine Person mehr im Seminar sitzen könnte, dann ist das – ehrlich gesagt – völlig in Ordnung.

Selbstverständlich möchte ich damit nicht sagen, dass es nicht Bereiche oder Themen gäbe, wo Strong-Consistency zwingend erforderlich ist. Ich sage nur, dass es in vielen typischen Web- und Cloud-Anwendungen völlig in Ordnung ist, wenn es "nur" Eventual-Consistent ist. Und das wiederum kann ich aus jahrelanger Erfahrung in der Konzeption, im Entwurf und in der Entwicklung von Microservices bestätigen: Strong-Consistency wird in 95 % der Fälle massiv überschätzt. Die Wahrheit ist, dass in nahezu allen Fällen Eventual-Consistency gänzlich ausreichend und gut genug ist. Insofern kommt es bei diesem Argument letztlich darauf an, ob man einen dieser wenigen begründeten Ausnahmefälle hat oder nicht. Pauschal betrachtet, sind Konsistenz und Transaktionalität kein Argument gegen Microservices.

Argument #4: Entwicklungs- und Betriebskosten

Kommen wir zum fünften Argument gegen Microservices, nämlich den angeblich höheren Entwicklungs- und Betriebskosten. Häufig wird behauptet, Microservices seien ein Problem, weil ein einzelnes Team mit den zahlreichen Services zu viele Kontextwechsel hätte. Und wissen Sie was? Da bin ich ganz bei Ihnen! Es hat allerdings auch niemand gefordert, dass Sie Microservices mit einem einzigen Team umsetzen sollen.

Im Gegenteil! Eigentlich ist das Konzept der Microservices, bei dem es, wie anfangs erwähnt, um Unabhängigkeit geht, nämlich prädestiniert dafür, dass man mit unterschiedlichen Teams parallel an den verschiedenen Services arbeiten kann. Das heißt natürlich nicht, dass sich Microservices nur dann umsetzen lassen, wenn pro Service ein dediziertes Team bereitsteht. Aber es gibt ja noch etwas zwischen den Extremen. Meiner Meinung nach ist es überhaupt kein Problem, wenn ein Team eine Handvoll Services betreut (je nachdem, wie komplex und umfangreich die Services sind).

Wenn Sie aber an dem Punkt sind, wo ein einzelnes Team 20 oder gar 50 Services betreuen müsste, dann sind entweder die Services falsch geschnitten, Ihr Team ist falsch aufgestellt oder Sie haben schlicht und ergreifend zu wenige Teams. Daher sind Microservices primär dann sinnvoll, wenn es um das fachliche Zerlegen geht, wenn es um Unabhängigkeit geht, und wenn diese Unabhängigkeit sich auch in den Organisationsstrukturen widerspiegelt. Ansonsten wird es vermutlich eher schwierig werden. Wenn man aber mehrere Teams hat, dann sind Microservices ein sehr praktischer Ansatz, weil sie es dann nämlich erlauben, den Fokus auf nur einen Teil der Domäne legen zu müssen, und weil sie klare und explizite Schnittstellen erzwingen.

Und was die Betriebskosten angeht: Hier wird oft mit Monitoring, Logging, Alerting und so weiter argumentiert. Aber mal ganz ehrlich: Das brauchen Sie doch für einen Monolithen genauso? Und wo ist jetzt der große Unterschied, ob man nun 2 oder 20 oder 200 Container überwachen muss? Tatsächlich verstehe ich hier den Punkt nicht, denn der Aufwand steigt nicht linear mit der Anzahl der Container, sondern den größten Aufwand hat man damit, das ganze Monitoring & Co. an sich überhaupt einmal einzurichten und aufzusetzen. Wenn das jedoch einmal erledigt ist, stellt der Rest eher das i-Tüpfelchen dar, was den Aufwand angeht.

Argument #5: Koordination und Kommunikation

Und damit kommen wir zum fünften häufig genannten Argument gegen Microservices, nämlich den organisatorischen Herausforderungen. Hier wird in der Regel die zusätzlich notwendige Koordination und Kommunikation zwischen den Teams beklagt. Dabei geht es um Fragen wie:

• Wer macht was?
• Wer definiert welche API?
• Wer richtet sich nach wem?
• …

Um diese Fragen zu klären, gibt es zahlreiche etablierte API-Patterns. Tatsächlich finde ich von allen genannten Argumenten dieses das mit Abstand schwächste, denn Microservices schneidet man ja nicht irgendwie, sondern entlang fachlicher Grenzen. Und dieses Schneiden entlang fachlicher Grenzen muss ohnehin gemacht werden, auch wenn man einen Monolithen baut, denn auch bei Modulen und Komponenten muss überlegt werden, wie und wo geschnitten wird.

Würde man das einfach nicht machen, bekäme man sehr schnell den berühmt-berüchtigten "Big Ball of Mud". Das heißt, wenn dieses Schneiden ohnehin erforderlich ist und wenn man sich dazu ohnehin Gedanken machen muss über Zuständig- und Verantwortlichkeiten, dann ist auch der Aufwand in jedem Fall der gleiche. Daran ändert sich nichts, ob diese Diskussionen nun innerhalb eines einzelnen Teams oder über mehrere Teams hinweg verteilt stattfinden. Der große Vorteil von Microservices ist dann, dass sie die Teams dazu zwingen, diese Diskussionen ordentlich und sorgfältig zu führen, ganz einfach deshalb, weil eine fachliche Grenze zugleich auch eine echte technische Grenze darstellt, die sich nicht ignorieren lässt.

Fazit

Es ergeben sich also folgende fünf Aspekte:

1. Man sollte hinterfragen, ob man die Notwendigkeit zum fachlichen Zerlegen hat.
2. Was Deployment und Infrastruktur angeht, sprechen diese eher für Services, weil das den teuersten Teil des Ganzen (nämlich die fachliche Entwicklung) vereinfacht.
3. Man muss die Konsistenz hinterfragen, aber das ist kein technisches, sondern ein fachliches Problem.
4. Die Entwicklung von Microservices funktioniert besonders dann gut, wenn man auch organisatorisch verteilt aufgestellt ist, sprich, in mehreren Teams entwickelt.
5. Koordination und Kommunikation sind in jedem Fall erforderlich, das macht daher schlussendlich keinen nennenswerten Unterschied.

Services und insbesondere Microservices lohnen sich als Architekturansatz dann, wenn man fachlich gesehen sehr komplexe Anwendungen baut und/oder wenn man mehrere Teams hat, die an einem großen Projekt zusammenarbeiten müssen, man sich dabei jedoch eine gewisse Unabhängigkeit bewahren möchte. Und wenn das gegeben ist, dann sind Microservices höchstwahrscheinlich eine gute Idee, andernfalls wahrscheinlich eher nicht oder nur bedingt.

Und jetzt mal ganz ehrlich: Ist diese Erkenntnis wirklich eine Überraschung? Ich glaube nicht … stattdessen gilt wieder einmal, dass man das richtige Werkzeug für das vorliegende Problem auswählen sollte, und man deshalb einen gewissen Überblick über die zur Verfügung stehenden Werkzeuge haben sollte. Wer hingegen nur einen Hammer kennt, für die oder den wird jedes Problem wie ein Nagel aussehen. (who)