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

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

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


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

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