© Liashko/Shutterstock.com
Entwickler Magazin
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.

Eberhard Wolff


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 pro...

Entwickler Magazin
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.

Eberhard Wolff


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 pro...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang