© best_vector/Shutterstock.com
Sind Microservices ein Irrweg und elegante Monolithen die Lösung?

Kolumne: Stropek as a Service


Meine Twitter-Timeline läuft im Moment über wegen der Diskussionen, ob Microservices nicht ein großer Irrtum waren. Man hört Lobgesänge auf elegante Monolithen. Microservices seien im Betrieb viel zu komplex. Die lose Kopplung der Services führe zu enormem Kommunikationsaufwand und damit schlechter Performance. Getrennte Datenspeicher für jeden Microservice seien der pure Horror angesichts der zigfach duplizierten Datenbestände und der daher notwendigen Datensynchronisation.

Ich habe in dieser Kolumne schon oft über verschiedene Aspekte geschrieben, wie Microservices umgesetzt werden und welche Werkzeuge Public Clouds wie Microsoft Azure für ihre Umsetzung beinhalten. Angesichts der immer lauter werdenden Diskussion möchte ich diesmal das Warum in dem Mittelpunkt stellen.

Kundenorientierung

Meiner Ansicht nach müssen moderne Entwicklungsteams Kundenorientierung ganz weit oben auf ihre Prioritätenliste setzen. Es hilft nichts, wenn Software wunderbar strukturiert und technisch auf dem neuesten Stand ist, aber nicht das tut, was die Benutzer verlangen. Als Entwicklungsteams dürfen wir beschäftigt sein nicht mit produktiv sein verwechseln. Es ist leicht, uns mit technischen Raffinessen selbst zu beschäftigen. Produktiv sind wir nur, wenn aus dem investierten Entwicklungsaufwand auch eine konkrete Verbesserung aus Kundensicht resultiert. Benutzern ist es vollkommen egal, ob die Software in der genormten Testumgebung gute Performance zeigt, für sie zählt die Performance im Echtbetrieb unter den Rahmenbedingungen, die bei ihnen vorzufinden sind.

Microservices helfen aus meiner Sicht, eine Entwicklungsorganisation aufzubauen, die diese Kundenorientierung widerspiegelt. Der Grund ist, dass Microservices nicht nach technischen Kriterien abgegrenzt werden, sondern nach inhaltlichen. Man spricht je Microservice vom Bounded Context, einem fachlich abgegrenzten Teilbereich, in dem wichtige Geschäftsprozesse ablaufen. Die Gliederung von Microservices orientiert sich an den Denkmustern und Prozessen der Kunden, nicht an technischen Konzepten aus der Softwareentwicklung. Microservices wie Datenbankservice, Berichtsgenerator oder Lokalisierungsservice sind Negativbeispiele. Sie repräsentieren technische Cross-Cutting Concerns, und als Entwicklungsteam tendieren wir dazu, sie in zentrale Module oder Services auszugliedern, um Codeduplizierung zu vermeiden.

Benutzer denken aber anders. Ihnen sind ihre Geschäftsprozesse wichtig, nicht deren softwaretechnische Umsetzung. Sie ...

Neugierig geworden?

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