© Excellent backgrounds/Shutterstock.com
Java Magazin
Alternativen zum Hype

Microservices - oder doch nicht?

Sie sind in aller Munde: Microservices. Jedoch handelt es sich bei ihnen, wie bei jeder anderen Architektur auch, um ein Trade-off. Diese Tatsache führt umgehend zu der Frage, in welchen Bereichen Microservices überhaupt sinnvoll sind, wie es mit ihnen weitergeht und was nach ihnen kommt.

Eberhard Wolff


Video: Beyond Microservices – ein Blick hinter den Hype

Um die Vorteile und Herausforderungen von Microservices [1] zu verstehen, sollte zunächst der Begriff definiert werden. Dabei helfen die ISA-Prinzipien (Independent Systems Architecture) [2]:

Da es sich bei Microservices nur um eine andere Art von Modulen handelt, die als Docker-Container oder beispielsweise als Serverless-Funktionen umgesetzt werden, stehen sie in Konkurrenz zu anderen Modularisierungsvarianten wie Java Packages oder JARs. Bei der Implementierung von Microservices gibt es jedoch viel mehr Freiheiten; jeder Microservice kann in einer anderen Programmiersprache geschrieben sein. Es gibt zwei Ebenen von Architektur: Die Makroarchitektur umfasst Entscheidungen, die alle Microservices beeinflussen. Die Mikroarchitektur betrifft Entscheidungen, die nur einen Microservice beeinflussen. Diese Unterscheidung ist wichtig, weil erst durch Microservices so viele Freiheiten entstehen, dass eine Mikroarchitektur sinnvoll ist. Darüber hinaus verfügt jeder Microservice über eine eigene Continuous Delivery Pipeline. Ansonsten ginge ein wesentlicher Vorteil von Microservices verloren: das unabhängige Deployment.

Organisatorische Vorteile

Durch Microservices ergeben sich Vorteile im Bereich der Organisation. Das erscheint zunächst merkwürdig, schließlich sind Microservices „nur“ eine Architektur. Jedoch hat Architektur eben auch Auswirkungen auf die Organisation: Die Alternative zu Microservices wäre ein Deployment-Monolith, in dem alle Module zusammen deployt werden, was jedoch einige Einschränkungen bedeutet. Es ist beispielsweise nicht möglich, ein Feature in einem Modul zu implementieren und dann nur dieses Modul zu deployen. Deshalb erfordert das Deployment eine Koordinierung: Alle Module müssen in einer Version vorliegen, die tatsächlich sinnvoll deployt werden kann. Außerdem ist es notwendig, dass der Deployment-Monolith eine gemeinsame technische Basis hat – zum Beispiel die JVM oder eine bestimmte Programmiersprache. Im Fall von Java müssen alle Bibliotheken in nur einer festgelegten Version vorhanden sein. Deshalb ist es notwendig, dass alle Module mit diesen Bibliotheksversionen umgesetzt sind und diese technische Basis auch mit allen Teams koordiniert wird (Abb. 1). Im Gegensatz dazu können Microservices einzeln deployt werden und jeweils andere technologische Entscheidungen umsetzen (Abb. 2). Diese technologischen Entscheidungen müssen nicht unbedingt dazu führen, dass jeder Microse...

Java Magazin
Alternativen zum Hype

Microservices - oder doch nicht?

Sie sind in aller Munde: Microservices. Jedoch handelt es sich bei ihnen, wie bei jeder anderen Architektur auch, um ein Trade-off. Diese Tatsache führt umgehend zu der Frage, in welchen Bereichen Microservices überhaupt sinnvoll sind, wie es mit ihnen weitergeht und was nach ihnen kommt.

Eberhard Wolff


Video: Beyond Microservices – ein Blick hinter den Hype

Um die Vorteile und Herausforderungen von Microservices [1] zu verstehen, sollte zunächst der Begriff definiert werden. Dabei helfen die ISA-Prinzipien (Independent Systems Architecture) [2]:

Da es sich bei Microservices nur um eine andere Art von Modulen handelt, die als Docker-Container oder beispielsweise als Serverless-Funktionen umgesetzt werden, stehen sie in Konkurrenz zu anderen Modularisierungsvarianten wie Java Packages oder JARs. Bei der Implementierung von Microservices gibt es jedoch viel mehr Freiheiten; jeder Microservice kann in einer anderen Programmiersprache geschrieben sein. Es gibt zwei Ebenen von Architektur: Die Makroarchitektur umfasst Entscheidungen, die alle Microservices beeinflussen. Die Mikroarchitektur betrifft Entscheidungen, die nur einen Microservice beeinflussen. Diese Unterscheidung ist wichtig, weil erst durch Microservices so viele Freiheiten entstehen, dass eine Mikroarchitektur sinnvoll ist. Darüber hinaus verfügt jeder Microservice über eine eigene Continuous Delivery Pipeline. Ansonsten ginge ein wesentlicher Vorteil von Microservices verloren: das unabhängige Deployment.

Organisatorische Vorteile

Durch Microservices ergeben sich Vorteile im Bereich der Organisation. Das erscheint zunächst merkwürdig, schließlich sind Microservices „nur“ eine Architektur. Jedoch hat Architektur eben auch Auswirkungen auf die Organisation: Die Alternative zu Microservices wäre ein Deployment-Monolith, in dem alle Module zusammen deployt werden, was jedoch einige Einschränkungen bedeutet. Es ist beispielsweise nicht möglich, ein Feature in einem Modul zu implementieren und dann nur dieses Modul zu deployen. Deshalb erfordert das Deployment eine Koordinierung: Alle Module müssen in einer Version vorliegen, die tatsächlich sinnvoll deployt werden kann. Außerdem ist es notwendig, dass der Deployment-Monolith eine gemeinsame technische Basis hat – zum Beispiel die JVM oder eine bestimmte Programmiersprache. Im Fall von Java müssen alle Bibliotheken in nur einer festgelegten Version vorhanden sein. Deshalb ist es notwendig, dass alle Module mit diesen Bibliotheksversionen umgesetzt sind und diese technische Basis auch mit allen Teams koordiniert wird (Abb. 1). Im Gegensatz dazu können Microservices einzeln deployt werden und jeweils andere technologische Entscheidungen umsetzen (Abb. 2). Diese technologischen Entscheidungen müssen nicht unbedingt dazu führen, dass jeder Microse...

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