Einer der vielleicht umstrittensten Hypes der letzten Jahre ist die Microservice-Architektur. Sie besagt, dass eine Software nach Aufgaben und Entitäten in kleinste Elemente, sogenannte Microservies aufgeteilt werden soll. Doch was bringt das überhaupt? Wo liegen die Stärken dieser Architektur und gibt es auch Nachteile? Diese Fragen sollen nachfolgend genauer diskutiert werden.
Was sind Microservices?
Microservices sind Dienste, die eine einzige Aufgabe erfüllen auf die sie spezialisiert sind. D.h. sie erfüllen meist nur eine Funktion, aber dafür machen sie es richtig. Ebenso werden solche Microservices von nur einem Entwicklungsteam gebaut, getestet und in Produktion gebracht. Dies entspricht dem bekannten Continuous-Integration-Continuous-Delivery, kurz CICD-Ansatz.
Ein Beispiel für eine Aufgabe eines Microservices ist etwa die Erstellung eines PDF-Dokuments aus einer HTML-Datei. Dieser Dienst hat keinerlei Abhängigkeiten zu anderen Services und kann ganz einfach skaliert werden. Die Vorteile liegen auf der Hand: Man kann beliebig viele Instanzen laufen lassen, ohne dass bei der Koordinierung Probleme entstehen können.
Warum Microservices?
In der Literatur findet man zahlreiche Stärken und Vorteile einer Microservice-Architektur. Nachfolgend eine kurze Übersicht dazu:
- Einfaches Deployment
- Klar definierte Zuständigkeiten und Aufgaben
- "Bring your own DB", jeder Service kann den Datenbanktyp selber wählen
- Günstige und schnelle Bugfixes
- Gut skalierbar
Diese Liste ist nicht abschliessend, aber sie zeigt bereits einige deutliche Stärken von Microservices auf.
Ein aus meiner Sicht oft vergessener Vorteil sind die kostengünstigen Bugfixes. Dadurch, dass pro Microservice lediglich ein paar hundert Zeilen Code anfallen, sind Fehler schnell gefunden und behoben. In der Praxis bedeutet dies, dass innerhalb von wenigen Minuten ein Bug gefunden, ein Test geschrieben, der Fehler behoben und der Service neu ausgerollt werden kann. Dagegen könnte man nun argumentieren, dass zwecks guter Software-Architektur innerhalb eines Monolithen, solche Bugs ebenfalls schnell behoben werden können. Jedoch macht es für einen Software-Entwickler einen erheblichen Unterschied, ob man unzählige Codedateien und Zeilen durchgehen muss oder nur ein paar wenige.
Gibt es auch Nachteile?
Ja, auch Microservices sind nicht immer das Gelbe vom Ei. In der Praxis gestaltet es sich oft recht schwierig, geeignete Unterteilungen für die Microservices zu finden. Oft sieht man sich dabei mit der Frage konfrontiert, ob Informationen nun redundant über mehrere Microservices gespeichert oder doch lieber mittels einer zusätzlichen Abfrage abgerufen werden sollen. Solche Entscheidungen stehen am Ende immer in einem gewissen Zielkonflikt zwischen Komplexität und Skalierbarkeit, der nur mit Erfahrung und Evaluation gelöst werden kann.
Ein weiterer Punkt, den man bei der Entscheidung für oder gegen Microservices betrachten sollte, ist, dass der Aufwand für die Koordinierung von Schnittstellen oder das Entwickeln von am Anfang unvorhergesehener Features extreme Ausmasse annehmen kann. Insbesondere wenn die Unterteilung der Microservices zu fein granuliert wurde und für ein neues Feature eine Vielzahl von Microservices angepasst werden müssen, kann der Aufwand schnell mal ein paar zusätzliche Tage in Anspruch nehmen.
Zusammenfassend lässt sich sagen, dass das Konzept von Microservices grundsätzlich eine gute Idee ist. Wie bei jeder Idee, gibt es aber auch hier gewisse Nachteile, die nur mittels Erfahrung und akribischer Planung vermieden werden können. Es ist unabdingbar, dass zu Beginn eines Projekts mit Microservice-Architektur alle Aufgaben bekannt und klar definiert sind. Ansonsten sind Probleme bei der Weiterentwicklung vorprogrammiert.
