neu

Vom Monolithen zum Microservice: Großer Wandel in kleinen Schritten

Wie man einen IT-Monolithen zu Microservices umbaut? Wir verraten es Ihnen – hier.

In einem unserer letzten Beiträge hat unser Autor die Vor- und Nachteile von Microservices skizziert und erklärt, welchen Einfluss die Systeme auf Entwicklung und Betrieb haben. Im folgenden Artikel erläutert er nun, wie man Monolithen erfolgreich zur Microservice-Landschaft umbaut.

Nahezu jedes Unternehmen hat ihn: den einen riesigen IT-Dienst, der speziell für die eigenen Belange entwickelt wurde. Mit den Jahren hat er sich in die IT-Landschaft hineingefressen, ist um zahlreiche Features angewachsen – und ist nun so omnipräsent, dass jeder kleinste Fehler ganze Unternehmensprozesse ins Wanken bringen kann.

Gratulation, Sie haben einen Monolithen.

Sie wollen aber viel lieber eine kleinteiligere, flexiblere und voneinander unabhängige Landschaft aus Services? Dann müssen Sie den Monolithen zerteilen und zu Microservices migrieren – davon jeder mit eigener Geschäftslogik, Datenhaltung und möglicherweise einer eigenen Benutzeroberfläche.

Eine gute Entscheidung – doch wie macht man das? Wir zeigen Ihnen im Folgenden, wie sie eine solche Migration anpacken und auf welche Fallstricke Sie achten müssen.

Eine harte Wahrheit jedoch vorab: Der Umbau vom Monolithen zu Microservices ist selten ein Big Bang. Die Migration ist stellenweise schmerzhaft lang- und mühsam. Microservices sind kein Schalter, den man umlegt – sie sind eine lange Reise, die man antritt. Doch bevor wir hier zu sehr ins Esoterische abdriften – kommen wir zu den wesentlichen drei Fragen!

Erstens: Wo fängt man an, einen Monolithen aufzubrechen?

Stoppen Sie jeglichen weiteren Ausbau Ihres Monolithen – und setzen Sie neue Funktionen und Entwicklungen direkt als Microservice um. Auf diese Weise beginnen Sie den ersten Schritt in Richtung Microservices, ohne den Betrieb ihrer Legacy-Systeme zu gefährden.

Identifizieren und extrahieren Sie die Funktionen mit den wenigsten Abhängigkeiten. Starten Sie mit Features ihres Monolithen, die am wenigsten neuralgische Verbindungen aufweisen. Lassen Sie sich dabei nicht von der bisweilen enormen Komplexität entmutigen. Innerhalb von Monolithen sind die Abhängigkeiten meist extrem vielschichtig. Daher beginnen Sie am besten immer mit den „äußeren“ Knoten des Systems.

Schalten Sie Teile des Monolithen strategisch ab, sobald neue Projekte und Prioritäten im Unternehmen Anlass dazu geben. Orientieren Sie sich also bei der Migration entlang der strategischen Bedürfnisse Ihres Unternehmens.


Zweitens: Gibt es typische Etappen, die man bei der Migration von Monolithen zu Microservices beachten sollte?

Nein, dafür gibt es tatsächlich keine Blaupause. Der Wandel hin zum „System of Systems“ sollte Stück für Stück in kleinen Etappen geschehen. So minimiert man Risiken bei der Migration. Auch für das Design der jeweiligen Microservices existiert keine Vorlage: Die Wirklichkeit sieht meist so aus, dass in einem System of Systems sowohl Individual-Software als auch Standard-Produkte koexistieren.

Zudem brauchen Sie realistische Erwartungen: Nicht jeder Monolith lässt sich komplett im Microservices zerlegen.

Drittens: Worauf sollte ich anschließend beim Betrieb von Microservices achten?

Wichtig ist vor allem die Bereitschaft von Entwicklern und Administratoren, sich auf ein Umdenken in allen Belangen der IT-Infrastruktur einzulassen. Denn mit der IT-Infrastruktur verändern wir auch ganz grundlegend die Arbeitsweise der gesamten IT-Abteilung. Entwicklerteams werden eigenständiger und eigenverantwortlicher, auch im Betrieb erhöht sich die Komplexität.

Zudem braucht es auf technischer Seite eine Basis, die den Anforderungen von Microservices gerecht wird. Auf drei Dinge sollten Sie dabei besonders achtgeben:

Eine durchdachte API

Schnittstellen bilden zusammen mit den Datenflüssen die Lebensadern einer Microservice-Landschaft. Denken Sie deswegen beim Design ausreichend über die aktuellen und zukünftigen Informationsflüsse nach. Welche Daten muss sie langfristig zur Verfügung stellen? Machen Sie Ihre Architektur zukunftssicher!

Traffic Management

Durch den erhöhten Kommunikations-Aufwand zwischen den Services sollten Sie nun auch ein Augenmerk auf die Datenflüsse zwischen den Systemen legen. Mittels vernünftigem Traffic Management können sich die APIs untereinander deutlich machen, falls diese ihr Gegenüber überfordern – und so Problemen vorbeugen, bevor diese ernsthaft entstehen.

Ausreichendes Monitoring

Und noch etwas verraten die Datenflüsse: nämlich den Gesundheitszustand der Ihrer Microservice-Landschaft. Ein Monolith mag kompliziert in der Wartung sein – eine Microservice-Architektur ist durch ihre vielschichtige Technik komplexer in der Überwachung. Sorgen Sie deswegen von Anfang an für ausreichende Kontaktpunkte für ein zentrales Monitoring aller Systeme.



Planen Sie, ihre Legacy-Monolithen durch Microservice-Landschaften zu ersetzen? Oder stecken Sie bereits mitten in der Migration und stoßen an Grenzen? Melden Sie sich bei uns – unsere Experten unterstützen Sie gerne.