© Liashko/Shutterstock.com
Entwickler Magazin
Dekomposition von Microservices

Wie schneide ich richtig?

Auch wenn sich Programmiersprachen und -paradigmen immer wieder neu erfinden, haben manch alte Prinzipien heute noch ihre Gültigkeit. Bei der Frage, wie man Microservices am besten trennt, hilft das Prinzip des Information Hiding aus den 70er-Jahren. So können Microservices ihre vollen Stärken ausspielen.

Thomas Franz


Microservices ermöglichen die parallele Entwicklung und Inbetriebnahme von Software in kleinen Teams. Sie unterstützen daher sowohl agile Vorgehensweisen als auch geschäftliche Ziele, wie eine schnellere Time to Market. Microservices setzen die vierzig Jahre alten Ziele der Modularisierung um, wie sie schon 1972 von David Parnas beschrieben wurden:

Managerial: Development time should be shortened, because separate groups would work on each mod­ule with little need for communication.Product flexibility: It should be possible to make drastic changes to one module without a need to change others.Comprehensibility: It should be possible to study the system one module at a time. The whole system can therefore be better designed because it is better understood.

Die meisten Programmiersprachen stellen heute Modularisierungskonzepte bereit, zum Beispiel Pakete in Java und Module in Python. Allerdings ist es oft ohne großen Aufwand möglich, Klassen anderer Module oder Pakete zu verwenden. Dadurch entsteht die Gefahr einer engen Kopplung, der Verstrickung von Code, die den Zielen der Modularisierung widerspricht.

Microservices forcieren per Definition eine lose Kopplung: Ein Microservice ist ein eigenständiger Prozess, der ausschließlich über Netzwerkschnittstellen mit anderen Microservices kommuniziert. Diese harte Trennung erschwert enge Kopplung und hilft dadurch Modularisierung einzuhalten.

Problemdekomposition ist kritischer denn je

Entsprechend obiger Definition von Microservices muss sich der Entwickler sehr sicher sein, was durch welchen Microservice implementiert wird und was nicht. Denn falls die Modularisierung, d. h. die Dekomposition, nachträglich geändert werden muss, kann das teuer werden – der harten Trennung wegen. Wenn beispielsweise zwei Microservices in unterschiedlichen Programmiersprachen geschrieben sind, ist eine aufwändige Portierung von Code notwendig. Innerhalb einer monolithischen Architektur hingegen lassen sich viele Veränderungen durch Refactoring-Maßnahmen, die zusätzlich noch von vielen Entwicklungswerkzeugen unterstützt werden, vergleichsweise günstig erledigen.

Aktuell wird vor dieser Herausforderung sogar diskutiert, ob ein Microservices-Projekt monolithisch oder wirklich direkt mit Microservices beginnen sollte [1]. Für die Antwort auf diese Frage ist es natürlich auch relevant, die methodische, technologische und prozessuale Reife zu betrachten. Dieser Artikel konzentriert sich auf den architekturbezogenen Kern dieser Fragestellu...

Entwickler Magazin
Dekomposition von Microservices

Wie schneide ich richtig?

Auch wenn sich Programmiersprachen und -paradigmen immer wieder neu erfinden, haben manch alte Prinzipien heute noch ihre Gültigkeit. Bei der Frage, wie man Microservices am besten trennt, hilft das Prinzip des Information Hiding aus den 70er-Jahren. So können Microservices ihre vollen Stärken ausspielen.

Thomas Franz


Microservices ermöglichen die parallele Entwicklung und Inbetriebnahme von Software in kleinen Teams. Sie unterstützen daher sowohl agile Vorgehensweisen als auch geschäftliche Ziele, wie eine schnellere Time to Market. Microservices setzen die vierzig Jahre alten Ziele der Modularisierung um, wie sie schon 1972 von David Parnas beschrieben wurden:

Managerial: Development time should be shortened, because separate groups would work on each mod­ule with little need for communication.Product flexibility: It should be possible to make drastic changes to one module without a need to change others.Comprehensibility: It should be possible to study the system one module at a time. The whole system can therefore be better designed because it is better understood.

Die meisten Programmiersprachen stellen heute Modularisierungskonzepte bereit, zum Beispiel Pakete in Java und Module in Python. Allerdings ist es oft ohne großen Aufwand möglich, Klassen anderer Module oder Pakete zu verwenden. Dadurch entsteht die Gefahr einer engen Kopplung, der Verstrickung von Code, die den Zielen der Modularisierung widerspricht.

Microservices forcieren per Definition eine lose Kopplung: Ein Microservice ist ein eigenständiger Prozess, der ausschließlich über Netzwerkschnittstellen mit anderen Microservices kommuniziert. Diese harte Trennung erschwert enge Kopplung und hilft dadurch Modularisierung einzuhalten.

Problemdekomposition ist kritischer denn je

Entsprechend obiger Definition von Microservices muss sich der Entwickler sehr sicher sein, was durch welchen Microservice implementiert wird und was nicht. Denn falls die Modularisierung, d. h. die Dekomposition, nachträglich geändert werden muss, kann das teuer werden – der harten Trennung wegen. Wenn beispielsweise zwei Microservices in unterschiedlichen Programmiersprachen geschrieben sind, ist eine aufwändige Portierung von Code notwendig. Innerhalb einer monolithischen Architektur hingegen lassen sich viele Veränderungen durch Refactoring-Maßnahmen, die zusätzlich noch von vielen Entwicklungswerkzeugen unterstützt werden, vergleichsweise günstig erledigen.

Aktuell wird vor dieser Herausforderung sogar diskutiert, ob ein Microservices-Projekt monolithisch oder wirklich direkt mit Microservices beginnen sollte [1]. Für die Antwort auf diese Frage ist es natürlich auch relevant, die methodische, technologische und prozessuale Reife zu betrachten. Dieser Artikel konzentriert sich auf den architekturbezogenen Kern dieser Fragestellu...

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