Monolith oder Microservice Architektur?

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.

Was ist DevOps?

DevOps ist ein Konzept, welches aus zwei Trends heraus entstanden ist: Zum einen gibt es den Trend namens Agile Systemadministration oder Agile Operations, welche das Ziel verfolgen, agile Konzepte auch den IT Betrieb zu bringen. Zum anderen steht dahinter die Idee, einen Nutzen daraus zu gewinnen, dass die Entwicklung und der Betrieb möglichst eng miteinander arbeiten, sei das entweder beim Erstellen oder beim betreiben einer Dienstleistung. Diese Zusammenarbeit soll über den gesamten Applikaitonslebenszyklus – oder moderner Servicelebenszyklus stattfinden, vom Design zur Entwicklung und Wartung einer Applikation.

Dev meint dabei nicht nur den bekannten Entwickler, sondern jede Person, die irgendwie an der Entwicklung einer Appliation beteiligt ist. Ops steht für alle möglichen Jobs im Betrieb: Systemadministrator, Datenbankadministratoren, Netzwerktechniker, Sicherheitsspezialisten etc.

Schlussendlich ist DevOps aber mehr als Entwicklung und Betrieb, mehr als die Tools und Prozesse, die dahinterstehen. Es steht für eine Philosophie, eine Einstellung, Dinge anders zu machen als in der Vergangenheit. Es ist das Schaffen einer Kultur, in der die Entwickler mit dem Betrieb zusammenarbeiten, immer mit dem Ziel, eine möglichst gute Software abzuliefern und am Laufen zu halten. Und alle Beteiligten arbeitet zusammen, um dieses Ziel zu erreichen.

Das Umdenken in der agilen Revolution

Bevor Agile unsere Welt kam schienen die Rollen klar verteilt: Die Devs waren die Macher, die Ersteller der Software, während die Ops die Personen waren, die sich um die Applikation in der Wartung gekümmert haben. Die Industrie hat aber festgestellt, dass diese zwei Rollen durchaus Synergieeffekte für sich nutzen können, wenn sie zusammenarbeiten.

Dieser Gedankenanstoss kam auch aus der agilen Ecke: Dort wird bis heute die Zusammenarbeit als eines der höchsten Werte gepriesen. Und das nicht nur zwischen diesen beiden, sondern zwischen allen Rollen. Gemeinsam soll in kurzen Iterationen das Produkt beziehungsweise das Inkrement stetig verbessert werden. Aus agiler Sicht macht es nur Sinn, wenn man die Interaktion eines Systems mit deren Umsystemen gemeinsam betrachtet und die Applikation als Ganzes betrachtet, statt nur den Code.

 Entwickler werden sich dabei vermehrt mit dem Thema der virtuellen Maschinen beschäftigen, während die Leute im Betrieb sich mit automatisierten Tests auseinandersetzen. Das ganze läuft dann bestenfalls unter einem Schirm von gemeinsamen Messzahlen (KPI = Key Performance Indicators).

Developer und Operations-Leute werden weiterhin bestehen

Genauso wie es unrealistisch isch, dass in einem Scrum Team jede Person ein Software Architekt ist, ist es nicht möglich, dass Leute im Betrieb plötzlich die gesamte Entwicklung übernehmen oder umgekehrt. Es ist aber sehr von Vorteil, wenn die Leute im Betrieb die Entwickler verstehen und auch die Entwickler ein gewisses Skill-Set haben, um betriebliche Herausforderungen zu meistern – Nicht zuletzt, wenn es einen Stellvertreter braucht, weil eine Person im Betrieb vier Wochen in die Ferien geht.

Microservices Einführung

Jeder moderne Software Architekt sollte wissen, um was es sich beim Thema Microservices handelt. Man findet im Internet alle möglichen technischen Erklärungen dafür, dabei ist es überhaupt nichts Übersinnliches.

Die simpelste Erklärung ist: Ein Microservice ist eine Einheit für sich, hat genau eine spezifische Aufgabe, und kann in nicht mehr als zwei Wochen gebaut werden.

Dies scheint wirklich zu einfach zu sein, nicht wahr?

Schauen wir uns drei wichtige Punkte dazu genauer an:

  1. Ein Microservice fokussiert sich auf genau eine Aufgabe, ähnlich der Kohäsion einer Methode oder einer Klasse. Wenn etwa Amazon als Microservice gebaut werden würde, dann gäbe es genau ein Modul für das Kaufen und Verkaufen eines Artikels, ein Modul für die Anzeige und das Hinzufügen der Benutzerkommentare etc. Im Gegenzug dazu sind die meisten Applikationen heutzutage grosse, schwere Kreuzer, die über Jahrzehnte gewachsen sind und innerlich sehr vernetzt sind.

  2. Microservices laufen für sich alleine, unabhängig von anderen Modulen. Wenn ein Microservice also abstürzt, wenn man andere Teile der Applikation ändert, ist es dieser nicht gut designt.

  3. Einer der wichtigsten Punkte ist allerdings: Ein Microservice ist in kurzer Zeit zu erstellen und in genauso kurzer Zeit nochmals zu erstellen. Wie oben geschrieben, spricht man von einer Zeitspanne von etwa zwei Wochen. Warum man einen Service nochmals schreiben sollte, fragen Sie? Nun, stellt man fest, dass der Microservice entweder das falsche macht oder ganz einfach nicht mehr aktuell ist, kann dieser in kurzer Zeit durch ein modernes Pendant ersetzt werden. Dies gilt natürlich auch für Performance: Läuft ein Microservice nicht schnell genug, kann dieser in kürzester Zeit durch eine neue Variante ersetzt werden.

Dazu kommt, dass jeder Microservice für sich ein API zur Verfügung stellt, welches unabhängig von der verwendeten Sprache oder Technologie ist. Dies bedeutet beispielsweise, dass man bei Amazon die ganze Applikation mit Java & Spring bauen könnte bis auf den wichtigsten Teil, das Anzeigen der Werbung. Weil dieser Teil für das Business unglaublich wichtig ist, wird dieser kurzerhand in C++ geschrieben, um sicherzustellen, dass dieser gut performt.

Dasselbe gilt natürlich auch für die dahinterliegende Datenbank. Für die Artikel könnte man eine MongoDB verwenden, während ein anderer Teil mit Oracle arbeitet.

Fokussierte Teams

Was nun bei Microservices dazukommt ist die kleiner granulierte Organisation. Statt ein grosses Team zu haben, welche die Herrschaft über alle Services hat, arbeiten viele kleine Teams an einer überschaubaren Anzahl von Microservices.

Fazit

Diese Einführung sollte reichen, um eine Idee zum Thema Microservices zu erhalten.