Die Bombe ist geplatzt: Amazon kehrt zurück zum Monolithen! Diese Headline ging im vergangenen Monat durch die Techszene. Ist, das nun das Ende von Microservices? Denn diese Headline wird den Hypecycle vermutlich stark abschwächen. Wer allerdings den Artikel genauer liest, der wird feststellen, dass Amazon¹ nicht den Rückschritt in einem klassischen Monolithen gemacht hat, sondern dort immer noch Dinge verteilt sind. Der Hauptgrund scheint weniger technische Exzellenz, sondern interne Amazon kosten zu sein.
Diese Bombe ermöglicht die Chance, dass gute Architekturen gebaut werden können, ohne dass Microservices gebaut werden mit der einzigen Begründung, Microservices zu bauen.
Es muss “Micro” sein
Damit kommen wir zum ersten Antipattern. Was bedeutet eigentlich Microservices? Bedeutet es, Services so klein wie möglich zu schneiden? Nicht zwangsläufig.
Wie wäre es, ein System so zu bauen, dass dies die kleinste selbst überlebende Einheit ist? Dies kann mit der self-contained systems Architektur erreicht werden. Durch diese Architektur wird das System so gebaut, dass Teams an einem geschlossenen System autonom arbeiten aber gleichzeitig müssen nicht ständig andere Systeme aufgerufen werden, welches die Architektur komplexer macht.
Es müssen nur Klassen und Methoden kopiert werden
Das Projekt “aus dem Monolithen ausbrechen” wird häufig damit gestartet, dass “einfach” Klassen in ein fremdes Projekt kopiert werden. Die Methodenaufrufe werden dann durch einen Restaufruf ersetzt.
Das ermöglicht zwar kleinere Deployments, aber verringert die Performance sehr durch die vielen Netzwerkcalls und erhöht die Gefahr, dass das System ausfällt. Sofern ein System in der Restcallkette ausfällt, fallen alle Systeme aus, da jeder Service aufeinander aufbaut. Dieses Phänomen wird auch distributed Monolth genannt.
Es wird nach Entitäten geschnitten
Das gleiche Problem kann entstehen, wenn nach Entitäten geschnitten wird. Eine viel bessere Möglichkeit ist es nach Workflows zu schneiden, welche einen Businesscase abbilden. Welche Businesscases gibt es? Dies kann man durch ein Event Storming Event erreichen.
Wie können diese Businesscases nun miteinander kommunizieren? Dafür können natürlich REST-Aufrufe genutzt werden, besser ist es allerdings, wenn man versucht, möglichst viel asynchron (z.B. Kafka) zu verarbeiten. Dies benötigt eine etwas andere Denkweise, allerdings hilft hier Übung sehr!
Es wird alles besser mit Microservices
Gerade in Migrationsprojekten stellt sich schnell Ernüchterung ein, wenn nicht alles besser wird. Kleinere Systeme sind nicht immer sinnvoll, aber ab einer gewissen Größe ist dies alternativlos². Es wird komplexer, da die Schnittstellen getestet werden müssen und gewisser Code dupliziert werden muss. Gleichzeitig muss man lernen umzudenken und die Nutzung von asynchronen Events lernen. Mit Kafka oder Pulsar ist hier auch meist ein neues Tool, welches gelernt werden muss.
Es wird aus architektonischen Gründen geschnitten
“Wieso ist der build rot?” “Wer hat diese Änderung gemacht?” Zwei Sätze, die vermutlich jeder schon einmal gehört hat, wenn mehrere Teams an einem Stück Software arbeiten. Auch wenn mit strengen Feature Branches oder Codeownerfiles gearbeitet wird, bleibt Stress nicht aus. Abgesehen von technischen Fehlern, haben Menschen unterschiedliche Präferenzen, die alle valide sind. Aus diesem Grund werden in der agilen Softwareentwicklung kleine Teams bevorzugt. Diese müssen sich nur mit sich in dem Team einigen und können daher effizient entscheiden.
Sofern nun allerdings alle Teammitglieder an der gleichen Software arbeiten helfen diese optimalen Entscheidungen nicht, da diese noch mit allen anderen abgestimmt werden müssen. Die beste Lösung ist es, diese Abhängigkeit zu kappen und die Systeme so zu entwickeln, dass beide Teams unabhängig voneinander arbeiten.
Der einzige andere Ausweg hier ist Hierarchie, was allerdings viel schlimmere Probleme auslöst…
¹ Aus meiner Sicht ist die Tatsache, dass Amazon Video ein eigenes System ist, schon ein Schritt der gegen einen “Bigball of Mud Monolith” spricht
² Natürlich ist es möglich, aber aus meiner Sicht ist dies ab einer gewissen Anzahl Mitarbeiter / Lines of Code die beste Alternative
