Microservices sind seit Jahren der Architektur-Trend schlechthin. Und ja — für die richtige Problemstellung sind sie hervorragend. Aber die Realität zeigt: Viele Teams führen Microservices ein, ohne die Voraussetzungen dafür zu haben.

Das Ergebnis ist kein verteiltes System — sondern ein verteilter Monolith: alle Nachteile beider Welten, keine der Vorteile.

Wann Microservices Sinn machen

Microservices lösen organisatorische Probleme, nicht primär technische:

– Mehrere Teams arbeiten unabhängig an verschiedenen Geschäftsbereichen
– Unterschiedliche Release-Zyklen pro Domäne sind notwendig
– Unterschiedliche Skalierungsanforderungen pro Service
– Technologievielfalt ist gewünscht (ein Service in Java, ein anderer in Python)

Wenn Ihr Team aus 3–5 Entwicklern besteht und eine Anwendung betreut: Microservices sind sehr wahrscheinlich der falsche Ansatz.

Der gut strukturierte Monolith

Ein Monolith ist kein Anti-Pattern. Ein schlecht strukturierter Monolith ist das Problem. Die Lösung ist nicht automatisch eine Microservice-Architektur, sondern oft ein Modularer Monolith:

– Klare Modul-Grenzen mit definierten APIs
– Eigene Datenhaltung pro Modul (kein Shared Database)
– Module können unabhängig getestet werden
– Spätere Extraktion in Services ist möglich, wenn nötig

Das Beste aus beiden Welten

Monolith mit klaren Modulen
┌──────────────────────────────────┐
│  ┌──────────┐  ┌──────────┐     │
│  │  Bestell- │  │  Kunden- │     │
│  │  wesen    │  │  verw.   │     │
│  │           │  │          │     │
│  └────┬──────┘  └────┬─────┘    │
│       │  definierte   │          │
│       │  Schnittstelle│          │
│  ┌────┴──────┐  ┌────┴─────┐    │
│  │  Lager    │  │  Billing │    │
│  └───────────┘  └──────────┘    │
│                 Ein Deployment   │
└──────────────────────────────────┘

Die Kosten von Microservices

Was selten erwähnt wird — Microservices erfordern erhebliche Infrastruktur:

Wenn Sie diese Infrastruktur nicht haben oder nicht betreiben können, werden Microservices zum Bremsklotz statt zum Beschleuniger.

Entscheidungshilfe

Starten Sie mit einem Monolith, wenn:
– Ein Team, ein Produkt
– Domäne noch nicht vollständig verstanden
– Schnelle Time-to-Market wichtiger als Skalierbarkeit

Wechseln Sie zu Microservices, wenn:
– Team-Autonomie das Hauptziel ist
– Einzelne Domänen unabhängig skaliert werden müssen
– Sie die Infrastruktur betreiben können (oder wollen)

Fazit

Die beste Architektur ist die, die Ihr Team produktiv macht. Für die meisten mittelständischen Unternehmen ist ein modularer Monolith der pragmatischere Weg — mit der Option, gezielt Services zu extrahieren, wenn der Bedarf entsteht.

Bei CGS IT Solutions beraten wir technologieneutral: Wir empfehlen die Architektur, die zu Ihrer Organisation passt — nicht die, die gerade im Trend liegt. Mehr dazu unter Software Architektur.

Der Beitrag Microservices oder Monolith? Die ehrliche Antwort erschien zuerst auf CGS IT Solutions GmbH.