Microservices

Microservices werden derzeit als Status Quo bei der Entwicklung einer Web-Anwendung gehandelt. Leider ist der Begriff sehr allgemein gehalten, so dass man nicht von jetzt auf gleich die Intention dahinter erkennt.

In erster Linie beschreibt Microservices die Organisation einer Web-Anwendung (also die Architektur). Entgegen dem gewohnten Vorgehen eine Web-Anwendung als ein in Ebenen geteiltes Ganzes zu organisieren, werden bei Microservices Grenzen zwischen den Features gezogen und diese als eigenständige Anwendung inklusive eingebettetem Container betrieben und mit geeigneten Mitteln wie HTTP oder AMQP verbunden.

Durch die Teilung ergeben sich einige Vorteile: Zunächst konzentriert sich jeder Service auf einen konkreten Aspekt des Gesamten und kann somit fast unabhängig von einem eigenen Team entwickelt werden. Dies gilt auch für das Deployment der Anwendung. Dieses kann genauso wie die Entwicklung unabhängig voneinander erfolgen. Wichtig ist hier, dass Änderungen nicht zum Ausfall eines abhängigen Services führen. Dies betrifft vor allem die Kommunikation der Services untereinander, die stets mit dem Partner-Service abgestimmt sein muss.

Durch die Konzentration des Dienstes auf ein Feature kann die beste Technologie für dieses Feature ausgewählt werden, ohne das die Anzahl der Abhängigkeiten ins unendliche steigt. Beispielsweise kann für stark zusammengehörige Daten MongoDB anstatt eines RDBMS gewählt werden. Diese Freiheit beschränkt sich nicht nur auf den Datenspeicher , auch diverse andere Kompontenten wie Frameworks und gar die Programmiersprache können frei gewählt werden. Die Benutzeroberfläche ist hierfür das beste Beispiel. Hier eignet sich eine Mixtur aus JavaScript sicherlich besser als Java, welches z.B. für den User-Service verwendet wird.

Auch für den Betrieb ergeben sich Vorteile. So lassen sich einzelne Teile einer Anwendung, die eine größere Last haben als andere, einzeln skalieren und Ressourcen somit besser ausnutzen.

Durch die Vielzahl an Möglichkeiten ergibt sich innerhalb eines Anwendungsbundes eine komplexe Landschaft, die bei gegebener Größe nicht mehr überschaubar ist. Klar behalten die jeweiligen Teams den Überblick über ihren Service, der Gesamtüberblick wird aber deutlich komplexer als dies bei einer monolithischen Organisation sein würde. Da jeder Service nun eine eigene Anwendung für sich ist, muss diese entsprechend konfiguriert werden. Viele Tätigkeiten müssen mehrfach durchgeführt werden.
Für den Betrieb steigt mit der Anzahl der Services der Verwaltungsaufwand. Es wird aufgrund des verteilten Deployments schwieriger Fehler zu verfolgen.

Auch im Test erhöht sich der Aufwand, so muss nicht nur die Funktionalität eines einzelnen Features sichergestellt werden, sondern auch die Kommunikation mit den Partner-Services.

Eine Microservices-Architektur gibt Entwicklern und Betrieb viele Vorteile, vor allem durch die freie Wahl an Mitteln. Diese Vorteile stehen aber im Gegengewicht der steigenden Komplexität des Ganzen. Ob sich so eine Architektur lohnt ist vom Projekt abzuwägen und kann nicht ad hoc beantwortet werden.