© Liashko/Shutterstock.com
Vom Deployment-Monolithen zum Microservices-System

Microservices-Migration


Wenn ein Deployment-Monolith mit den Ansprüchen nicht mehr Schritt halten kann, sind Microservices oft die Lösung. Dann muss das vorhandene System in ein Microservices-System migriert werden. Diese Herausforderung kann sehr unterschiedlich angegangen werden.

Die Migration zu Microservices soll etwas an dem vorhandenen System verbessern [1] – [4]. Um zu verstehen, wieso Microservices besser als Architektur geeignet sein können als ein Deployment-Monolith, muss man zunächst den Begriff „Microservice“ definieren. Eine mögliche Definition ist, dass Microservices Module sind, die zur Organisation eines Projekts dienen – so wie Java Packages oder Java Archives (JARs) auch. Ein Modul kann isoliert geändert und verstanden werden, sodass es weitgehend unabhängig von den anderen Modulen weiterentwickelt werden kann.

Die ISA (Independent Systems Architecture) Principles [5] sind eine Sammlung von Best Practices für Microservices. Der Name sagt schon, was das Ziel ist: Eine größere Unabhängigkeit, als sie mit klassischen Modulen möglich ist. Daher sind Microservices in Docker-Containern laufende Prozesse. Wenn die Module in den Docker-Container implementiert sind, können sie unabhängig voneinander deployt werden, jedes Modul kann andere Technologien nutzen, und der Absturz eines Moduls reißt die anderen nicht mit. In einem Deployment-Monolithen laufen alle Module zusammen in einem Prozess, sodass alle Module gemeinsam deployt werden müssen. Es muss auch einen gemeinsamen Technologiestack geben. Ein Speicherleck bringt den gesamten Deployment-Monolithen zum Absturz. So bieten die Microservices in den Containern also eine Unabhängigkeit beim Deployment, dem Technologiestack und beim Ausfall.

Diesen Vorteilen steht vor allem der Nachteil gegenüber, dass es bei einem Microservices-System nicht nur einen Prozess gibt, sondern eine Vielzahl von Prozessen. Das erhöht vor allem die Komplexität im Betrieb. Wenn die Vorteile diese Nachteile aufwiegen, sind Microservices die einfachste Architektur, und das System sollte mit Microservices umgesetzt werden. Natürlich gilt das auch für die Migration eines Systems zu einem Microservices-System.

Migrationsstrategie: schrittweise zum Ziel

Die Migration in ein Microservices-System könnte theoretisch in einem einzigen Schritt erfolgen: Bei einem Deployment wird statt des Deployment-Monolithen eine Menge von Microservices deployt. Das erhöht das Risiko, da sich auf einen Schlag die Architektur des gesamten Systems grundlegend ändert. Die Migration hin zu Microservices kann mit der Nutzung anderer Basistechnologien einhergehen, was das Risiko weiter erhöht. Außerdem dauert es sehr lange, bis das System vollständig migriert ist, sodass man von den Vorteilen der Microservices erst sehr spät profitiert.

Daher ist es sinnvoller, das System schrittweise zu migrieren. Es wird zunächst nur ein neuer Microservice zusammen mit dem Deployment-Monolithen in Produktion gebracht, dann schrittweise weitere Microservices. Das Risiko reduziert sich: Die Microservices werden peu à peu aus dem System herausgelöst, sodass die Änderungsschritte kleiner und dementsprechend risikoärmer sind. Außerdem profitiert das System schneller von den Vorteilen der Microservices, da die ersten Teile schneller als Microservices umgesetzt werden. Zudem kann man während der Migration die Prioritäten ändern und andere Teile des Systems früher oder später als Microservices migrieren.

Wie erwähnt haben Microservices eine Vielzahl von Vorteilen. Die Migrationsstrategie muss dafür sorgen, diese Vorteile möglichst früh zu realisieren. Deshalb haben die erwarteten Vorteile der Microservices-Architektur einen erheblichen Einfluss auf die Migrationsstrategie.

Stabilität als Ziel

In einem Projekt [6] standen meine Kollegen vor der Herausforderung, ein System zu stabilisieren. Microservices können als Lösung dafür sinnvoll sein, weil sie getrennt ausfallen, wie bereits erwähnt. Außerdem sind Microservices verteilte Systeme, bei denen es viel mehr Server gibt und Kommunikation über das unzuverlässige Netzwerk stattfindet. Es ist also wahrscheinlich, dass irgendetwas in dem Microservices-System gerade nicht funktioniert. Damit dann nicht das gesamte System ausfällt, muss das System resilient (etwa: widerstandfähig) sein. Daher gibt es im Microservices-Bereich einige Patterns, um die Stabilität eines Systems zu erhöhen. Eine gute Sammlung stellt Michael T. Nygards Buch „Release It!“ dar [7]. Auch die Patterns können die Stabilität des Systems verbessern.

Das System in besagtem Projekt hatte Netzwerkverbindungen zu externen Systemen, die nicht sehr zuverlässig waren. Diese Verbindungen wurden mit Time-outs versehen. Dadurch wird ein Zugriff abgebrochen, wenn er zu lange dauert. So kann erreicht werden, dass nicht etwa alle Threads blockieren, weil sie auf die Antwort externer Systeme warten. Ebenso wurden Circuit Breaker eingebaut. Das sind eigentlich Sicherungen im Stromkreislauf. Bei einem Softwaresystem unterbricht der Circuit Breaker die Kommunikation mit einem entfernten System, sobald eine größere Anzahl Fehler aufgetreten ist. Die Aufrufe führen dann sofort zu einem Fehler, sodass auch ohne Time-out keine Ressourcen blockiert werden....

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