Micro Services – die Insider-Perspektive. Teil 2:

„WAS MICRO SERVICES BRAUCHEN, UM ZU FUNKTIONIEREN?“

Willkommen bei Teil 2 unserer Blog-Reihe über Micro-Services – einen jungen Ansatz der IT-Architektur, der monolithische System-Dinosaurier durch hoch agile Bienenschwärme von kompakten, autonomen, kollaborierenden Services ersetzt, wobei die Kopplung zwischen den Services idealer Weise möglichst lose und die Kohäsion innerhalb des einzelnen Services möglichst stark sein soll.

Eine solche Architektur bietet den Ausweg aus der Unbeweglichkeit und Unsteuerbarkeit komplexer, organisch gewachsener Systeme. JIT hat viele einschlägige Projekte begleitet und empfiehlt Micro-Services gerne und aus Überzeugung – allerdings nur dann, wenn die technischen und organisatorischen Rahmenbedingungen tatsächlich gegeben sind.

Das Nachdenken über organisatorische Rahmenbedingungen beginnt mit „Conway´s Law“: Wenn eine Organisation ein System entwirft, erkannte Melvin Conway schon vor einem runden halben Jahrhundert, entsteht völlig zwangsläufig eine Abbildung ihrer eigenen Team- und Kommunikationsstrukturen.

Deshalb wird ein Unternehmen, das die Migration zu einer Micro Service-Architektur vorbereitet, eingehend über Businessprozess-Anatomie, Zuständigkeitsgrenzen und Aufgabenverteilungen nachdenken müssen.

Denn um eine möglichst lose Kopplung zwischen Micro Services bei möglichst starker Kohäsion innerhalb jedes Services erzielen, müssen die Services und die zugrundeliegenden Datenmodelle sorgsam entlang klarer Domänengrenzen und Zuständigkeiten modelliert werden, die sich dann in einer klaren, effizienten Micro Service-Architektur spiegelt.

Domain-driven Design (DDD) ist das Werkzeug der Wahl für solche Modellierungen, speziell wegen der dazu verwendeten „bounded contexts“: Sie teilen die Business-Domäne sauber in klar abgegrenzte Zonen auf, zum Beispiel in Billing, Payment, Shipping usw. Jeder so definierte „bounded context“ bietet eine explizite Schnittstelle, die von kollaborierenden Services anderer Zonen verwendet wird.

Zu den organisatorischen Voraussetzungen gesellen sich auch technische Vorbedingungen. Die eine ist ein hoher Automatisierungsgrad: Continous Integration/Delivery ist in einem Micro Service-System unabdingbar.

Ebenso wesentlich ist das Monitoring: Der Zustand der einzelnen Services und des Gesamtsystems muss kontinuierlich überwacht werden. Dies gestaltet sich etwas komplexer als bei traditionellen Applikationen, da mehrere Server, Logfiles und Metriken wie CPU-Auslastung oder Response-Zeiten an einer zentralen Stelle aggregiert werden müssen. Tools wie Graylog, Graphite und Nagios sind dazu hilfreich.

Sind alle diese Rahmenbedingungen geschaffen, bleibt nur noch eine Frage: Soll das System in Zukunft spielen wie die Philharmoniker? Oder soll es tanzen wie Nijinsky? Was das bedeutet, impliziert und erfordert, verraten wie Ihnen in Teil 3 unserer Blog-Serie.

Top