In der modernen Softwareentwicklung gelten Mikroservices oft als Königsweg für skalierbare und wartbare Systeme. Doch hinter der glänzenden Fassade lauern zahlreiche Fallstricke, die Teams teuer zu stehen kommen können. Dieser Artikel beleuchtet fünf typische Fehler aus realen Projekten und zeigt, wie sie sich vermeiden lassen.

Warum wir Mikroservices wirklich einführen

Die offiziellen Gründe klingen überzeugend: geringere Kopplung, unabhängige Bereitstellungen, flexible Skalierung. In der Praxis stecken jedoch häufig andere Motive dahinter:

1. Modernität – Wer möchte schon mit einem "veralteten" Monolithen arbeiten?
2. Karriere-Sicherheit – Kaum jemand wird kritisiert, wenn er oder sie auf das vermeintlich zukunftssichere Paradigma setzt.
3. Reiz der Komplexität – Technische Raffinesse wird mit unternehmerischem Mehrwert verwechselt.

Wichtig ist die Erkenntnis: Ein gut strukturierter Monolith ist nicht grundsätzlich schlechter als eine Service-Landschaft. Entscheidend bleibt, wie gut die gewählte Architektur zu Domäne, Team und Entwicklungsplan passt.

Vom Monolithen zum verteilten System – das Strangler-Fig-Muster

Ein häufig empfohlener Migrationspfad ist das Strangler-Fig-Muster (benannt nach einer Würgefeigenart): bestehende Funktionen werden Stück für Stück aus dem Monolithen herausgelöst und in eigenständige Services überführt. Das kann funktionieren, bringt aber neue Performance- und Betriebsrisiken mit sich.

Versteckte Performancekosten verteilter Systeme

• Netzwerklatenz (Verzögerungszeit) und Datenserialisierung (Umwandlung von Objekten in übertragbare Formate) addieren sich schnell zu mehreren Millisekunden pro Aufruf.
• TLS-Terminations (Verschlüsselungsendpunkte), Proxies (Vermittlungsdienste) und Retries (Wiederholungsversuche) erhöhen den Durchsatz nicht, sondern das Gegenteil.
• In Laufzeitumgebungen wie .NET oder JVM läuft die Garbage Collection (automatische Speicherbereinigung, ab .NET 4.5 teilweise nebenläufig), es bleibt aber eine vollständige Pausierungsphase (Global-Stop-Phase); mehrere kleine Prozesse können daher häufiger Speicherbereinigungszyklen auslösen als ein einzelner großer Prozess.

Fazit: Verteilung ist kein Ersatz für systematische Performance-Optimierung. Wer Services ohne Leistungsmessung zerschneidet, tauscht Prozessorgrenzen gegen Netzwerkengpässe.

Fehler 1 – Netzwerkaufrufe ohne Rücksicht auf Verzögerungszeit

Der Kardinalfehler besteht darin, jede Funktionalität über synchrone HTTP-Anfragen oder Remote Procedure Calls (RPC) aufzurufen. Erinnerungen an die WCF-Ära (Windows Communication Foundation) sind fehl am Platz – entscheidend ist, Granularität (Detaillierungsgrad) und Kommunikationsmodell bewusst zu wählen:

• Grobkörnige Schnittstellen (Coarse-grained APIs) statt kommunikationsintensiver Dienste (Chatty Services)
• Asynchrone Kommunikation (z.B. Messaging, gRPC Streams) dort, wo Antwortzeiten nicht kritisch sind
• Massen- bzw. Stapeloperationen (Bulk-/Batch-Operationen), um Kommunikationsrundläufe zu reduzieren

Die Illusion der kompletten Neuentwicklung

Wenn die Service-Landschaft unübersichtlich wird, klingt das Versprechen, "alles neu und besser" zu machen, verführerisch.

Warum komplette Neuentwicklungen (Big-Bang-Rewrites) selten gelingen

• Komplexität unterschätzt: Die sichtbare Funktionalität bildet nur einen Teil der Geschäftsregeln ab.
• Doppelte Arbeit: Neue Funktionen müssen in beiden Systemen gepflegt werden, bis die Ablösung gelingt.
• Verzögerte Wertschöpfung: Kundinnen und Kunden erhalten über Monate keinerlei Mehrwert.

Erfolgreiche Komplett-Neubauten sind die Ausnahme – meist sind sie durch extrem fokussierte Anforderungen oder sehr kleine Fachbereiche motiviert.

Fehler 2 – Die unkritische komplette Neuentwicklung

Eine komplette Neuentwicklung kann klappen, wenn

1. das bestehende System überschaubar klein ist und
2. ein messbarer Geschäftsvorteil entsteht, der die Übergangszeit kompensiert.

Andernfalls ist eine schrittweise Modernisierung (Strangler-Fig, modulare Neustrukturierung) fast immer die risikoärmere Option.

Infrastruktur neu erfinden – das "Not-Invented-Here"-Syndrom

Um Verzögerungsprobleme zu lindern, greifen Teams oft zu Nachrichtenwarteschlangen (Message Queues). Wenn erste Fehlermeldungen auftreten, entwickeln sie eigene Wiederholungsmechanismen (Retry-Mechanismen), Warteschlangen für fehlgeschlagene Nachrichten (Dead-Letter-Queues) oder Schutzschalter (Circuit Breaker) – obwohl Bibliotheken wie Polly, Frameworks wie NServiceBus oder Rebus diese Szenarien längst adressieren.

Fehler 3 – Das NIH-Syndrom (Not-Invented-Here)

Selbstgebaute Infrastruktur

• bindet Fachkräfte an grundlegende technische Probleme (Low-Level-Probleme),
• erreicht selten denselben Reifegrad wie Open-Source-Alternativen,
• verschiebt die Verantwortung für Sicherheit und Beobachtbarkeit (Security & Observability) komplett auf das Team.

Tipp: Prüfen Sie zuerst bewährte Lösungen und investieren Sie nur dort in Eigenentwicklungen, wo echte Alleinstellungsmerkmale entstehen.

Grenzen falsch gezogen – Fachbereich vs. Datenmodell

Eine Produktsuche braucht Daten aus Produkt-, Bestell- und Kundendomäne. Werden Services nach Entitäten ("Produkt", "Kunde") statt nach abgegrenzten Kontexten (Bounded Contexts) geschnitten, entstehen Abhängigkeitsketten.

Fehler 4 – Grenzen am Datenmodell ausrichten

Domain-Driven Design empfiehlt, Services entlang ihrer geschäftlichen Verantwortung (Kontext) zu schneiden. Typischerweise fallen dabei Substantive an (Katalog, Checkout, Abrechnung). Entscheidend ist,

• wer die verantwortlichen Teams (Owner-Teams) sind und
• welche Geschäftsereignisse zwischen Kontexten fließen.

Grenzen ausschließlich nach "Verben" (Suchen, Bezahlen) zu ziehen, führt häufig zu orchestrierenden Prozess-Services ohne klare Datenhoheit.

Physische ≠ logische Entkopplung

Mehr Bereitstellungen bedeuten nicht automatisch mehr Autonomie. Wenn zwei Services dieselbe Geschäftsregel ändern müssen, sind sie logisch gekoppelt – egal, ob sie in getrennten Containern laufen.

Fehler 5 – Verwechslung physischer und logischer Grenzen

• Datenkopien (durch Ereignisse übertragene Zustände, Event-Carried State Transfer) entkoppeln Lesepfade, nicht Geschäftsregeln.
• API-Versionen lösen technische, nicht fachliche Kopplung.

Der Schlüssel liegt in klarer Verantwortungsverteilung und Ereigniskonsistenz (z.B. transaktionssichere Ausgangsbox-Muster, Outbox-Pattern).

Eine mögliche Ergänzung – das Engine-Muster (mit Vor- und Nachteilen)

Beim Engine-Muster stellt ein Service ("Engine") eine Erweiterungsschnittstelle (Plug-in-Schnittstelle) bereit; andere Teams liefern Programmmodule (Assemblies) oder Pakete, die in den Hauptdienst (Host) eingebunden werden. Das verringert Netzwerk-Verzögerungen, erhöht aber

• die technische Abhängigkeit (Lock-in) von einer Laufzeitumgebung,
• das Risiko eines zentralen Ausfallpunkts (Single-Point-of-Failure) und
• den Koordinationsaufwand bei schrittweisen Aktualisierungen (rollierende Updates).

Empfehlung: Nur einsetzen, wenn sehr niedrige Verzögerungszeit das dominierende Ziel ist und alle Beteiligten dieselbe Technologie-Plattform teilen.

Leitlinien für erfolgreiche Mikroservices

1. Geschäftlichen Nutzen reflektieren: Mikroservices sind Mittel zum Zweck, kein Selbstzweck.
2. Verzögerungszeit bewusst managen: Leistungsmessungen vor jedem Schnitt, nicht danach.
3. Schrittweise migrieren: Strangler-Fig oder modulare Erweiterung schlägt komplette Neuentwicklung.
4. Erprobte Frameworks nutzen: Neuerfindung des Rades vermeiden, Sicherheit & Beobachtbarkeit inklusive.
5. Service-Grenzen entlang der Fachdomäne: Abgegrenzte Kontexte > Entitäten > einzelne Anwendungsfälle.
6. Logische & physische Entkopplung unterscheiden: Autonomie entsteht durch klare Verantwortlichkeit und Ereignisse, nicht durch Container-Grenzen.

Häufig gestellte Fragen

Sind Monolithen wirklich so schlecht, wie oft behauptet wird?

Nein. Ein gut modularisierter Monolith kann – besonders in frühen Produktphasen – die geringsten Betriebskosten aufweisen. Entscheidend ist die Passung zur Team- und Produktgröße.

Wann ist der richtige Zeitpunkt, von einem Monolithen zu Mikroservices zu wechseln?

Sobald unterschiedliche Teile des Systems unabhängig skalieren oder verschiedene Teams eigenverantwortlich Bereitstellungen durchführen müssen. Vermeiden Sie Migration nur aus Trend-Gründen.

Wie finde ich die richtigen Service-Grenzen?

Nutzen Sie Domain-Driven-Design: identifizieren Sie abgegrenzte Kontexte (Bounded Contexts), formulieren Sie eine einheitliche Sprache (Ubiquitous Language) und modellieren Sie Geschäftsereignisse. Grenzen müssen die Realität der Organisation abbilden – nicht das Entitäten-Beziehungs-Diagramm.