Vorteile von Microservices

Betrachtet man hierbei die gängigen Beschreibungen dessen, was als Microservice wahrgenommen wird, so erklärt sich die Begeisterung noch auf weitere Weisen. Als Microservices werden umgangssprachlich gern kleine Dienste verstanden, die zumindest zur Laufzeit voneinander entkoppelt sind und über ein bestimmtes Kommunikationsmedium miteinander interagieren. Dieses Medium ist meist ein Netzwerk und wird über einen Service Bus oder über entsprechende Endpunkte zum Beispiel mit REST oder RPC umgesetzt. Dies verhindert, dass die Dienste über etwas anderes als ihre öffentlichen Schnittstellen angesprochen werden. Da sie physisch voneinander getrennt sind und in eigenen Prozessen, gegebenenfalls sogar auf völlig unterschiedlicher Hardware laufen, können sie zeitgleich auch leichter skaliert werden.

Durch die Nutzung standardisierter Austauschformate kann darüber hinaus jedes Team seine Dienste technisch so umsetzen, wie es sie selbst umsetzen möchte. Dadurch können sich die Entwickler auf die Technologien konzentrieren, mit denen sie sich auskennen. Sollte ein Dienst ausserdem einmal zu komplex oder zu schlecht wartbar sein, kann er aufgrund seiner geringen Grösse vergleichsweise leicht ausgetauscht werden. Aus den gleichen Gründen sind die Dienste auch automatisch viel leichter verständlich und besser testbar als der Code innerhalb eines gewachsenen Monolithen. Dass sie aufgrund ihrer Natur auch ausfallsicherer sind, ist selbstverständlich.

Neben der rein technischen Skalierung erlauben Micro­services aber auch eine organisatorische Skalierung. Neue Teams können sehr viel schneller produktiv arbeiten, als dies bei einem Monolithen der Fall ist. Diese neuen Teams erstellen eigene Dienste auf der grünen Wiese und müssen sich daher nicht so sehr um das kümmern, was bereits vorhanden ist. Insofern sie die Schnittstellen der anderen Dienste verstehen, können sie diese über Standardvorgehensweisen nutzen und brauchen sich nicht mit dem lästigen Klein-Klein von deren Implementierung herumschlagen. Gerade Firmen wie Uber und Netflix konnten dank dieser Skalierbarkeit eine immense Entwicklungsgeschwindigkeit erreichen und binnen kurzer Zeit auf Marktveränderungen reagieren.

Das klingt fast zu gut, um wahr zu sein, und tatsächlich ist es das auch. Denn die zuvor genannte landläufige Beschreibung spart sehr viele der eigentlichen Kernkonzepte von Microservices aus und verschweigt die wichtigsten Problemfelder. Der Hauptfehler, der hierbei gern gemacht wird, ist, dass die Argumentation sehr stark von der technischen Seite getrieben wird. Das Kernkonzept von Microservices ist aber, dass sie gerade eben nicht technisch getrieben sein sollten, sondern fachlich.

Laut dem Autor Sam Newman sind Microservices Dienste, die ­unabhängig voneinander deployt werden können, um eine bestimmte Business-Domäne modelliert werden und über Netzwerke miteinander kommunizieren. Sie sind somit eine besondere Form der serviceorientierten Architektur, bei der speziell Rücksicht darauf genommen wird, wie die Grenzen der Dienste geschnitten werden. Genau dieser Schnitt der Dienste ist es indes, der in der Praxis zu einigen Schwierigkeiten führt.

Bild 1 zeigt beispielsweise eine Aufteilung rein auf Basis der technischen Schichten. Eine fachliche Trennung ist daher in Bild 1 nicht zu erkennen. Bild 2 wiederum nimmt eine Auftrennung mit dem Ziel einer Skalierung vor. Wobei Auftrennung hier nicht das richtige Wort ist: Tatsächlich werden nur mehrere Instanzen der gleichen Software bereitgestellt. Das gleiche Vorgehen wurde eigentlich auch bei Bild 3 verfolgt. Hier gibt es keine Unterscheidung, warum die Logik und die Datenhaltung konkret in eigenen Diensten vorliegen. Vielmehr wird alles in einem grossen Frontend-Monolithen wieder zusammengeführt.

Ein solcher Fall liegt beispielsweise vor, wenn man einen typischen Desktop-Client betrachtet, der verschiedene Back­end-Services anspricht, wie es bei einer serviceorientierten Architektur der Fall ist. Bild 3 zeigt demnach keine Microservice-Architektur, sondern eine serviceorientierte Architektur. Microservices werden die Dienste erst durch ihre fachliche Auftrennung und Entkopplung voneinander, wie sie beispielsweise in Bild 4 zu sehen ist. Hier wurde absichtlich auf die Darstellung der Präsentationsschicht verzichtet, um die Komplexität der Abbildung zu verringern.

Die Auftrennung der Dienste erfolgte im Beispiel anhand der Fachabteilungen, für die sie entwickelt wurden, das heisst die Verkaufsabteilung, die Personalabteilung und die Einkaufsabteilung. Je nachdem, wie umfangreich die abzubildenden Prozesse sind, könnten solche Dienste aber noch weiter zerlegt werden. So wäre beispielsweise ein Dienst für die Rechnungslegung vorstellbar, oder ein Dienst für das Beantragen von Urlaub.