,

Vom Monolithen zu Microservices – Refactoring in drei Schritten

Vom Monolithen zu Microservices – Refactoring in drei Schritten
Bei der Einführung von Microservices entstehen für Architektur, Entwicklung und Auslieferung große Vorteile. Den Herausforderungen beim Umbau einer monolithischen Architektur begegnet man am besten mit einer systematischen Refactoring-Strategie.

In den letzten Jahren gab es eine Menge Verbesserungen im Bereich der Software-Architektur: Entwickler konzentrierten sich verstärkt auf lose gekoppelte Anwendungen und erzeugten damit eine modulare Architektur. Trotzdem sind die Anwendungen noch miteinander verzahnt und werden als Monolith oder in einem Paket bereitgestellt.

In diesem Beitrag zeigen wir die Vorteile des Umstiegs von einer monolithischen Architektur zu Microservices am Beispiel eines ERP-Systems, das aus einem Bestell-, einem Kunden- und einem Produktmodul besteht.

Monolith, Microservice
ERP-System mit monolithischer dreischichtiger Architektur

Abbildung 1 zeigt eine traditionelle monolithische N-Layer-Applikation, bestehend aus der Anwendungsschicht, einem Business Logic Layer und einer Datenbankschicht. Dieser Architekturansatz wird sehr häufig verwendet, ist einfach zu entwickeln und zu implementieren.

Ein Problem entsteht dann, wenn die Anwendung größer ist. Die damit verbundene Komplexität macht es für den Entwickler schwer, den Überblick zu behalten und erhöht den Zeitaufwand, der bei der Entwicklung von Bugfixes oder neuen Features nötig ist. Ein besonderes Hindernis für die Auslieferung stellen in diesem Zusammenhang Software-as-a-Service-Anwendungen dar. Hier werden täglich Teile der Produktionsumgebung aktualisiert. Die Entwickler müssen für Updates einzelner Funktionen jeweils die komplette Applikation zur Verfügung stellen.

Umstellung auf Microservices

Viele Unternehmen wie Amazon oder Netflix haben diese Probleme durch den Einsatz von Microservice-Architekturmuster gelöst. Microservices separieren jedes Modul in einen eigenen kleinen Dienst. Jeder Service hat eine spezifische Aufgabe und arbeitet unabhängig – ist aber mit anderen Services verbunden. Die Kommunikation zwischen den Diensten erfolgt via HTTP Request oder Message Queue. Ein häufiger Fehler in der Software-Entwicklung – unabhängig vom Architekturmodell – besteht darin, dass jede Regel von Grund auf neu definiert wird. Dieser Ansatz ist zeitaufwändig, riskant und endet meist in einem Desaster, da Fristen und Budgets nicht eingehalten werden können. Eine strategische Umstellung von einer monolithischen Anwendung hin zu Microservices kann dank einer systematischen Refactoring-Strategie in den drei folgenden Schritten gelingen.

1. Neue Features - neue Microservices

Im ersten Schritt werden einfach keine neuen Features mehr innerhalb des Monolithen entwickelt. Stattdessen setzen die Architekten jede neue Anforderung in einen eigenständigen Microservice um. Dieser Dienst wird unabhängig von der Hauptanwendung entwickelt, bereitgestellt und skaliert.

Monolith, Microservice
Entwicklung neuer Features als eigenständige Anwendungen

2. Splitten der Layer

Im nächsten Schritt werden die Anwendungsschicht und der Business Logic Layer der monolithischen Anwendung separiert. Es entsteht dabei in der Regel eine saubere Trennung zwischen beiden Schichten. Nach dem Split können beide Applikationen dann selbstständig entwickelt, getestet, eingesetzt und skaliert werden. Wo bisher ein großes Team für die gesamte Applikation verantwortlich ist, kann nach diesem Schritt das Team in zwei oder mehr eigene Teams aufgeteilt werden, die unterschiedliche Dienste und Aufgaben behandeln. Damit sinken die Komplexität in der Entwicklung und der Aufwand bei der Kommunikation, was die Produktivität der gesamten Mannschaft verbessert.

Monolith, Microservice
Trennung der monolithischen Architektur in zwei separate Applikationen und Deployment-Einheiten

3. Überführen weiterer Module in Microservices

Um die restlichen Komponenten des Monolithen umzubauen, müssen die Entwickler bestehende Module in eigenständige Microservices extrahieren. Das Herauslösen der bestehenden Module kann sich je nach Komplexität der Anwendung als schwierig gestalten. Entwickler sollten mit dem Modul starten, das entweder am einfachsten zu extrahieren ist oder bei dessen Auslösen der größte Mehrwert entsteht. Wenn beim Auslösen des Moduls schnelle Iterationen möglich sind, werden beim Deployment Zeit und Kosten gespart. Entwickler können sogar die Möglichkeit in Betracht ziehen, das Modul als einen Standalone-Microservice zu entwickeln, wenn sie feststellen, dass das Extrahieren des Moduls zu komplex ist.

Monolith, Microservice
Die Module des Monolithen werden zu Microservices

Erfolg in drei Schritten

Architekturmuster in Form von Microservices lösen also die aus der monolithischen Software-Architektur bekannten Probleme. Bei einer Umstellung vom Monolithen zu Microservices gilt es, eine komplette Neudefiniton der bestehenden Landschaft zu vermeiden. Stattdessen hilft eine systematische Refactoring-Strategie in den drei genannten Schritten:

  1. Neue Features werden gleich zu neuen Microservices.
  2. Das Aufsplitten der Layer schafft Ordnung.
  3. Das Überführen der bestehenden Module in Microservices schließt den Umbau ab.

Schlussendlich wird der Monolith nach und nach schrumpfen, während die Anzahl der Microservices wächst – und mit der Anzahl der eingesetzten Dienste setzt ein weiterer Mehrwert der Microservices ein: Die Effizienz und Agilität der kleineren Entwicklungsteams wächst.


Über den Autor des Beitrags:

Hendry Anwar

Leave a reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.