Suche
Interview mit Bernd Rücker

„Microservices machen nur Sinn, wenn ich mit mehreren Teams arbeite“

Savvas Hajiraftis

Bernd Rücker

Microservices sind, wenn man über Softwarearchitektur spricht, in aller Munde. Der Kampf vom 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 zur W-JAX 2018 Antwort auf diese und weitere Fragen.

JAXenter: Hallo Bernd und danke, dass du dir Zeit genommen hast. Auf der W-JAX 2018 stellst du ein aktuell allgegenwärtiges Thema der IT-Branche vor: Microservices. Jeder spricht darüber, aber warum genau sollte man eigentlich mit Microservices arbeiten?

Bernd Rücker: Ein Microservice soll möglichst isoliert von anderen Microservices sein. Das betrifft sowohl die Daten, aber auch z.B. die Entwicklung und das Deployment. Dadurch können sich unterschiedliche Teams um die verschiedenen Microservices kümmern – wobei sie so wenig wie möglich miteinander reden müssen. Dies wiederum ermöglicht, dass in Summe mehr Entwickler/Teams an einem komplexen System arbeiten können.

JAXenter: Was sind deiner Erfahrung nach die größten Schwierigkeiten bei der Implementierung von Microservices?

Bernd Rücker: Neben dem notwendigen Skill-Set (siehe unten) liegt die größte Herausforderung meiner Ansicht nach in der Kollaboration der Microservices. Das fängt z.B. bei der Frage an, wie kommuniziert werden soll (REST? gRPC? Messaging? Event-driven?) und geht bis zu relativ komplexen Entscheidungen rund um Choreographie vs. Orchestration. Es ist nicht leicht, das Problemfeld wirklich zu verstehen und eine sinnvolle Lösung – abseits von aktuellen Hypes oder vereinfachten Plattitüden – auszuwählen.

Die größte Herausforderung liegt meiner Ansicht nach in der Kollaboration der Microservices.

Was im ersten Enthusiasmus meist auch übersehen wird: Jede Kommunikationsart ist „remote“ – eine Microservice-Architektur ist immer ein verteiltes System. Und in verteilten Systemen 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. Dies ist ein komplexes Problemfeld, das ich auch in meinem Talk auf der W-JAX aufzeigen will – um den Teilnehmern dann aber auch zumindest ansatzweise Lösungen an die Hand zu geben.

In einer aktuellen Umfrage war die Top-Antwort zu Problemen mit 59% übrigens „Lack of visibility into end-to-end business processes that span multiple services”. Das ist natürlich nachvollziehbar, wenn viele kleine Services benötigt werden. Um etwas sinnvolles für den Kunden auszuführen, wird es schwieriger, dieses Zusammenspiel zu verstehen. Und die zweithäufigste Antwort war mit 50% übrigens: „Ambigous error handling, leading to unadressed errors at the boundaries between microservices”.

JAXenter: Was für Anforderungen setzen Microservices voraus und auf was sollten sich Entwickler, die mit ihnen arbeiten wollen, einstellen?

Bernd Rücker: Microservices machen nur Sinn, wenn ich mit mehreren Teams arbeite. Das Vorgehen erfordert dann typischerweise auch einen hohen Reifegrad der Organisation, da viele Themen mitkommen (automatisierte Deployment Pipelines, Registrys, Contract-based Testing, Observability, …). Das heißt 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, wie ich oben bereits erwähnte.

JAXenter: Ist die Arbeit mit Microservices nur vorteilhaft? Oder sind Microservices vielleicht doch nicht das Allheilmittel, das man gegen die Softwaremonolithen in der Entwicklung einsetzten kann?

Der Vorteil von Microservices kommt mit einem Preis.

Bernd Rücker: Wie immer kommt es darauf an. Ich glaube, dass bei größeren Softwaresystemen, die von mehreren Teams betreut werden müssen, Microservices Vorteile ausspielen. Man erkauft sich diesen Vorteil aber definitiv zu einem Preis (hauptsächlich erhöhte Komplexität), sodass man im Einzelfall einfach abwägen muss. Und das wird immer eine individuelle Entscheidung sein, da es eben auch von der Reife, dem aktuellen Entwicklungsvorgehen, den Entwicklern, dem Tech-Stack und der vorhandenen Legacy abhängt. Mittelfristig glaube ich, dass die meisten typischen Business-Anwendungen in Microservices-Architekturen gebaut werden.

JAXenter: Was sollten die Leute, die deine Session besucht haben, mit nach Hause nehmen?

Bernd Rücker: Sie sollten besser verstanden haben, welche Herausforderungen verteilte Systeme und Remote-Kommunikation mit sich bringen. Sie sollten aber auch konkrete Ideen haben, wie sie diese Herausforderungen angehen. Viele der Probleme erfordern ein gewisses Maß an State Handling, was ich ebenfalls genauer darlegen will. Da ich mit Live Coding arbeite und der Code verfügbar ist, können die Teilnehmer natürlich auch direkt selbst loslegen und mit Code-Beispielen rumspielen.

Bernd Rücker entwickelt seit über 15 Jahren Software und hat zahlreichen Kunden dabei geholfen, Kernprozesse zu automatisieren, so z.B. den Bestellprozess bei Zalando, Auftragsprozesse bei T-Mobile oder Patentanträge in der Schweiz. Er hat aktiv an der Entwicklung verschiedener Open Source Workflow Engines mitgearbeitet und ist Mitgründer der Camunda, eines Open-Source-Unternehmen, das Workflow-Automatisierung neu erfindet. Er ist zudem Co-Autor des „Praxishandbuch BPMN“, spricht regelmäßig auf Konferenzen und schreibz für verschiedene Magazine. Seit geraumer Zeit beschäftigt er sich mit Workflow-Automation-aradigmen, die in moderne Architekturen rund um Microservices, Domain-driven Design, Event-driven Architecture und reaktiver Systeme passen.
Geschrieben von
Savvas Hajiraftis
Savvas Hajiraftis
Savvas Dimitrios Hajiraftis ist seit November 2017 Teil der JAXenter-Redaktion und studiert Lehramt an der Technischen Universität Darmstadt.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "„Microservices machen nur Sinn, wenn ich mit mehreren Teams arbeite“"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Alexander Zimmermann
Gast

Ich finde es Schade dass nicht auf die Themen Skalierung und Verfügbarkeit eingegangen wurde. Für den Betrieb ist es nämlich ein enormer Vorteil, nur die Komponenten die wirklich stark beansprucht werden skalieren zu können. Mit einem Monolithen geht das nicht.

Außerdem kann ich besonders kritische Teile über die ganze Welt verteilen und habe damit nicht den Overhead der restlichen Bestandteile.