Datacenter

Der kalkulierte Kontrollverlust

6. Februar 2017, 10:47 Uhr | Autor: Sascha Möllering, Redaktion: Markus Kien

Fortsetzung des Artikels von Teil 1

Vorteile von Microservices

Dieses Verfahren eignet sich für die Ablösung von Monolithen durch Microservices: Für den Monolithen muss eine Programmierschnittstelle – ein Application Programming Interface (API) – definiert werden. Die Kommunikation mit der Anwendung findet nur noch über die API statt. Einzelne Bestandteile beziehungsweise Domänen des Monolithen können identifiziert und als Microservice herausgelöst werden. Der Microservice implementiert den jeweiligen API-Teil und abhängige Komponenten kommunizieren nicht mehr mit dem Monolithen, sondern mit dem Service.

Ein wesentlicher Vorteil von Microservices besteht im besseren Time-to-Market. Teams können mit deutlich weniger Koordinierungsaufwand parallel an vielen Features arbeiten und diese Features unabhängig voneinander in Produktion bringen. Darüber hinaus können einzelnen Funktionalitäten viel granularer skaliert werden. Es ist nicht mehr notwendig, für die vollständige Anwendung Rechenkapazität und neue Server bereitzustellen, sondern nur für die Funktionalitäten, die intensiv genutzt werden. Dieser Ansatz ist somit auch deutlich kosteneffizienter.

Natürlich haben Microservices nicht nur Vorteile, der Overhead dieses Modularisierungsansatzes ist nicht unerheblich. Da Microservices untereinander über das Netzwerk kommunizieren, treffen auch für sie die sogenannten “Fallacies of Distributed Computing” zu: Verteilte Aufrufe können fehlschlagen, da beispielsweise ein Service oder das Netzwerk nicht verfügbar ist; der aufrufende Service muss mit diesen Problemen umgehen können. Darüber hinaus ist die Kommunikation von zwei Services über das Netzwerk erheblich langsamer als ein Aufruf im Kontext desselben Prozesses.

Bislang blieb eine Frage völlig unbeantwortet: Wie groß darf denn ein Microservice werden? Es gibt durchaus einige Autoren, die eine feste Zeilenanzahl des Quellcodes als Metrik nutzen. Dieser Ansatz lässt jedoch völlig die jeweiligen fachlichen Problemdomänen und die Teamdynamiken außer Acht. Einflussfaktoren auf die Größe eines Microservices sind beispielsweise die Teamgröße, die Ersetzbarkeit, der Overhead durch die verteilte Kommunikation und die Konsistenz der Daten und Transaktionen. Ein Microservice muss eine Problemdomäne umfassen, damit die Daten, die innerhalb der Domäne mit Hilfe von Transaktionen verwaltet werden, auf jeden Fall konsistent bleiben.

Eine wesentliche Frage bei der Entwicklung von Microservices ist von organisatorischer Natur: Wie sollten meine Teams aufgebaut sein, damit die notwendigen agilen Prozesse umgesetzt werden können? Conway’s Law besagt: “Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden”. Daraus lässt sich folgern, dass ein auf Modularisierung basierender Ansatz sinnvoll ist, da zwar eine Abstimmung in den Teams stattfinden muss, das aber nicht zwangsläufig teamübergreifend gilt. Nur wenn eine Schnittstelle zwischen den Modulen existiert, müssen sich die Teams abstimmen.