© Palto/Shutterstock.com
Von Monolithen zu Microservices

DDD als Schlüssel zum Erfolg


In vielen Unternehmen sind sie noch zu finden: monolithische Legacy-Systeme, die über Jahrzehnte gewachsen sind. Nach und nach stellen IT-Abteilungen die Altsysteme auf Microservices um. Dabei eignet sich nicht jedes System zur Migration, und auch bei der Integration bestehender Datenbanken gilt es einiges zu beachten.

Der Umstieg auf Microservices bringt viele Vorteile mit sich. Eines der Grundprinzipien in der Softwareentwicklung ist die Modularisierung. Bereits 1972 stellte David Parnas das Prinzip des „Information Hiding“ vor [1]. Die Grundidee hinter Modularisierung ist, ein Softwaresystem in Module mit begrenzter Komplexität und klaren Schnittstellen zu zerlegen. Die interne Businesslogik der Module bleibt dem Nutzer dabei verborgen. Dieses Prinzip der Modularisierung treiben Microservices auf die Spitze, indem sie jedes Element des Funktionsumfangs in einem eigenen Service auslagern (Abb. 1).

bindick_microservices_1.tif_fmt1.jpgAbb. 1: Die Grundidee von Microservices

Microservices-Architekturen zeichnen sich durch fünf Kerneigenschaften aus:

Bounded Context: Der Funktionsumfang einer Anwendung wird in fachlich abgrenzbare Kontexte (Bounded Context) geschnitten. Gemäß dem Prinzip „Do one thing and do it well“ hat jeder Kontext genau eine funktionale Aufgabe. Aus technischer Sicht wird je Kontext ein Service implementiert, der sowohl für die Datenhaltung als auch für die Businesslogik und das User Interface verantwortlich ist. Ein Entwicklungsteam, bestehend aus maximal zehn Personen, setzt jeweils einen Service um.

Lose Kopplung: Die Kopplung von Microservices erfolgt lose und anders als bei konventionellen Modularisierungstechniken, bei denen Funktionen in Bibliotheken und Klassen, die im selben Prozess laufen, ausgelagert werden. Microservices hingegen werden separat in eigenen Prozessen ausgeführt und über das Netzwerk, zum Beispiel auf Basis von RESTful HTTP, miteinander gekoppelt.

Unabhängige Deploybarkeit: Entwicklungsteams können Services weitestgehend unabhängig voneinander in die Produktion überführen. Voraussetzung dafür ist ein guter fachlicher Schnitt der Anwendung. Außerdem unterstützen leichtgewichtige Virtualisierungstechniken wie Docker die einfache Bereitstellung der Services. Jedes Team arbeitet innerhalb einer eigenen Deployment-Pipeline (Continuous Integration/Continuous Development) und hat somit den Build-Prozess und die Absicherung des Service in der eigenen Hand. Lediglich einige wenige Integrationstests müssen übergreifend durchgeführt werden.

Unabhängige Technologiestacks: Da die Integration der Services in ein Gesamtsystem lose gekoppelt über das Netzwerk erfolgt, ist ein gemeinsamer Technologiestack nicht erforderlich. Jeder Service lässt sich mit einer eigenen Technologie wie etwa Programmiersprache, Frameworks, Datenbank, Betriebssystem oder Laufzeitumgebung umsetzen. Die Technologieentscheidung liegt beim jeweiligen Entwicklungsteam. Somit wird ein optimal auf den jeweiligen Funktionsumfang zugeschnittener Stack erreicht (Stichwort: „best fit“).

Dezentrales Datenmanagement: Jeder Service verwaltet seine für den Funktionsumfang notwendigen Daten selbst. Das führt zu einer Verteilung und Dezentralisierung der Daten über das Gesamtsystem. Vor diesem Hintergrund müssen die Entwickler Strategien bezüglich Datenkonsistenz, Dauerhaftigkeit und Datenreplikation ausarbeiten.

Wann ein bestehendes IT-System in Microservices überführen?

Der immer noch anhaltende Microservices-Hype und die vielen offensichtlichen Vorteile lassen vermuten, dass jedes IT-System von Microservices profitiert. Sie bringen aber auch Nachteile mit sich. Der größte Nachteil ist, dass durch die Verwendung von Microservices ein verteiltes System mit hoher Komplexität entsteht. Serviceaufrufe zwischen Microservices sind fehleranfällig und sollten entsprechend robust entwickelt sein. Außerdem entstehen mehr Artefakte, die es zu installieren und betreiben gilt. Unabhängig von der Technik gibt es auch Herausforderungen auf organisatorischer Ebene. Entscheidungskompetenzen und Verantwortung sind auf die Teams verteilt. Es ist somit nicht sinnvoll, jede bestehende monolithische Applikation in Microservices zu überführen.

Microservices spielen vor allem dort ihre Vorteile aus, wo neue oder geänderte Features schnell ausgeliefert werden müssen. Sie passen daher optimal zu agilen Vorgehensmodellen. Das Gesamtsystem lässt sich mithilfe von Microservices viel besser hinsichtlich verwendeter Technologien, Datenhaltung und Skalierbarkeit optimieren. Zusätzlich entsteht eine nachhaltige Softwarearchitektur, die langfristig besser wartbar ist, da einzelne Microservices leicht angepasst und ersetzt werden können.

Schrittweise Portierung

Wenn genau diese Punkte bei einem bestehenden monolithischen System Probleme bereiten, lohnt es sich, über die Migration auf eine Microservices-basierte Architektur nachzudenken. Ein kompletter Umbau eines Monolithen in einem Schritt innerhalb kurzer Zeit („Big Bang“) wird nur bei sehr kleinen Anwendungen funktionieren. Bei größeren Anwendungen kommt in der Regel nur eine schrittweise Portierung auf Microservices in Frage, um einerseits schnell Erfolge zu erzielen und andererseits das Risiko für das Scheitern des Umbaus zu minimieren. Im ersten Schritt können einzelne Funktionen in einen Microservice ausgelagert werden. Stufenweise können die Entwickler den Umfang an Microservices dann erhöhen (Abb. 2). Bereits bei der Migration eines einzelnen Service kommen erste Vorteile direkt zum Tragen, wie zum Beispiel ein schnelles Deployment unabhängig vom Rest der Anwendung sowie eine flexible und autonome Entwicklung des Service.

Die folgenden Best Practices beschreiben, wie die Herangehensweise an einen schrittweisen ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang