Monolith vs. Microservices Part 5
Optimale Lösung ohne Kompromisse vs. technologie-zoo
Abgesehen von der einzusetzenden Hardware und Ablaufumgebung ist auch die Wahl der einzusetzenden Technologien und Bibliotheken eine zentrale Entscheidung in Projekten. Wobei – das gilt ja nur für Monolithen. Bei einer Microservice-Architektur kann für jeden Service der am besten geeignete Technologiestack eingesetzt werden. Oder?
Zusammenfassung
In aller Regel ist Technologie kein Selbstzweck: Der eingesetzte Technologiestack muss funktionale und nicht-funktionale Anforderungen bedienen können. Einerseits sollte die Möglichkeit, unterschiedliche Technologien zu nutzen, wo sie sinnvoll sind, im Kontext von Microservices auch genutzt werden, andererseits sollte abgewogen werden, welche Technologien man tatsächlich einsetzen möchte (zum Beispiel lieber etablierte Bibliotheken mit großer Community als Bibliotheken, die von Einzelpersonen entwickelt werden und in Gefahr sind auszusterben). Außerdem gilt: Je größer der Technologie-Zoo in einem Projekt wird, desto höher wird der Aufwand für die Einarbeitung neuer Teammitglieder, die Wartung und Dokumentation der vielen Technologieabhängigkeiten. Deshalb sollten die einzusetzenden Technologien beschränkt, aber begründete Ausnahmen zugelassen werden.
In einer monolithischen Architektur stellt sich diese Frage gar nicht – hier gibt es für das ganze Projekt nur einen festen Technologiestack.
Moni: „Welchen Technologiestack setzen wir denn eigentlich für die App ein?“
Michi: „Der Technologiestack soll für jeden fachlichen Prozess individuell gewählt werden, da sich für verschiedene Anforderungen unterschiedliche Technologien etabliert haben. Jedes Team kann so für seine fachlichen Prozesse die geeignete Technologie wählen und damit am effizientesten seine User Stories umsetzen.“
Moni: „Wer soll diesen Technologie-Wildwuchs denn warten und pflegen? Bei deinem Ansatz können Entwickler:innen gegebenenfalls nur mit Technologie-Schulung von einem Team in das andere wechseln. Das kann aber notwendig werden, wenn für einen fachlichen Prozess mehr Anforderungen existieren als für andere. Ich würde einen bewährten Technologiestack für die gesamte Anwendung einsetzen und damit Flexibilität bei der Teambesetzung und Wartbarkeit gewährleisten.“
Moni und Michi diskutieren über den Technologiestack, der für die Restaurant-App eingesetzt werden soll. Michi erklärt, dass es innerhalb einer Microservice-Architektur möglich ist, dass unterschiedliche Services eine unterschiedliche Technologie einsetzen. Ähnlich wie bei der Wahl der Ablaufumgebung und Hardware müssen bei einer Microservice-Architektur keine Kompromisse gemacht werden. Dies ist möglich aufgrund einer Eigenschaft von Microservices: Sie kommunizieren untereinander über sprachunabhängige Schnittstellen. Das heißt der Bestellprozess könnte in Node.js implementiert sein, die Routenoptimierung in GO und die Bestandsverwaltung in Java.
Unterschiedliche Technologien einzusetzen, kann zum Beispiel daher kommen, dass es schon fertige Bibliotheken für einzelne Sprachen gibt – oder dadurch, dass nicht alle Teams aufgrund unterschiedlicher Ausbildung in der gleichen Programmiersprache entwickeln können.
Moni ist dieser Wildwuchs an unterschiedlichen Technologien und einzusetzenden Frameworks zu hoch. Viele verschiedene Technologien sorgen dafür, dass Projektmitglieder nicht frei zwischen Teams wechseln können, wenn der Bedarf bei einem Team gerade größer ist als bei einem anderen Team. Außerdem kann es im Extremfall passieren, dass Teile der Software nicht mehr wartbar sind, weil alle Entwickler:innen mit dem Know-how für eine spezielle Technologie das Projekt verlassen haben und eine Weiterentwicklung ohne dieses Know-how nicht leicht möglich ist.
