Softwarearchitektur: Micro Service oder Monolith

Micro Service oder Monolith: Welches ist die besser Software Architektur?

Klarte Antwort, it depends.

Mirco Services sind seit ca. zehn Jahren die vorherrschende Software-Architektur, wenn es um Server-Anwendungen geht. Die meisten stellen sich nur die Frage, wie gross darf oder kann ein Micro Service sein. Aber gibt es Alternativen zu Micro Services? Ja und zwar mindesten zwei:

1. Serverless
2. Monolith

Zum ersten Punkt der Serverless Architektur kommen wir später. Punkt 2 der Monolith gilt als überholt und wird mit der Softwarekrise in den 90er Jahren in Verbindung gebracht, nicht ganz zu unrecht, waren damals doch fast alle Softwareprodukte Monolithen.

Seit den 90er hat sich allerdings einiges getan, wie Software entwickelt wurde. Agile Softwareentwicklung hat mehr oder weniger zu den Micro Services geführt. Ein grosser Vorteil der Micro Services war und ist, das man durchaus in der Lage ist die Softwareentwicklung horizontal, also mit der Anzahl der Entwicklerteams, zu skalieren. Aber offen gesagt, ist dies auch mit Monolithen möglich. Mit der aktuellen Technik, ein paar alten bewährten Software Regeln ist auch möglich Monolithen mit multiplen Teams parallel mit der selben Geschwindigkeit zu entwickeln wie Micro Services. Dazu benötigt man nur zwei Regeln:

1. Share Nothing
2. Dinge, die zusammengehören sind im selben Package

Eine Anmerkung zu Punkt 2, das bedeutet nicht das ein Package mit Controller und eins mit Services und so weiter hat. Diese Packetierung ist falsch, das ist so als würde man die Pflanzen nach ihr Blütenfarbe klassifizieren. In einem Packet befindet sich Controller, Service, Model, Repository die zusammen einen Anwendungsfall implementieren. Pakete selbst sind unabhängig von einander und benutzen keine Klassen aus anderen Paketen. Und fertig ist der skalierbar programmierte Monolith.

PS: Fehlende Buchstaben im Text sind verursacht durch Apples grandiosen Versuchen Tastaturen für MacBooks neu zu erfinden.

PS 2: Die Paketierugsstrategie vieler Domain Driven Ansätze ist komplett falsch.

Vertikalisierung der Softwareentwicklung und Micro Services

Die Vertikalisierung der Softwareentwicklung ist ein erfolgreiche Modell für die Skalierung der Softwareentwicklung. Dabei betreut ein Entwicklerteam eine Kunden-Domäne und entwickelt die Software für diese Domäne autonom. Dies wird gerne durch das Share Nothing Prinzip umgesetzt. Das Entwicklerteam kann ohne Rücksicht auf andere Teams, also ohne Abstimmungsaufwand und Meeting-Marathons die Software für die Kunden-Domäne entwickeln. Dies spart Zeit und bring schnell gute Erfolge, es ist sehr effizient.

Vertikalisierung führt oft dazu, das das Team die Kunden-Domäne als einen Micro Service umsetzt. In der Praxis stösst dieses Vorgehen: eine Domäne, ein Team, ein Micro Service, recht schnell an seine Grenzen. Der Grund ist die Komplexität dieses fetten Micro Services, der verscheiden Aufgaben erfüllt. Oft kommt es zu komplexen Deployments, weil der fette Micro Service in verscheiden Funktionen deployed wird, z.B. zur Datenversorgung und Kunden-App. Aus meiner Erfahrung ist das Deployment und der Betrieb sehr komplex und führt zu zusätzlichen Fehlern. Ein Codebasis führt zu funktional unterschiedlichen Micro Services, die durch Konfiguration unterschieden werden. Diese funktional unterschiedlichen Micro Services sind nicht unabhängig von einander. Es kann zu fehlerhaften Konstellationen kommen, oft hilft nur eine gezieltes Überwachen des Betriebes diese Klasse von neuen Fehlern zu erkennen. D.h. wir haben eine neue Klasse von Runtime Fehlern, die schwerer zu erkennen sind und dazu noch sehr spä erkannt werden. Diese Fehler sind erst nach dem Deployment erkennbar. Dann ist der Service für den Kunden aber schon gestört. Oder aus einer anderen Perspektive, wenn wir die 12 Factors App Kriterien heranziehen, wäre dies ein Bruch mit dem Faktor 1!

Eine erfolgreiche Alternative ist es aus diesen fetten Micro Service in einzelne kleine, in sich geschlossene, Micro Services zu zerlegen. Zum Beispiel kann man die Datenversorgung von der Bearbeitung von Kundenrequest trennen. Oft wird als Gegenargument angeführt, das es gemeinsamen Code gäbe. In der Praxis hat sich gezeigt, das die Menge des gemeinsamen Codes sehr gering ist. Das Problem des gemeinsame Codes kann bei Bedarf über Bibliothek gelöst werden.

Zusammengefasst die Vorteile der Zerlegung von fetten Micro Services einer Vertikalen in schlanke Micros Services:

• Vereinfachung des Deployments
• Vereinfachte Konfigurationen
• Keine Fehler durch Fehlkonfigurationen, die Instanzen der Applikation sind unabhängig voneinander
• Höhere Robustheit, Fehler in einem Micro Service stört nicht die gesamte Applikation, so führt der Ausfall der Datenversorgung nicht dazu das der Kunde nicht mehr bedient wird
• Ein negativen Performance-Einflüsse durch Daten-Imports oder Wartungsjobs.
• Bessere Wartbarkeit, Codebasis beleibt schlank und übersichtlich