In meiner Einführung in Microservices bin ich auf eben dieses Thema eingangen. Das Gegenteil von Microservices, quasi die „altertümliche“ Architektur, wird hingegen Monolith genannt.

Wenn man nun ein neues System designen möchte, nach welchen Kriterien entscheided man sich, ob man jetzt Microservices verwendet oder einen Monolith baut?

Die Eigenschaften von Microservices

Entscheidet man sich für eine Microservices Architektur teilt man eine Applikation in mehrere Komponenten, wobei jede Komponente individuell entwickelt und verpackt wird. Jede Komponente hat einen eigenen Prozess. Die einzelnen Services kommunizieren dabei etwa über eine REST Schnittstelle.

Die Eigenschaften einer Monolith Architektur

Bei einem traditionellen Monolith System gehören die Bausteine zu einer einzigen Applikation, die den Software Lifecycle durchlauft. Alle benötigten Komponenten sind darin enthalten und werden zusammen deployed. Die meisten Applikationen bestehen dabei mehr oder weniger aus einer Datenbank und einer serverseitigen Applikation. Die serverseitige Applikation hat dabei die meiste Logik, etwa das behandeln von HTTP Requests oder das Holen und Schreiben von Daten auf die Datenbank.

Die gesamte Businesslogik ist also an einem Ort. Natürlich besteht die Applikation aus verschiedenen Klassen und Interfaces etc., diese werden am Ende aber zu einem Paket verschnürt. In Java wird aus einer Webapplikation etwa ein WAR File erstellt, welches dann auf einem Tomcat Server deployed werden kann.

Die Nachteile eines Monoliths

Ist die gesamte Applikation eine einziges Stück, kann dieses natürlich über die Jahre ordentlich wachsen und unübersichtlich werden – oder sogar in einem degenerierten Design ausarten, welches nur noch schlecht zu korrigieren ist. Die Applikation mit ihren Anforderungen und Bugs muss immer von jemandem verwaltet werden, was sehr mühsam werden kann.

Was dazu kommt, ist das Ausliefern der Applikation. Da es eine einzige Applikation ist, muss bei jeder kleinen Änderung das gesamte Paket ausgeliefert werden. Dasselbe gilt für die Skalierung.

Gerade im Hinblick auf Microservices wird auch der Wechsel auf eine andere Technologie sehr mühsam bei einem Monolith. Hat der Monolith erst mal eine gewisse Grösse erreicht, wird kaum eine Firma mal fröhlich Geld in die Hand nehmen, um die ganze Applikation in einer anderen Technologie neu zu schreiben.

Monolith ist also schlecht, Microservices gut?

Genau! Microservices werden unabhängig voneinander entwicklet und ausgeliefert. Jeder Microservice wird individuell skaliert. Bei einer neuen Technologie kann ein Microservice einfach durch einen neuen ersetzt werden. So einfach kann das sein!

Wichtig: Jeder Microservice hat dabei seine eigene Datenbank! Das bedeutet gleichzeitig, dass jeder Microservice seinen eigenen Datenbanktyp einsetzen kann, sei das etwa eine relationale Datenbank oder NoSQL. Und jeder Microservice kann hinter einen eigenen Load Balancer gesetzt werden, um eine optimale Last zu gewährleisten.

Super! Ab jetzt nur noch Microservices!

Moment! Microservices haben ebenfalls ein paar Nachteile, welche ich hier auflisten möchte.

Ein Monolith hat den grossen Vorteil, dass die verschiedenen Komponenten ganz einfach miteinander kommunizieren können. Bei Java etwa ruft man einfach die Methoden der entsprechenden Klassen auf. Bei Microservices muss der Entwickler immer eine Schnittstelle gegen aussen für andere Microservices anbieten.

Ebenfalls ein wichtiger Punkt bei Microservices: Mehrere Microservices müssen sich gegenseitig finden beziehungsweise kennen – nicht ganz einfach, wenn die IP eines Microservice gegebenfalls ändern kann. Zu diesem Zweck braucht es einen sogenannten Service Discovery Mechanismus, damit die Microservices die Netzwerklokationen finden. Dies kann etwa eine speziell dafür eingesetzte Service Registry Datenbank sein, welche die Adressen aller Microservices kennt. Ein Microservice registriert sich dort, wenn er gestartet wird. Diese Datenbank muss natürlich immer verfügbar sein und darf seine IP nicht dynamisch wechseln 😉

Fazit

Als Fazit kann man sagen: Hat man das Glück und kann eine neue Applikation erstellen, muss man sich fragen, ob diese sehr gross und komplex oder eher klein und simpel ausfallen wird. Gross und komplex wäre dann eher was für verschiedene Microservices, während klein und simpel für einen Monolith sprechen würde. Oftmals ist die Realität aber so, dass man schon mit einem über die Jahre gewachsenen Monolithen zu tun hat. Ich probiere, herauszufinden, ob man einen Monolithen stückweise in Microservices migrieren kann oder ob dafür ein Big Bang notwendig ist.