Suche
Diskussion um Microservice-Architekturen

Stefan Tilkov antwortet auf Martin Fowler: Brauchst du Microservices, bau dir Microservices!

Moritz Hoffmann

Vor kurzem hat sich Martin Fowler in der aktuellen Diskussion um Microservices zu Wort gemeldet, indem er das negative Bild von monolithischen Software-Architekturen zurechtrückt und die großen Systeme als ersten Ausgangspunkt von Microservices empfiehlt. Nun widerspricht Stefan Tilkov: Monolithen seien gerade kein geeigneter Ansatz für den Bau von Microservices. Werden sie zerlegt, sieht das Ergebnis meist anders aus, als von den Entwicklern erhofft.

Tilkov hält die von Fowler geäußerten Empfehlung, dass am Anfang von Microservices ein Monolith zu stehen habe, für die genau verkehrte Herangehensweise. Auch das bereits vor einer Weile geäußerte Argument von Sam Newman, man habe mit einem bereits gebauten System schlichtweg mehr Material, um damit zu arbeiten, zu testen und die Verteilung der Anwendungen Schritt für Schritt anzugehen, überzeugt Tilkov keineswegs. Zu schwierig und bisweilen unmöglich gestalte sich die Partitionierung in der Praxis. 

Mit Fowler empfiehlt er, die Entscheidung für oder gegen eine Zerlegung nicht leichtfertig zu treffen, zum Beispiel ohne benennbaren Grund oder noch schlimmer, ohne eine genaue Kenntnis des Anwendungsbereichs, für den das monolithische System zerteilt werden soll. 

If you are actually able to build a well-structured monolith, you probably don’t need microservices in the first place. Which is OK!

Besser, und für Tilkov der Idealfall, ist die Produktion einer zweiten Systemversion.

Kleine feine Anwendungen

Freilich aber gibt es bisweilen gute Gründe für die Zerlegung eines Monolithen. Der für Tilkov entscheidende hängt eng mit der von ihm hochgeschätzten Eigenschaft von Microservices zusammen, dass einzelne Teilstücke innerhalb eines großen Systems unabhängig von einander liefern können. Mit der Einrichtung schwierig zu durchdringender Grenzen zwischen verschiedenen Teilen des Systems kann auch die Entwicklung parallel und mehrschichtig vonstatten gehen.

Eine solche Strategie kann dabei helfen, keine falschen bzw. zu engen Abhängigkeiten zwischen Komponenten herzustellen. Tilkov ist sich darüber im Klaren, dass diese Fehler auch beim Bau monolitischer Systeme vermeidbar sind. Allerdings erfordere dies eiserne Disziplin und das strikte Befolgen von vielen Regeln, während die Microservice-Architektur einen Bewegungsrahmen setze, der Entwickler quasi intuitiv von Fehlern abhält.

Beim Schälen des Monolithen

Das sei allerdings nur der Fall, wenn die Microservices bereits als solche angelegt worden sind. Und hier liegt in Tilkovs Diskussionsbeitrag der Hund begraben. Startet man mit dem Bau eines Monolithen, um diesen zu einem späteren Zeitpunkt zu zerlegen, wird man es in der Regel sehr schwer haben, voneinander abgrenzbare Einheiten in einem klar strukturierten System sinnvoll aneinander zu bauen. Die sehr enge und dichte Verflechtung von Anwendungen sei schließlich genau die Eigenschaft, die einen Monolithen charakterisiert.

Schon auf der technischen Seite könne der Plan einer unkomplizierten Monolithen-Partitionierung in unabhängige Anwendungen nicht aufgehen:

The parts will rely on features of the platform they all use. They’ll communicate based on abstractions that are shared because they all use the same libraries. They’ll communicate using means that are only available when they are hosted in the same process.

Schlimmer noch teilten sich die einzelnen Monolithen-Komponenten üblicherweise Domain-Objekte und das gleiche Persistenzmodell. Sogar die – für Einzelprojekte und die dafür verwendete IDE sehr bequeme – Eigenschaft einer einfachen Refaktorierbarkeit und Beweglichkeit, machten es sehr schwierig, derart aufgebaute System zu zerlegen.

Subsysteme – Zwischen Monolith und Microservices?

Schon zu Beginn des System-Baus sollte die Option einer Zerlegung genau geprüft werden und im weiteren Prozess präsent bleiben. Deshalb empfiehlt Tilkov in Abgrenzung zu Fowler, beim Bau großer Systeme ein besonderes Augenmerk auf die verwendeten Subsysteme zu legen und diese so unabhängig wie möglich anzulegen. Jedes Subsystem soll dabei einen eigene Zyklus von Entwicklung, Deployment und Delivery beinhalten oder vielleicht sogar mit einer eigenen Architektur ausgestattet werden.

Als Ergebnis erhalte man zwar nicht unbedingt das, was gängigerweise als Microservices bezeichnet wird, aber, so Tilkov, ein sehr kraftvolles Konzept für den Bau großer Systemen. Tilkov bezieht sich mit seinem Einspruch gegen Fowler nicht nur auf theoretische Überlegungen, sondern macht vor allem die erprobte Anwendung des von ihm vorgeschlagenen verteilten Systems aus Subsystemen geltend.

Tragfähige Architekturen?

Hervorgehoben wird dabei das Beispiel des Otto-Onlineshops, dessen Bau mit Microservices in einer Vertikalen-Architektur in einer Dokumentation nachzulesen ist. Mit den Hinweisen auf seine praktischen Erfahrungen will Tilkov aber keineswegs über die Grundregeln bei der Entscheidung für Monolithen oder Microservices hinwegtäuschen. Dieser Entscheidung müsse die genaue Kenntnis des Einsatzgebiets und der möglichen Konsequenzen für die weitere Entwicklung zugrunde liegen:

If you decide to build things using a microservices approach, you need to be aware that while it will be a lot easier to make localized decisions in each individual part, it will be much harder to change the very boundaries that enable this. Refactoring in the small becomes easier, refactoring in the large becomes much harder.

Auch für den von ihm verfolgten Ansatz gilt:

Beware of architectural recipes that are too simple and too obvious.

Die Diskussion um Microservices jedenfalls scheint noch nicht an ihr Ende gekommen…

Aufmacherbild: Construction of multi-storey buildings on monolithic technology von Shutterstock.com
 Urheberrecht: shinobi

Geschrieben von
Moritz Hoffmann
Moritz Hoffmann
Moritz Hoffmann hat an der Goethe Universität Soziologie sowie Buch- und Medienpraxis studiert. Er lebt seit acht Jahren in Frankfurt am Main und arbeitet in der Redaktion von Software und Support Media.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.