Als Entwickler kann man ihnen fast nicht ausweichen – den Microservice-Architekturen. Die Entscheidung für deren Einsatz ist oft schon getroffen, bevor es die erste User-Story im Backlog und die erste Zeile Code im Repository gibt.
„Microservice“ lautet scheinbar die Antwort auf alle Fragen nach der besten Umsetzung heutiger Business-Probleme. Netflix und andere dienen als schillerndes Beispiel für den Erfolg dieser Architektur.
Aber sind sie wirklich der einzige Weg ins Ziel? Sind sie Fluch oder Segen? Dem wollen wir auf den Grund gehen.

Zielpublikum: Entwickler:innen, Architekt:innen, Entscheider mit technischem Background
Voraussetzungen: Kenntnisse in Java oder einer anderen objektorientierten Sprache, Grundkenntnisse in Software-Architektur
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract
Als Entwickler kann man ihnen fast nicht ausweichen – den Microservice-Architekturen. Egal ob Neuauflage einer Bestandsanwendung oder Green-Field-Projekt, der Architektur-Ansatz ist oft schon festgelegt, bevor es die erste User-Story im Backlog und die erste Zeile Code im Repository gibt.
„Microservice“ lautet scheinbar die Antwort auf alle Fragen nach der besten Umsetzung heutiger Business-Probleme. Unternehmen wie Netflix dienen als schillerndes Beispiel für den Erfolg dieser Architektur. Und alle wollen nacheifern. Mit modernen Tools, agilen Methoden und motivierten Entwicklern wird das schon zu schaffen sein.
Aber was waren eigentlich die Architektur-Zziele, die zur Entscheidung geführt haben? Und welche Alternativen hätte es gegeben? Was sind die Kernprobleme, die wir lösen müssen? Und sind Microservices wirklich der einzige Weg ins Ziel? Oder wieso wurden sie gewählt?
Wir haben uns angeschaut, warum Vergleiche mit Netflix hinken, warum Microservice-Architekturen sich oft zu mehr Fluch als Segen entwickeln und dass die Rolle der Entwickler bei diesem Scheitern oft unterschätzt wird.