© Excellent backgrounds/Shutterstock.com
Java Magazin
Interview mit Bernd Rücker

„Microservices haben einen Preis: Komplexität“

Microservices sind, wenn man über Softwarearchitektur spricht, in aller Munde. Der Kampf des Architekten, der mit Microservices den „bösen“ Monolithen aufbrechen muss, hat schon fast etwas Episches. Doch sind Microservices wirklich das Allheilmittel für die moderne Softwarearchitektur? Bernd Rücker gibt in diesem Interview Antwort auf diese und weitere Fragen.

Bernd Rücker


Java Magazin: Hallo Bernd und danke, dass du dir Zeit genommen hast. Auf der W-JAX 2018 hast du ein aktuelles Thema der IT-Branche vorgestellt: Microservices. Jeder spricht darüber, aber warum sollte man mit Microservices arbeiten? Bernd Rücker: Ein Microservice soll möglichst isoliert von anderen Microservices sein. Das betrifft sowohl Daten, aber auch z. B. Entwicklung und Deployment. Dadurch können sich unterschiedliche Teams um die verschiedenen Microservices kümmern. Dabei müssen sie wenig miteinander reden. Das ermöglicht, dass in der Summe mehr Entwickler bzw. Teams an einem komplexen System arbeiten können.JM: Was sind die größten Schwierigkeiten bei der Implementierung von Microservices?Rücker: Neben dem notwendigen Skillset liegt die größte Herausforderung meiner Ansicht nach in der Kollaboration der Microservices. Das fängt etwa bei der Frage an, wie kommuniziert werden soll – REST? gRPC? Messaging? Event-driven? –, und geht bis hin zu komplexen Entscheidungen rund um Choreographie vs. Orchestration.Was im ersten Enthusiasmus oft untergeht: Jede Kommunikationsart ist „remote“. Eine Microservices-Architektur ist immer ein verteiltes System. In solchen habe ich viele Probleme allein deshalb, weil Netzwerke immer unzuverlässig sind. So ist mein Gegenüber vielleicht gar nicht oder nur sehr langsam erreichbar oder ich habe einen Call erfolgreich abgesetzt, ohne es selbst zu wissen, da ich einen Netzwerkfehler bekommen habe.ACID-Transaktionen können nicht verwendet werden, das heißt, in Projekten muss man sehr genau darüber nachdenken, wie man es erreicht, dass mehrere Aktionen in einer „Alles oder nichts“-Semantik ausgeführt werden können.JM: Welche Anforderungen setzen Microservices voraus und auf was sollten sich Entwickler, die damit arbeiten wollen, einstellen?Rücker: Microservices ergeben nur Sinn, wenn ich mit mehreren Teams arbeite. Das Vorgehen erfordert typischerweise einen hohen Reifegrad der Organisation, da viele Themen mitkommen (automatisierte Deployment Pipelines, Registries, Contract-based Testing, Observability, …). Entwickler sollten sich darauf einstellen, viel lernen zu müssen. Auch sollte keine Silver Bullet erwartet werden, die auf einmal alle Probleme löst. Für Entwickler haben Microservices zwar den Vorteil eines klar definierten Scopes in einem Microservice, dafür verschiebt sich die Komplexität eben in die Kollaboration der Services.JM: Sind Microservices nur vorteilhaft oder sind sie vielleicht doch nicht das Allheilmitt...

Java Magazin
Interview mit Bernd Rücker

„Microservices haben einen Preis: Komplexität“

Microservices sind, wenn man über Softwarearchitektur spricht, in aller Munde. Der Kampf des Architekten, der mit Microservices den „bösen“ Monolithen aufbrechen muss, hat schon fast etwas Episches. Doch sind Microservices wirklich das Allheilmittel für die moderne Softwarearchitektur? Bernd Rücker gibt in diesem Interview Antwort auf diese und weitere Fragen.

Bernd Rücker


Java Magazin: Hallo Bernd und danke, dass du dir Zeit genommen hast. Auf der W-JAX 2018 hast du ein aktuelles Thema der IT-Branche vorgestellt: Microservices. Jeder spricht darüber, aber warum sollte man mit Microservices arbeiten? Bernd Rücker: Ein Microservice soll möglichst isoliert von anderen Microservices sein. Das betrifft sowohl Daten, aber auch z. B. Entwicklung und Deployment. Dadurch können sich unterschiedliche Teams um die verschiedenen Microservices kümmern. Dabei müssen sie wenig miteinander reden. Das ermöglicht, dass in der Summe mehr Entwickler bzw. Teams an einem komplexen System arbeiten können.JM: Was sind die größten Schwierigkeiten bei der Implementierung von Microservices?Rücker: Neben dem notwendigen Skillset liegt die größte Herausforderung meiner Ansicht nach in der Kollaboration der Microservices. Das fängt etwa bei der Frage an, wie kommuniziert werden soll – REST? gRPC? Messaging? Event-driven? –, und geht bis hin zu komplexen Entscheidungen rund um Choreographie vs. Orchestration.Was im ersten Enthusiasmus oft untergeht: Jede Kommunikationsart ist „remote“. Eine Microservices-Architektur ist immer ein verteiltes System. In solchen habe ich viele Probleme allein deshalb, weil Netzwerke immer unzuverlässig sind. So ist mein Gegenüber vielleicht gar nicht oder nur sehr langsam erreichbar oder ich habe einen Call erfolgreich abgesetzt, ohne es selbst zu wissen, da ich einen Netzwerkfehler bekommen habe.ACID-Transaktionen können nicht verwendet werden, das heißt, in Projekten muss man sehr genau darüber nachdenken, wie man es erreicht, dass mehrere Aktionen in einer „Alles oder nichts“-Semantik ausgeführt werden können.JM: Welche Anforderungen setzen Microservices voraus und auf was sollten sich Entwickler, die damit arbeiten wollen, einstellen?Rücker: Microservices ergeben nur Sinn, wenn ich mit mehreren Teams arbeite. Das Vorgehen erfordert typischerweise einen hohen Reifegrad der Organisation, da viele Themen mitkommen (automatisierte Deployment Pipelines, Registries, Contract-based Testing, Observability, …). Entwickler sollten sich darauf einstellen, viel lernen zu müssen. Auch sollte keine Silver Bullet erwartet werden, die auf einmal alle Probleme löst. Für Entwickler haben Microservices zwar den Vorteil eines klar definierten Scopes in einem Microservice, dafür verschiebt sich die Komplexität eben in die Kollaboration der Services.JM: Sind Microservices nur vorteilhaft oder sind sie vielleicht doch nicht das Allheilmitt...

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