Monolith vs Microservice (Christian Nockemann)

Auswahlkriterien für die Entscheidung zwischen Wohlstrukturierter Monolith und Microservice

Organisatorische Strukturen

Die Teams der Organisation sollen unabhängig voneinander arbeiten können (Stichwort Conway's Law). Einzelne Teams müssen alle benötigten Kompetenzen abdecken. Beim Wechsel zu agilen Strukturen können Organisatorische Schulden entstehen. D.h., dass vorherrschende Zuständigkeiten verteilt werden und somit die Entwicklung an bestimmten Stellen verlangsamt werden kann.

Technologieunabhängigkeit

Verschiedene Microservices können mit unterschiedlichen Sprachen implementiert werden. Daraus folgt, dass die Organisation weniger spezifische Kompetenzen erwerben muss und so effektiver Entwickler und andere Fachkräfte anwerben kann.

Technische Schulden

Nachdem ein wohlstrukturierter Monolith erzeugt wurde, stellt sich die Frage, wie lange die Strukturen erhalten bleiben bzw. wie lange alle Prinzipien eingehalten werden. Die Praxis zeigt, dass dies selten lange der Fall ist. Aber auch bei Microservices können sich technische Schulden anhäufen, wenn diese nicht regelmäßig abgebaut werden.

Individuelle Skalierbarkeit

Die individuelle Skalierbarkeit und Verteilbarkeit von Microservices ist eine großer Pluspunkt. Microservices können effektiver auf erhöhte Lasten reagieren und sind global auf Cloudsysteme verteilbar. Wenn das System allerdings nur lokal arbeiten muss und oder keine Anwendungsfälle denkbar sind, bei denen Lastspitzen entstehen, sind diese Vorteile zu vernachlässigen.

Entkopplung auf Persistenzebene

Bei Microservices sind die Datenbanken der Microservices getrennt voneinander.

Technischer organisatorischer Overhead

Aufgrund der Anzahl von Services entsteht ein größerer Aufwand alle Systeme am Laufen zu halten. Hier gibt es Tools wie Docker und Kubernetes, die diese Aufgaben unterstützten.

Testing

Ein erheblicher Mehraufwand entsteht durch die Koordination von Tests, die verschiedene Microservices ansprechen.

Fallstudie FAE GPS Schuhsohle

1. Fragestellung aus der Veranstaltung zum Vortrag bezogen auf das Anwendungsbeispiel der GPS-Schuhsohle: Herr Nockemann hat ein Zielbild eines „gut strukturierten Monolithen“ beschrieben. Wenn wir Ihnen den MS-Architekturstil nicht vorgegeben hätten, was wäre dann Ihre Wahl für Ihre Subdomäne gewesen? Gut strukturierter Monolith oder Zusammenspiel mehrerer Microservices?

Wir sind der Meinung, dass sich Microservices für das Hochschulmodul besser eignen. Im Folgenden wird dies unter verschiedenen Gesichtspunkten näher beleuchtet.

Organisatorische Strukturen

Die kleinen Teamgrößen von agilen Techniken sind ideal für die Hochschulumgebung. Der Verwaltungsaufwand innerhalb der Teams steigt mit zunehmender Mitgliedszahl.

Technologieunabhängigkeit

Um die Ergebnisse verschiedener Teams vergleichbar zu halten, sollte die Technologie über alle Teams gleich bleiben. Außerdem ist es für die Betreuer einfacher bei Problemen Hilfe zu leisten. Die Technologieunabhängigkeit von Microservices hilft also in der Fallstudie wenig, dies ist aber lediglich dem Hochschulkontext geschuldet.

Technische Schulden

Es ist vermutlich einfacher für das nächste Bearbeitungsteam sich in ausgewählte Microservices einzuarbeiten als in einen gesamten Monolithen. Das sollte den Abbau von technischen Schulden und die Erweiterung des Systems vereinfachen. Analog gilt dies, wenn das System zu einem späteren Zeitpunkt als Open Source Projekt veröffentlicht wird.

Individuelle Skalierbartkeit

Es ist durchaus denkbar, dass die Verwaltungsservices dieser Subdomäne weniger Last erzeugen als die anderen Microservices.

Testing

Das End-to-End-Testing zwischen den Microservices stellt eine weitere künftige Aufgabe dar, die noch nicht tangiert wurde. Offene Fragen sind hier u.A. Test-Scope und Technologiewahl.

Strategische vs taktische Entscheidung für oder gegen MS

2. Fragestellung aus der Veranstaltung zum Vortrag: Ist dies (Monolith oder Microservices) eine Frage strategischer oder taktischer Architektur? D.h. ist eine übergreifende Entscheidung für die gesamte Applikationsdomäne (strategisch) nötig, oder kann jede Subdomäne ihre Entscheidung unabhängig für sich selbst treffen (taktisch)?

Für die gesamte Applikationsdomäne ist es eine strategische Entscheidung sich für oder gegen einen Monolithen zu entscheiden. Fällt hier die Entscheidung für Microservices, könnte man auf Subdomänenebene die Entscheidung treffen für Microservices im Sinne des DDD oder für ein Self-Contained System, das sich nach außen wie ein Microservice verhält.

Wir sind allerdings der Meinung, dass eine Festlegung auf eine Microservice Architektur auf strategischer Ebene getroffen werden sollte. Dies begründen wir darin, dass die Vorteile (Deploybarkeit, Wartbarkeit, Resilience, Time2Market, ...) einer Microservicearchitektur langfristig nur so garantiert werden können.

Im Fall der GPS-Schuhsohle wäre es möglich, dass das System größer wird, wenn es im Feld zur Anwendung kommt. Es kann nicht ausgeschlossen werden, dass eine Subdomäne wie beispielsweise das Ungewöhnliche Verhalten durch neue Funktionswünsche weiter wächst. Wurde die Entscheidung dieser Subdomäne auf einen Monolithen fallen, bestünde die Gefahr, dass der Monolith unstrukturiert wird. Außerdem wäre die Skalierbarkeit der Monolithen von Beginn an schwieriger, als die der Microservices.