Microservices funktionieren nicht?

„Microservices funktionieren nicht.“

Das ist so ein Satz, bei dem Architektur kurz die Augen schließt, tief durchatmet und hofft, dass danach noch ein Nebensatz kommt.

Denn vielleicht stimmt der Satz sogar.

Nur vermutlich nicht so, wie er gemeint ist.

Die spannendere Frage ist nicht, ob Microservices funktionieren. Die spannendere Frage ist:

Was genau hat nicht funktioniert?

Waren es wirklich Microservices?
Oder war es ein verteilter Monolith?
Wurden fachliche Grenzen geschnitten?
Oder nur technische Artefakte?
Konnten Teams unabhängig liefern?
Oder mussten Releases trotzdem über fünf Services, drei Teams und ein Change Board koordiniert werden?

Und aus Frontend-Sicht besonders wichtig:

War die UI Teil des fachlichen Schnitts — oder nur der Ort, an dem alle schlechten Schnitte wieder zusammengeklebt wurden?

Die Aussage ernst nehmen

Wenn jemand nach 15 Jahren sagt: „Microservices funktionieren nicht“, sollte man das nicht arrogant wegwischen.

Wahrscheinlich steckt Erfahrung dahinter.
Wahrscheinlich gab es Schmerzen.
Wahrscheinlich gab es teure Projekte, zähe Releases, instabile Umgebungen, unklare Verantwortlichkeiten, schwer testbare Abläufe, Debugging über sieben Systeme hinweg und Meetings, die nur existierten, weil die Architektur sie brauchte.

Das ist real.

Nur beweist es nicht automatisch, dass Microservices nicht funktionieren.

Es beweist erst einmal nur:

Diese konkrete Form verteilter Architektur hat nicht funktioniert.

Und dann wird es interessant.

Denn viele Systeme, die als Microservices verkauft werden, sind fachlich keine Microservice-Architekturen. Sie sind technisch verteilte Anwendungen mit zentraler Denkweise.

Oder kürzer:

Ein Monolith wird nicht dadurch fachlich sauber, dass man ihn über HTTP verteilt.

Was genau hat nicht funktioniert?

Wenn Microservices angeblich nicht funktionieren, muss man bohren.

Nicht aus Rechthaberei. Sondern weil die Diagnose sonst wertlos bleibt.

Hat nicht funktioniert, dass Services unabhängig deploybar waren?
Gab es überhaupt unabhängige Deployments?

Hat nicht funktioniert, dass Teams autonom arbeiten konnten?
Gab es überhaupt Team Ownership?

Hat nicht funktioniert, dass Services fachlich geschnitten waren?
Oder wurden nur Tabellen, technische Module oder CRUD-Bereiche verteilt?

Hat nicht funktioniert, dass Datenhoheit klar war?
Oder griffen mehrere Services auf dieselben Daten, dieselben Modelle oder dieselbe Wahrheit zu?

Hat nicht funktioniert, dass das System beobachtbar war?
Oder war ein Fehler über Servicegrenzen hinweg ungefähr so gut nachvollziehbar wie ein Paket ohne Sendungsnummer?

Hat nicht funktioniert, dass die UI einfacher wurde?
Oder musste das Frontend aus fünf APIs, drei Statuscodes und zwei historischen Sonderfällen erraten, was der Nutzer eigentlich gerade sehen darf?

Das sind unterschiedliche Probleme.

Und sie haben unterschiedliche Ursachen.

Wer alles unter „Microservices funktionieren nicht“ zusammenfasst, macht es sich zu einfach. Das ist ungefähr so präzise wie: „Autos funktionieren nicht“, nachdem man mit Sommerreifen auf Glatteis gefahren ist.

Kann stimmen. Hilft aber nur bedingt.

Nicht jede verteilte Anwendung ist eine Microservice-Architektur

Eine Microservice-Architektur ist nicht einfach:

• viele Repositories
• viele Deployments
• viele REST-APIs
• viele Docker-Container
• viele Teams mit vielen Jira-Boards

Das ist erst einmal nur Verteilung.

Architektur entsteht nicht durch Anzahl.

Sie entsteht durch Grenzen, Verantwortung und Änderbarkeit.

Ein Service ist nur dann hilfreich, wenn er eine fachliche Verantwortung kapselt, klare Datenhoheit besitzt, sinnvoll beobachtbar ist, eigenständig getestet werden kann und von einem Team so verantwortet wird, dass Änderungen nicht jedes Mal durch das halbe Unternehmen wandern.

Wenn Änderung in Service A fast immer Änderung in Service B, C und D bedeutet, ist nichts wirklich unabhängig.

Wenn Releases koordiniert werden müssen, ist die Deployment-Grenze nur Dekoration.

Wenn Services sich ein gemeinsames Domain-Modell teilen, teilen sie oft auch ihre Schmerzen.

Wenn ein UI-Flow fünf synchrone Service-Calls braucht, um einen Button korrekt zu aktivieren, ist die fachliche Grenze vielleicht nicht dort, wo das Architekturdiagramm sie vermutet.

Ein verteilter Monolith ist ein Monolith, der gelernt hat, Netzwerkfehler zu produzieren.

Das klingt gemein. Ist aber oft erstaunlich präzise.

Die UI sitzt nicht oben drauf

Der vielleicht wichtigste Denkfehler steckt in einem alten Architekturbild:

Unten die Datenbank.
Darüber Services.
Darüber APIs.
Ganz oben die UI.

Als wäre die UI eine dünne Lackschicht. Ein bisschen Oberfläche. Ein bisschen hübsch machen. Ein bisschen Formular, Tabelle, Button.

Das war schon früher fragwürdig.

Heute ist es falsch.

Moderne Frontends sind interaktive, asynchrone, zustandsgetriebene Anwendungen. Sie enthalten Nutzerflüsse, Berechtigungen, Validierung, Fehlerzustände, Zwischenschritte, Optimistic Updates, ViewModels, fachliche Entscheidungen und sehr viel Bedeutung.

Die UI sitzt nicht oben drauf.

Sie ist Teil des fachlichen Schnitts.

Nutzer erleben keine Schichten.
Sie erleben einen Flow.

Sie wollen ein Anliegen erfassen, eine Bestellung prüfen, eine Aufgabe abschließen, eine Rechnung verstehen, eine Entscheidung treffen oder einen Fehler beheben.

Kein Nutzer denkt:

„Ah, schön, ich befinde mich gerade in der API-Schicht zwischen Service B und der Aggregation von Status C.“

Außer vielleicht Architekten. Aber die sollten bei der Produktgestaltung ohnehin nur unter Aufsicht in die Nähe echter Nutzer gelassen werden.

Das SOA-Erbe: technische Integration statt Produktfluss

SOA war nicht dumm.

Das muss man fairerweise sagen.

SOA hatte richtige Ideen:

• Services
• Verträge
• lose Kopplung
• Integration
• Wiederverwendung
• klare Schnittstellen

Das Problem war nicht die Idee, Systeme über Services zu strukturieren.

Das Problem war häufig, dass technische Integration für fachliche Architektur gehalten wurde.

Viele SOA-Landschaften dachten stark in zentralen Modellen, Integrationsflüssen, ESBs, Orchestrierung und Governance. Das hatte Gründe. Große Unternehmenslandschaften sind nicht einfach. Legacy-Systeme verschwinden nicht, nur weil ein Architekt ein neues Diagramm malt. Irgendjemand muss integrieren, übersetzen, stabilisieren und absichern.

Aber aus Produkt- und Frontend-Sicht entsteht dabei schnell ein Kernkonflikt.

SOA dachte oft:

• Modelle werden zentral technisch modelliert.
• Services liefern Daten.
• Die UI sitzt oben drauf.
• Der Nutzungskontext ist nachgelagert.

Nur arbeiten Nutzer nicht mit kanonischen Datenmodellen.

Sie arbeiten mit Absichten, Zuständen, Entscheidungen, Fehlern, Berechtigungen, Zwischenschritten und Bedeutung.

Ein kanonisches Modell kann technisch konsistent sein und trotzdem für eine konkrete UI-Situation unpassend sein.

Ein kanonisches Modell ist noch kein Produktmodell.

Technische Modelle erklären, wie Systeme Daten austauschen.
Produktmodelle erklären, was diese Daten für Nutzer bedeuten.

Das ist ein gewaltiger Unterschied.

Wenn man diesen Unterschied ignoriert, wird die UI irgendwann zum Übersetzungsbüro für eine Architektur, die den Nutzerfluss nie wirklich modelliert hat.

Wenn Architekturwissen bei wenigen Menschen sitzt

Viele SOA-Landschaften hatten noch ein anderes Problem: Das Kernwissen saß bei sehr wenigen Menschen.

Bei ESB-Spezialisten.
Bei Integrationsarchitekten.
Bei Leuten, die das kanonische Modell wirklich verstanden.
Bei Personen, die wussten, welcher Service in welchem Fall führend ist.
Bei Menschen, die historische Transformationen kannten.
Bei denen, die wussten, welche Ausnahme für welchen Kunden gilt.

Solange diese Menschen verfügbar waren, funktionierte das System.

Nicht schön vielleicht. Nicht schnell. Aber es funktionierte.

Wenn sie ausfielen, wurde Architektur zur Archäologie.

Dann begann die Grabung:

Warum wird dieses Feld hier umbenannt?
Warum darf Status ACTIVE in diesem Flow nicht aktiv bedeuten?
Warum ruft der Prozess erst Service A, dann B, dann wieder A?
Warum ist diese Transformation doppelt vorhanden?
Warum steht die Wahrheit in System X, aber nur für Mandant Y?
Warum weiß das niemand außer Ralf?

Das ist kein persönliches Versagen von Ralf.

Ralf hat wahrscheinlich jahrelang den Laden zusammengehalten.

Das Problem ist eine Architektur und Organisation, die kritisches Wissen nicht in klare Grenzen, Begriffe, Tests, Ownership und nachvollziehbare Flows übersetzt hat.

Wissensmonopole sind selten Absicht.

Sie entstehen, wenn Komplexität zentralisiert wird.

Und zentralisierte Komplexität fühlt sich eine Weile effizient an. Bis sie nicht mehr effizient ist. Dann ist sie ein Risiko mit Büro.

Microservices lösen SOA-Probleme nicht automatisch

Microservices können helfen, einige dieser Probleme zu lösen.

Aber sie tun das nicht automatisch.

Wenn man SOA nur durch kleinere Services ersetzt, aber dieselbe technische Modellierungsdenke behält, baut man den nächsten verteilten Integrationsknoten — nur moderner verpackt.

Dann heißt der ESB vielleicht API-Gateway.

Das zentrale Integrationswissen sitzt dann vielleicht beim Plattformteam.

Das kanonische Modell verteilt sich auf mehrere DTO-Pakete.

Die zentrale Orchestrierung wandert in synchrone Service-Call-Ketten.

Und das Frontend bekommt am Ende trotzdem technische Daten, aus denen es fachliche Bedeutung rekonstruieren muss.

Herzlichen Glückwunsch.

Der Elefant ist jetzt Cloud-native.

Das Problem bleibt.

Microservices funktionieren nicht, wenn sie nur Backend-Artefakte schneiden.

Sie funktionieren nur dann, wenn sie fachliche Verantwortung vertikal schneiden — inklusive Produkt, UX, Frontend, Backend, Tests und Betrieb.

Oder noch direkter:

Ein Microservice, dessen Fachlichkeit erst im Frontend zusammengesucht werden muss, ist kein sauberer fachlicher Schnitt. Er ist nur ein kleiner Backend-Baustein in einem größeren Architekturproblem.

Der verteilte Monolith

Nicht jede verteilte Anwendung ist eine Microservice-Architektur.

Es gibt Warnsignale.

Eine Änderung in Service A braucht Änderung in Service B, C und D.

Releases müssen koordiniert werden.

Services teilen sich eine Datenbank.

Services teilen sich ein gemeinsames Domain-Modell.

Ein UI-Flow braucht synchrone Call-Ketten über viele Services.

Teams können nicht unabhängig entscheiden.

API-Verträge folgen technischen Tabellen statt fachlichen Begriffen.

Fachliche Bedeutung entsteht erst im Frontend durch Mapping.

Es gibt keine klare Datenhoheit.

Observability fehlt.

Fehler lassen sich über Servicegrenzen hinweg kaum nachvollziehen.

Das ist dann keine autonome Service-Landschaft.

Das ist ein verteiltes Abhängigkeitsdiagramm mit Deployment-Pipeline.

Der Unterschied ist nicht akademisch. Er entscheidet darüber, ob Architektur Beweglichkeit ermöglicht oder verhindert.

Wenn alles gemeinsam geändert werden muss, ist nichts wirklich unabhängig.

Und wenn nichts unabhängig ist, sollte man sich ehrlich fragen, ob die Verteilung noch hilft — oder nur neue Fehlerklassen erzeugt.

Netzwerkfehler.
Versionierungsprobleme.
Timeouts.
Retries.
Konsistenzfragen.
Monitoring über Systemgrenzen.
Lokales Setup aus der Hölle.

Alles Dinge, die man in Kauf nehmen kann.

Aber bitte nicht für eine Architektur, die fachlich trotzdem gekoppelt bleibt.

Warum schlechte Service-Schnitte im Frontend sichtbar werden

Das Frontend ist oft der Ort, an dem schlechte Backend-Grenzen auffliegen.

Nicht weil das Frontend schuld ist.

Sondern weil Nutzerflüsse dort konkret werden.

Ein Architekturdiagramm kann elegant aussehen.
Ein Sequenzdiagramm kann plausibel wirken.
Ein Service-Schnitt kann auf Backend-Ebene sauber erscheinen.

Und dann kommt ein Screen.

Plötzlich muss die UI Daten aus fünf Services zusammensuchen.

Sie kennt technische IDs, interne Statuscodes und historische Flags.

Sie baut fachliche Bedeutung aus Mapping-Logik zusammen.

Fehlerzustände sind API-zentriert statt nutzerzentriert.

Buttons hängen an mehreren Backend-Zuständen, die niemand fachlich benennen kann.

ViewModels werden zu Reparaturschichten für falsche Boundaries.

UX-Begriffe passen nicht zu API-Begriffen.

Tests prüfen technische Responses, aber keine fachlichen Nutzerflüsse.

Produktentscheidungen scheitern an Service-Ownership-Diskussionen.

Und irgendwann ist das Frontend nicht mehr die Stelle, an der Nutzung modelliert wird.

Es ist die Integrationsschicht.

Nur ohne den Status, das Mandat und die Werkzeuge einer Integrationsschicht.

Wenn dein Frontend ständig fachliche Zusammenhänge rekonstruieren muss, sind deine Backend-Grenzen wahrscheinlich nicht so fachlich, wie sie im Architekturdiagramm aussehen.

Das ist einer der besten Architekturtests überhaupt.

Nicht: „Wie viele Services haben wir?“
Sondern: „Wie viel Fachlichkeit muss die UI reparieren, weil sie an keiner Grenze sauber modelliert wurde?“

Fachliche Ownership endet nicht am Controller

Ein weiterer Denkfehler: Eine Capability gehört dem Backend.

Nein.

Eine Capability gehört nicht dem Backend.
Sie gehört dem Produktfluss.

Fachliche Ownership endet nicht am Controller.

Eine echte fachliche Verantwortung umfasst:

• Produktproblem
• Nutzerabsicht
• UX
• Frontend
• Backend
• Tests
• Betrieb
• Monitoring
• fachliche Sprache
• Datenhoheit
• API-Verträge
• Fehlerverhalten

Das bedeutet nicht, dass jede Person alles können muss.

Natürlich braucht es Spezialisierung. Frontend, Backend, UX, Produkt, Test und Betrieb haben unterschiedliche Perspektiven, Werkzeuge und Tiefen.

Aber das Team muss die Capability als Ganzes verantworten können.

Wenn ein Team nur Backend-Endpunkte besitzt, aber nicht den Nutzerfluss versteht, ist der Schnitt unvollständig.

Wenn ein Frontend-Team nur konsumiert, was andere liefern, aber keine Mitverantwortung für API-Sprache, ViewModels und Fehlerverhalten hat, ist der Schnitt unvollständig.

Wenn UX Begriffe einführt, die in APIs, Tests und Monitoring nicht auftauchen, ist der Schnitt unvollständig.

Wenn Tests nur technische Antworten prüfen, aber keine Nutzerabsichten, ist der Schnitt unvollständig.

Frontend, Backend, UX, Produkt und Tests sind keine getrennten Welten.

Sie sind verschiedene Perspektiven auf dieselbe fachliche Verantwortung.

Sprache ist Architektur

Eine gemeinsame fachliche Sprache ist keine Backend-Sache.

Sie entsteht überall.

In UX-Texten.
In Labels.
In Fehlermeldungen.
In ViewModels.
In API-Verträgen.
In Events.
In Tests.
In Backend-Use-Cases.
In Monitoring-Dashboards.
In Support-Prozessen.

Wenn Backend, Frontend, UX, Produkt und Test unterschiedliche Begriffe für dieselbe Sache verwenden, ist das kein kosmetisches Problem.

Es ist ein Architekturproblem.

Ein Beispiel:

Backend sagt Case.
Frontend sagt Ticket.
UX sagt Anliegen.
Test sagt Vorgang.
Der Fachbereich sagt Fall.
Die API liefert ProcessItem.

Alle glauben, sie reden vom Gleichen.

Bis jemand eine Änderung baut.

Dann stellt sich heraus: Sie reden fast vom Gleichen. Aber nicht ganz. Und dieses „nicht ganz“ ist der Ort, an dem Bugs, Missverständnisse, Sonderfälle und endlose Abstimmungen wohnen.

Sprache ist Architektur.

Uneindeutige Begriffe erzeugen uneindeutige Systeme.

Das heißt nicht, dass ein Unternehmen ein globales Enterprise-Modell für alles braucht. Genau das wäre wieder die alte Falle.

Eine gute Architektur braucht keine globale Einheitssprache für alles.

Sie braucht eine eindeutige Sprache innerhalb eines fachlichen Kontextes.

Ein Begriff darf in unterschiedlichen Kontexten unterschiedlich bedeuten. Das ist normal. Manchmal sogar gesund.

Aber innerhalb eines fachlichen Schnitts muss klar sein, was gemeint ist.

Nicht ungefähr.
Nicht historisch gewachsen.
Nicht „das wissen wir doch alle“.

Sondern so klar, dass UX, Frontend, Backend, Tests, Betrieb und Support dieselbe fachliche Realität beschreiben können.

Moderne Architektur schneidet vertikal

Das horizontale Architekturmodell ist bequem.

Datenbank.
Backend.
API.
Frontend.

Man kann es leicht zeichnen. Es sieht geordnet aus. Es passt gut auf Folien. Und es erzeugt zuverlässig Übergaben.

Das Problem: Nutzerflüsse laufen nicht horizontal.

Sie laufen vertikal durch das System.

Ein echter Produktfluss umfasst:

• Produktziel
• Nutzerabsicht
• UX-Flow
• UI-Zustand
• Frontend-ViewModel
• API-Vertrag
• Backend-Use-Case
• Datenmodell
• Tests
• Betrieb
• Monitoring

Wenn diese Dinge auf unterschiedliche Verantwortlichkeiten verteilt sind, ohne gemeinsame Sprache und klare Ownership, entsteht Reibung.

Dann wird jede Produktänderung zur Integrationsaufgabe.

Ein Feld umbenennen? Abstimmung.

Einen Status anders anzeigen? Abstimmung.

Eine Fehlermeldung nutzerzentriert formulieren? Abstimmung.

Ein Button soll nur in bestimmten Fällen aktiv sein? Niemand weiß, wer den fachlichen Zustand besitzt.

Das ist kein Frontend-Problem.

Das ist ein Schnittproblem.

Moderne Architektur fragt deshalb nicht zuerst:

„Wie schneiden wir Services?“

Sie fragt:

„Wer verantwortet welchen fachlichen Nutzerfluss — von Absicht bis Betrieb?“

Erst danach stellt sich die Frage, ob daraus ein Microservice, ein Modul, ein Self-contained System, ein Bounded Context, ein Event-Flow oder etwas anderes wird.

Nicht Services schneiden.

Verantwortung schneiden.

Wann Microservices funktionieren können

Microservices können funktionieren.

Aber nicht, weil sie klein sind.

Sie funktionieren, wenn sie eine echte fachliche Grenze tragen.

Dazu gehören mindestens ein paar unbequeme Voraussetzungen:

Der fachliche Kontext ist klar.

Die Sprache innerhalb dieses Kontextes ist eindeutig.

Das Team besitzt nicht nur Endpunkte, sondern Verantwortung.

Datenhoheit ist geklärt.

API-Verträge folgen fachlichen Begriffen, nicht Tabellenstrukturen.

Die UI muss Bedeutung nicht aus technischen Resten rekonstruieren.

Tests prüfen nicht nur Responses, sondern relevante Nutzerflüsse und fachliche Regeln.

Deployment ist wirklich unabhängig.

Betrieb und Observability sind ernst genommen.

Fehlerverhalten ist nicht nur technisch, sondern nutzerzentriert verstanden.

Und vor allem:

Das Team kann Entscheidungen treffen, ohne bei jeder Änderung eine Prozession durch andere Teams starten zu müssen.

Microservices sind kein Architektur-Zauberstab.

Sie sind ein Verstärker.

Sie verstärken gute Grenzen.
Und sie verstärken schlechte Grenzen.

Bei guten Grenzen bringen sie Autonomie, Skalierbarkeit von Teams, klare Verantwortung und unabhängige Entwicklung.

Bei schlechten Grenzen bringen sie Latenz, Koordinationsaufwand, Monitoring-Schmerz, lokale Setup-Probleme und sehr viele Meetings mit dem Wort „Schnittstelle“.

Wann ein modularer Monolith besser ist

Die Alternative zu schlechten Microservices ist nicht automatisch SOA.

Und sie ist auch nicht automatisch ein großer Monolith, in dem alles wieder gemütlich zusammenklumpt wie Käsefondue mit Datenbankzugriff.

Die bessere Alternative ist ein bewusster Architekturentscheid.

Manchmal ist ein modularer Monolith sinnvoller.

Wenn das Team klein ist.
Wenn fachliche Grenzen noch unscharf sind.
Wenn Deployment-Komplexität keinen echten Nutzen bringt.
Wenn Betriebsreife fehlt.
Wenn Observability noch nicht ausreicht.
Wenn Datenhoheit noch nicht verstanden ist.
Wenn schnelle fachliche Lernzyklen wichtiger sind als technische Verteilung.

Ein modularer Monolith kann sehr sauber sein.

Er kann klare fachliche Module haben, stabile interne Grenzen, gute Tests, klare Sprache, sinnvolle ViewModels und eine Architektur, die spätere Extraktion ermöglicht.

Das ist oft besser als Microservices, die nur deshalb verteilt wurden, weil das Architekturdiagramm sonst nicht modern genug aussah.

Genauso können Self-contained Systems sinnvoll sein.

Oder eine event-driven Architektur.

Oder API-first.

Oder ein Integration Layer für Legacy-Anbindung.

Oder echte Microservices.

Oder eine fachlich modulare Architektur innerhalb eines Deployments.

Der Punkt ist nicht, ein Lieblingsmuster zu verteidigen.

Der Punkt ist, die Belastung zu verstehen.

Fachliche Grenze.
Teamstruktur.
Änderungsdruck.
Betriebsreife.
Datenhoheit.
Deployment-Anforderungen.
Testbarkeit.
Produktfluss.

Architektur ist keine Glaubensfrage.

Auch wenn manche Diskussionen erstaunlich nah an Religionskriege herankommen.

Falsch ist nicht Microservices

Microservices sind nicht grundsätzlich falsch.

SOA war nicht grundsätzlich falsch.

Monolithen sind nicht grundsätzlich falsch.

Falsch ist, technische Verteilung mit fachlicher Architektur zu verwechseln.

Falsch ist, Backend-Services zu schneiden und zu glauben, der Produktfluss werde sich schon irgendwie darüberlegen.

Falsch ist, die UI als Oberfläche zu behandeln, obwohl sie fachliche Bedeutung, Zustand und Nutzerentscheidungen modelliert.

Falsch ist, zentrale technische Modelle für Produktmodelle zu halten.

Falsch ist, Ownership an technischen Schichten statt an fachlichen Fähigkeiten auszurichten.

Falsch ist, Begriffe nicht ernst zu nehmen.

Denn irgendwann wird jede unklare Grenze sichtbar.

Oft im Frontend.
Oft im Test.
Oft im Betrieb.
Fast immer zu spät.

Merksatz

Die UI sitzt nicht oben drauf. Sie ist Teil des fachlichen Schnitts.

Microservices sind kein Backend-Konzept.

Wenn der Schnitt nicht bei Produkt, UX, Frontend, Backend, Tests und Betrieb trägt, ist er nicht fachlich.

Dann ist er nur verteilt.