Microservices-Architektur

Microservices sind kein Upgrade eines Monolithen; sie sind ein Tauschgeschäft. Sie tauschen Kopplung zur Compile-Zeit gegen Netzwerkaufrufe, ein Deployment gegen Dutzende und eine einzelne Datenbank gegen verteilte Datenhoheit. Dieser Tausch zahlt sich unter bestimmten Umständen aus und kostet überall sonst teuer. Nach einem Jahrzehnt Branchenerfahrung — inklusive des aktuellen Gegentrends, bei dem Teams ihre Services wieder zu weniger Deployables konsolidieren — lautet die ehrliche Frage im Jahr 2026 nicht „Wie führen wir Microservices ein?“, sondern „Was würde sie für uns lohnenswert machen?“

Was Microservices Ihnen tatsächlich einbringen

Die Aufteilung einer Anwendung in unabhängig deploybare Services bringt vier Dinge: unabhängige Deploybarkeit (Team A liefert aus, ohne auf Team B zu warten), unabhängige Skalierung (der Medienverarbeitungs-Service läuft mit vierzig Replicas, während das Billing mit zweien vor sich hin idlet), Technologieentscheidungen pro Service und Fehlereingrenzung — mit einem wichtigen Vorbehalt weiter unten. Beachten Sie: Jeder einzelne dieser Vorteile betrifft organisatorische und betriebliche Unabhängigkeit, nicht rohe Performance. Ein Netzwerk-Hop ist immer langsamer und weniger zuverlässig als ein Funktionsaufruf.

Wann Microservices ihre Kosten rechtfertigen

• Zu viele Teams in einer Codebasis. Deploy-Warteschlangen, Release Trains und ständige Merge-Konflikte sind das klassische Signal. Conways Gesetz ist real: Service-Grenzen funktionieren am besten, wenn sie Team-Grenzen widerspiegeln — weshalb Microservices oft eher ein organisatorisches Werkzeug sind als ein technisches.
• Wirklich unterschiedliche Skalierungs- oder Verfügbarkeitsprofile. Eine Komponente braucht GPU-Nodes und schnellt auf das Hundertfache des Traffics hoch; der Rest nicht.
• Isolationsanforderungen. PCI- oder regulierte Datenverarbeitung in einem kleinen, auditierbaren Service zu halten, verkleinert den Compliance-Scope.
• Eine stabile, gut verstandene Domäne. Service-Grenzen zu verschieben ist teuer. Wenn sich das Domänenmodell noch bewegt, ist es zu früh, Grenzen in Netzwerkverträgen einzufrieren.

Trifft nichts davon zu — ein kleines Team, ein sich entwickelndes Produkt, gewöhnliche CRUD-Workloads —, übernehmen Sie sämtliche Kosten und erhalten keinen der Vorteile. Wir haben dokumentiert, wie das ausgeht, wenn ein winziges Team ein Dutzend Services für eine CRUD-Anwendung betreibt.

Die meisten Teams sollten mit einem modularen Monolithen starten

Für die meisten Teams ist der richtige Ausgangspunkt ein modularer Monolith: ein Deployable, strikte Modulgrenzen, ein eigenes Schema pro Modul und Kommunikation über explizite In-Process-Schnittstellen. Sie bekommen die Designdisziplin von Microservices — Bounded Contexts, klare Verträge, eigene Daten — ohne die Steuer der verteilten Systeme. Braucht ein Modul später eine eigene Skalierungskurve oder einen eigenen Release-Rhythmus, existiert die Naht bereits, und die Extraktion ist überwiegend mechanisch. Zu splitten, bevor sich die Grenzen gesetzt haben, ist der Weg zum verteilten Monolithen — und das zu schnelle Zerlegen des Monolithen ist eine der häufigsten Misserfolgsgeschichten, die wir sehen.

Zerlegungsstrategien

Zerlegen Sie entlang von Geschäftsfähigkeiten, nicht entlang technischer Schichten oder Datenbank-Entities. Die Bounded Contexts des Domain-Driven Design sind das praktische Werkzeug: Ein Service sollte eine Fähigkeit Ende-zu-Ende besitzen (Pricing, Fulfilment, Identity), sodass die meisten Änderungen in einem einzigen Service landen. Vermeiden Sie Entity-basierte Aufteilungen — ein „User Service“ und ein „Order Service“, die sich bei jedem Request synchron gegenseitig aufrufen müssen, haben die Kopplung lediglich ins Netzwerk verlagert. Für Bestandssysteme funktioniert das Strangler-Fig-Muster: Setzen Sie ein Gateway vor den Monolithen und lösen Sie Fähigkeiten schrittweise heraus, wobei Sie den Monolith-Code stilllegen, sobald eine Fähigkeit umgezogen ist.

Datenhoheit und verteilte Transaktionen

Jeder Service besitzt seinen eigenen Datenspeicher; kein anderer Service liest oder schreibt ihn direkt. Eine gemeinsame Datenbank macht aus „Microservices“ einen verteilten Monolithen. Der Preis dieser Regel: Serviceübergreifende Konsistenz wird zu expliziter Arbeit. Verteilte Transaktionen werden mit dem Saga-Muster abgewickelt — einer Folge lokaler Transaktionen mit kompensierenden Aktionen im Fehlerfall —, und zuverlässiges Event-Publishing nutzt das Transactional-Outbox-Muster. Akzeptieren Sie Eventual Consistency, wo das Geschäft es erlaubt. Wenn ein Kern-Workflow tatsächlich ACID-Garantien über drei Services hinweg braucht, ist das meist der Beweis, dass die Grenzen falsch gezogen sind — nicht, dass Sie ein Two-Phase-Commit brauchen.

Fehlerisolation wird designt, sie gibt es nicht gratis

Ein ausfallender Service lässt den Rest des Systems nicht automatisch unberührt. Kaskadierende Ausfälle gehören zu den bestdokumentierten Microservices-Fehlermodi: Eine langsame Downstream-Abhängigkeit füllt die Connection Pools und Thread Pools der Upstream-Services, bis die gesamte Plattform stillsteht. Isolation muss konstruiert werden — Timeouts auf jedem Remote-Aufruf, Circuit Breaker, Bulkheads, Load Shedding und Graceful Degradation — und anschließend mit Fault-Injection-Tests verifiziert werden. Jede Behauptung, Microservices verschafften Ihnen Resilienz von Haus aus, sollten Sie als Warnsignal werten.

Betriebliche Voraussetzungen

Bevor der erste Service extrahiert wird, muss die Plattformarbeit stehen: automatisierte CI/CD pro Service; zentralisierte Observability mit OpenTelemetry-Traces, Prometheus-Metriken und aggregierten Logs (einen Request ohne Distributed Tracing über zehn Services hinweg zu debuggen ist Rätselraten); ein API-Gateway; Service-zu-Service-Authentifizierung (mTLS oder ein Service Mesh, sobald die Service-Anzahl dessen Overhead rechtfertigt) und eine On-Call-Rotation, die auf Teilausfälle vorbereitet ist. Unsere DevOps-Beratungspraxis behandelt dies als Eintrittskriterien einer Microservices-Migration, nicht als Nacharbeit.

Das Fazit

Microservices sind eher ein Werkzeug, um Organisationen zu skalieren, als um Software zu skalieren. Führen Sie sie ein, wenn der dominierende Schmerz die Koordination zwischen vielen Teams ist und das operative Fundament steht. Bis dahin liefert ein gut modularisierter Monolith schneller aus, kostet im Betrieb weniger und hält jede Option offen.

Sie betreiben so etwas in Produktion? Unser AWS Managed Services-Team betreibt solche Umgebungen rund um die Uhr — Monitoring, Incident Response, Patching und Kostenkontrolle durch namentlich benannte Senior Engineers, ab €3.000/Monat.