Microservices gelten seit Jahren als Goldstandard moderner Softwarearchitektur. In Konferenzvorträgen, Blogposts und Stellenanzeigen wird die Architektur als Zeichen technischer Reife dargestellt. Die Realität ist differenzierter. Viele Teams setzen Microservices ein, ohne dass die Rahmenbedingungen dafür gegeben sind. Heraus kommt nicht bessere Architektur, sondern mehr Komplexität ohne entsprechenden Gegenwert.

Drei Szenarien, die Microservices rechtfertigen

Aus der Erfahrung mit Projekten unterschiedlicher Größenordnung lassen sich drei Szenarien identifizieren, in denen Microservices ihre Stärken tatsächlich ausspielen:

Mehrere Teams arbeiten am selben Produkt: Wenn fünf oder mehr Teams gleichzeitig an einer Anwendung entwickeln, brauchen sie unabhängige Deployment-Zyklen. Ein Team muss seinen Service deployen können, ohne auf das Deployment der anderen warten zu müssen. Microservices ermöglichen das, weil jeder Service seinen eigenen Build- und Release-Prozess hat. Bei zwei bis drei Teams, die eng zusammenarbeiten, lässt sich das auch innerhalb eines Monolithen organisieren. Aber ab einer bestimmten Teamgröße wird die Koordination zum Bottleneck, und separate Services sind die logische Antwort.

Einzelne Komponenten müssen gezielt skaliert werden: Wenn der Bestellprozess hundertmal mehr Last verarbeitet als die Benutzerverwaltung, ist es sinnvoll, beide Komponenten unabhängig skalieren zu können. In einem Monolithen skaliert man immer die gesamte Anwendung, auch die Teile, die gar keine zusätzliche Kapazität brauchen. Microservices erlauben gezielte Skalierung, allerdings nur, wenn die Lastverteilung tatsächlich so ungleichmäßig ist, dass sich der zusätzliche Infrastrukturaufwand lohnt.

Unterschiedliche Technologien sind fachlich begründet: Wenn ein Teil der Anwendung Python für Machine Learning benötigt und ein anderer Java für Transaktionsverarbeitung, können Microservices die technologische Heterogenität sauber kapseln. In der Praxis ist dieser Fall seltener als oft angenommen. Die meisten Anwendungen kommen mit einem Tech-Stack aus.

In den meisten Projekten trifft keiner dieser drei Punkte zu. Die Teamgröße liegt bei 5 bis 15 Entwicklern, die Lastverteilung ist gleichmäßig, und der Tech-Stack ist homogen. Trotzdem entscheiden sich viele Teams für Microservices.

Die tatsächlichen Kosten

Wer Microservices ohne triftigen Grund einführt, bekommt keine bessere Architektur. Die Kosten fallen in vier Bereichen an.

Schnittstellenkomplexität: Jeder Service kommuniziert mit anderen Services über das Netzwerk. Jede Netzwerkkommunikation ist eine potenzielle Fehlerquelle: Verzögerungen, Ausfälle, Wiederholungslogik. In einer einzelnen Anwendung sind interne Aufrufe praktisch fehlerfrei. In einer verteilten Architektur muss für jede Kommunikation eine eigene Fehlerbehandlung existieren. Bei 20 Services mit gegenseitigen Abhängigkeiten multipliziert sich dieser Aufwand erheblich.

Fehlersuche in verteilten Systemen: Wenn ein Request durch fünf Services läuft und irgendwo ein Fehler auftritt, ist die Lokalisierung deutlich aufwändiger als in einem Monolithen. Spezialisierte Überwachungswerkzeuge für jeden einzelnen Service werden notwendig: zentrale Protokollierung, Nachverfolgung von Anfragen über mehrere Systeme hinweg, Monitoring. Diese Werkzeuge müssen eingerichtet, gewartet und vom Team beherrscht werden. In einer einzelnen Anwendung lässt sich ein Fehler in einer einzigen Protokolldatei nachvollziehen.

Deployment- und Infrastrukturaufwand: Statt einer Anwendung deployt man zwanzig. Jede mit eigener CI/CD-Pipeline, eigenem Health-Check, eigener Konfiguration. Container-Orchestrierung, Netzwerk-Management, Versionsverwaltung der einzelnen Dienste: Die Infrastrukturschicht, die für den Betrieb einer Microservice-Architektur nötig ist, erfordert eigenes Know-how und eigene Kapazität. In kleineren Teams bedeutet das, dass ein relevanter Anteil der Arbeitszeit in Infrastruktur fließt statt in fachliche Entwicklung.

Daten-Konsistenz: In einem Monolithen mit einer Datenbank ist eine Transaktion über mehrere Tabellen eine Standardoperation. In einer Microservice-Architektur, in der jeder Service seine eigene Datenbank hat, wird die gleiche Operation zu einer verteilten Transaktion. Die Lösungen dafür existieren, sind aber deutlich aufwändiger umzusetzen und zu testen als eine einfache Datenbanktransaktion in einer einzelnen Anwendung.

Die Alternative: der modulare Monolith

Ein strukturierter modularer Monolith kombiniert die Vorteile klarer Modulgrenzen mit der Einfachheit eines einzelnen Deployments. Jedes Modul hat definierte Schnittstellen und eigene Verantwortlichkeiten. Aber alles läuft in einem Prozess, mit einer Datenbank, einem Deployment, einem Logging-System.

Der entscheidende Vorteil zeigt sich später. Wenn der Tag kommt, an dem ein Modul tatsächlich als eigenständiger Service laufen muss, weil beispielsweise ein zweites Team daran arbeiten soll oder die Last gezielt skaliert werden muss, ist der Schnitt sauber vorbereitet. Die Modulgrenzen sind definiert, die Schnittstellen klar. Die Extraktion ist ein geplanter Schritt, kein Umbau unter Zeitdruck.

Dieser Ansatz folgt dem Prinzip, Architekturentscheidungen so spät wie möglich zu treffen, nicht so früh wie möglich. Wer zu früh auf Microservices setzt, löst Probleme, die noch gar nicht existieren, und schafft neue, die sofort da sind.

Die richtige Frage stellen

Bevor eine Architekturentscheidung Richtung Microservices fällt, lohnt sich eine ehrliche Bestandsaufnahme: Folgt die Entscheidung einem konkreten technischen Bedarf? Oder folgt sie dem, was Amazon, Netflix und Google machen?

Diese Unternehmen haben Microservices, weil sie tausende Entwickler beschäftigen und Millionen von Nutzern gleichzeitig bedienen. Wenn das eigene Team aus 5 bis 15 Entwicklern besteht und die Anwendung einige hundert gleichzeitige Nutzer hat, ist die Ausgangslage fundamental anders. Architekturentscheidungen sollten sich an den eigenen Rahmenbedingungen orientieren, nicht an denen von Big-Tech-Unternehmen.

Fazit

Microservices sind ein mächtiges Architekturwerkzeug für die Szenarien, in denen sie berechtigt sind: große Teams, ungleichmäßige Lastverteilung, heterogene Technologieanforderungen. Für die Mehrheit der Projekte erzeugen sie mehr Komplexität als Nutzen. Ein modularer Monolith bietet in diesen Fällen die gleiche Flexibilität bei deutlich geringerem Betriebsaufwand. Die beste Architekturentscheidung ist nicht die modernste, sondern die, die zu den tatsächlichen Anforderungen passt.