Monolith versus Microservices

Kaum ein Software-Engineer, der dies nicht kennt: Die erste Version der monolithischen Software war noch relativ einfach und übersichtlich. Im Laufe der Zeit kamen immer mehr Funktionen und Module hinzu, und die gesamte Applikation wurde komplexer und komplexer. Irgendwann war der Monolith so groß, dass er von einem einzelnen Entwickler nicht mehr überblickt werden konnte. Änderungen an einer Stelle bewirkten Merkwürdiges an anderen Stellen, und das Finden von Fehlern wurde mit jeder Zeile Code schwieriger. An einen Umstieg der Entwicklungsplattform war auch nicht zu denken, da dies einer kompletten Neuentwicklung entsprochen hätte.

Beispiel einer Software mit monolithischer Architektur

Im Gegensatz zum monolithischen Ansatz steht die Architektur der Microservices. Bei diesem Konzept werden möglichst kleine Module definiert, die jeweils nur für eine bestimmte Aufgabe bestimmt sind. Jeder Microservice stellt eine externe Schnittstelle zur Verfügung, die Zugriff auf die Daten und Funktionen des Microservice bietet. Die Kommunikation mit externen Modulen erfolgt über einen Dispatcher-Service, der die Anfragen an den entsprechenden Microservice weiterleitet. Die Entwicklungsplattform kann für jeden Microservice individuell definiert werden.

Beispiel einer Applikation mit Microservices

Die Datenverwaltung im jeweiligen Architekturmodell unterscheidet sich grundsätzlich: Bei einem monolithischen Ansatz gibt es normalerweise eine gemeinsame Schnittstelle zum Datenpool. In diesem Datenpool werden alle Daten gehalten und jedes Teilmodul kann beliebig über die Schnittstelle darauf zugreifen. Bei einer Änderung der Datenstruktur muss jedes Teilmodul entsprechend angepasst werden. Wenn hierbei ein Modul nicht angepasst wird, kann es zu Fehlverhalten und Daten-Inkonsistenzen kommen. Die Datenstruktur ist allgemein gehalten. Dadurch kann es sein, dass die Daten nicht für alle Module passend abgelegt sind und die Datenbeschaffung schwierig und wenig performant wird. Abhilfe können Datenbank-Views oder doppelte Datenhaltung schaffen. Die Verwendung von Transaktionen ermöglicht eine saubere Konsistenz der verschiedenen Datenbereiche.
Bei den Microservices ist jeder Service für seine eigenen Daten zuständig. Wie er diese hält, ist ihm selbst überlassen. So kann jeder Service die für seine Daten passende Struktur verwenden. Eine Änderung der Struktur hat keinerlei Auswirkungen auf andere Services. Wenn zwei Services dieselben Daten benötigen, so gibt es zwei Möglichkeiten: Entweder gibt es einen weiteren Service, der die Daten einmalig hält und die beiden anderen Services bedient, oder beide Services halten dieselben Daten und müssen sich bei einer Änderung der Daten gegenseitig synchronisieren – da keine Transaktionen stattfinden, müssen die jeweiligen Datenbereiche aufwendig synchronisiert werden.

Die Abhängigkeit der Module ist bei den Microservices wesentlich geringer: Jedes Teilmodul ist nur abhängig von den anderen Modulen, mit denen es kommuniziert – ein Ausfall eines Teilmoduls führt daher nicht automatisch zu einem Komplettausfall eines Systems. Bei der monolithischen Architektur ist der Ausfall eines Teilmoduls dagegen oftmals gleichzusetzen mit einem Komplettausfall des Systems. Zudem birgt schon das Bauen einer monolithischen Applikation das Problem, dass ein Fehler die gesamte Entwicklung ausbremsen kann.

Ein weiterer großer Vorteil von Microservices ist die Komplexität der Teilmodule: Ein Microservice führt typischerweise bestimmte Aktionen anhand eines Events aus. Diese Events können Abfragen von Daten des Service, Änderungen der Daten des Service oder der Aufruf einer speziellen Funktion sein. Diese Aktionen wiederum können zumeist so kompakt designt werden, dass sie sehr überschaubar bleiben, was die Fehlersuche oder die Übernahme des Projekts durch einen neuen Mitarbeiter enorm erleichtert.

Bei der Installation hat der Monolith Vorteile, da im Prinzip nur eine Applikation installiert wird. Bei den Microservices sind es mehrere Services, welche möglicherweise auch noch verteilt installiert werden müssen. Bei einem Update hingegen wird beim Monolithen alles überinstalliert, während bei den Microservices nur die geänderten Module installiert werden müssen, was die Installationsdauer enorm verkürzt und zudem die Möglichkeit bietet, bei einem Service auf eine vorhergehende Version zurückzuspringen.

Bei der Testbarkeit ist die monolithische Applikation einfacher, da nur ein Testplan für die gesamte Applikation benötigt wird. Dieser muss jedoch alle Funktionen der Applikation abdecken. Bei den Microservices wird für jeden Service ein Testplan benötigt. Dieser enthält dann nur die Funktionen des jeweiligen Service. Beim Nachtesten hingegen müssen beim Monolithen alle Funktionen getestet werden, während bei Microservices nur die Testpläne der geänderten Services durchgeführt werden brauchen.

Ein wesentlicher Unterschied der beiden Architekturmodelle ist die Wartbarkeit der Applikation: Während sich eine Fehlersuche beim Monolithen äußerst komplex gestalten kann, ist die Analyse der Microservices sehr viel einfacher, da die einzelnen Teilmodule unabhängiger und weniger komplex aufgebaut sind, wodurch sich der Fehler leichter isolieren und reproduzieren lässt.

Auch beim Trendthema Continuous Deployment haben Microservices die Nase vorn: Bei einer großen monolithischen Applikation ist Continuous Deployment schlicht nicht umsetzbar, da das Testen der kompletten Applikation im Verhältnis zur Entwicklungszeit zu lange dauert. Wenn bei einem Microservice Änderungen gemacht wurden, genügt einfach das Nachtesten des Microservice, und er kann unabhängig von Änderungen an anderen Modulen freigegeben werden.

Fazit: Der Aufbau von Microservices folgt sehr strikt der Vorgehensweise von abstrakten Problemlösungsprozessen, bei denen komplexe Aufgabenstellungen in einfachere und abgeschlossene Teile unterteil werden. Das große Ganze entsteht dann durch Verknüpfen der einzelnen Teil-Lösungen. Diese Herangehensweise erleichtert die Arbeit der Software-Entwickler enorm, da sie jeweils nur an bestimmten Teilmodulen arbeiten, welche sie aufgrund von deren Unabhängigkeit zudem optimal gestalten können.

 

Autor: Michael Smit, dot4LABS

Kontakt: Michael.Smit@dot4.de

 

Schreibe einen Kommentar

Your email address will not be published. Required fields are marked *