Microservices vs. Monolith: Welche Architektur, und wann?

Ein Monolith ist eine einzige deploybare Anwendung; Microservices zerlegen sie in kleine, unabhängig deployte Dienste, die über APIs kommunizieren. Die Debatte klingt nach Architektur, ist aber vor allem eine Organisationsfrage: Entscheidend ist, ob Teamstruktur, Domänenwissen und operative Reife die Aufteilung tragen können – denn die Aufteilung stellt immer eine Rechnung.

Das Wichtigste in Kürze

Der Unterschied in einem Codebeispiel

Innerhalb eines Monolithen ist der Aufruf eines anderen Moduls ein Funktionsaufruf – schnell, atomar und ohne die Möglichkeit, halb zu scheitern:

// Monolith: Aufruf im Prozess – eine Transaktion, eine Fehlerdomäne
const receipt = await billing.chargeOrder(order.id);

// Microservices: Derselbe Aufruf geht übers Netzwerk – und nun gehören
// Timeouts, Retries, Teilausfälle und Eventual Consistency Ihnen
const res = await fetch('https://billing.internal/charge', {
  method: 'POST',
  body: JSON.stringify({ orderId: order.id }),
  signal: AbortSignal.timeout(3000),   // und wenn billing langsam ist?
});
if (!res.ok) await compensateOrder(order.id); // und wenn es halb geklappt hat?

Jeder Schmerzpunkt von Microservices steckt in diesen letzten drei Zeilen. Der verwaltete Mittelweg hält eigene Logik unabhängig deploybar, ohne Ihnen die Fehlerbehandlung aufzubürden – eine Funktion wird wie ein Dienst aufgerufen, läuft aber auf einer von der Plattform verwalteten Infrastruktur:

// JavaScript / Node.js — Back4app JS SDK
// One deployable unit of business logic, no service mesh required
const receipt = await Parse.Cloud.run('chargeOrder', { orderId: 'ord_481' });
console.log(`Charged: ${receipt.status}`);

// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('chargeOrder');
final response =
    await function.execute(parameters: {'orderId': 'ord_481'});
if (response.success) {
  print('Charged: ${response.result['status']}');
}

// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("chargeOrder",
                        parameters: ["orderId": "ord_481"]) { result in
  if case .success(let receipt) = result {
    print("Charged: \(receipt)")
  }
}

// Android / Kotlin — Back4app Android SDK
val params = hashMapOf("orderId" to "ord_481")
ParseCloud.callFunctionInBackground<Map<String, Any>>("chargeOrder", params) { receipt, e ->
  if (e == null) Log.d("Billing", "Charged: ${receipt["status"]}")
}

Drei Formen, nicht zwei

Der maßgebliche Microservices-Artikel beschreibt das Ziel, MonolithFirst den Weg dorthin: Fast jedes erfolgreiche Microservices-System begann als Monolith, der zu groß wurde, und der modulare Monolith hält Ihnen die Option offen – erst die Grenzen, später das Netzwerk, und nur dort, wo es sich lohnt.

Microservices vs. Monolith: die praktischen Unterschiede

Die schärfste Zeile dieser Tabelle ist die Frage, wo die Komplexität liegt: Ein aufgeteiltes System hat nicht weniger Komplexität – es verlagert sie aus der Codebasis ins Netzwerk, in die Deployment-Pipeline und auf das Dashboard um drei Uhr nachts.

Die Migration in beide Richtungen

Die bekannte Richtung: Eine große Video-Streaming-Plattform hat jahrelang ihren Monolithen in über tausend Dienste zerlegt und damit ein Skalierungsproblem gelöst, das sie tatsächlich hatte. Die Gegenrichtung ist neuer und ebenso lehrreich: Dieselbe Branche brachte einen Monitoring-Dienst hervor, der seine Serverless-Microservices wieder in einen einzigen Prozess zusammenführte und die Infrastrukturkosten um rund 90 % senkte – der Datentransfer zwischen den Teilen war der größte Kostenfaktor –, sowie Engineering-Teams, die mehr als hundert Dienste wieder zu einem konsolidierten, weil Testsuiten und Abhängigkeitsverwaltung nicht mehr beherrschbar waren. Beide Richtungen waren rational: Konstant ist, dass die Architektur dem gemessenen Problem folgte, nicht dem Trend.

Typische Anwendungsfälle

• Monolith: neue Produkte, kleine Teams, unklare Domänen – überall dort, wo Lerngeschwindigkeit wichtiger ist als Skalierungstheorie.
• Modularer Monolith: wachsende Produkte, die sich Optionen für später offenhalten wollen, ohne heute den Mehraufwand zu tragen; der Standard, den man verteidigen sollte.
• Microservices: viele Teams, die unabhängig ausliefern, Komponenten mit unterschiedlichem Skalierungsbedarf (Feed vs. Checkout), Organisationen, die schnelles Provisioning, Monitoring und Rufbereitschaft bereits beherrschen.
• Hybrid mit verwaltetem Backend: Standard-Features (Authentifizierung, Daten, Speicher) werden als Dienst bezogen, eigene Logik läuft als unabhängig deployte Funktionen – Autonomie wie bei Microservices zu Betriebskosten wie beim Monolithen.

Sollten Sie aufteilen? Eine Entscheidungsmatrix

Wenn die linke Spalte auf Sie zutrifft, die rechte Sie aber reizt, ist der modulare Monolith der ehrliche Kompromiss – und wenn Sie aufgeteilt haben und jede Änderung drei Dienste berührt, haben Sie den verteilten Monolithen gebaut und sollten ohne falsche Scham wieder zusammenführen.

Grenzen und Trade-offs

• Monolith: Der Release-Zug wird langsamer, je mehr Teams es gibt; ein einziges Speicherleck ist ein Ausfall für alle; über Jahre gewachsene Verflechtungen lassen sich kaum herauslösen, wenn die Moduldisziplin nachlässt.
• Microservices: die “MicroservicePremium” – verteilte Transaktionen, Behandlung von Netzwerkfehlern, versionierte APIs zwischen Ihren eigenen Teams und ein Observability-Stack, der zu einem eigenen Budgetposten wird.
• Beide: Keines der beiden Modelle rettet eine schlecht modellierte Domäne. Service-Grenzen auf einem schlechten Modell erzeugen eine verteilte Version desselben Durcheinanders – mit Latenz.
• Die organisatorische Grenze ist real: Nach dem Gesetz von Conway liefern Sie Ihre Kommunikationsstruktur aus. Wer die Architektur umbaut, ohne die Teams umzubauen, landet zuverlässig beim Anti-Pattern.

Microservices und Monolith mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Sie verschiebt die Bedingungen der Debatte: Die üblichen 80 % des Backends müssen Sie gar nicht selbst entwerfen, und die individuellen 20 % laufen als Cloud-Code-Funktionen – jede unabhängig deploybar wie ein Microservice, keine mit Service Mesh, Datenbank pro Dienst oder Ops-Rotation. Teams, denen selbst das zu eng wird, behalten den Ausweg: Der Stack ist Open Source, sodass das spätere Herauslösen eines echten Dienstes bei funktionierenden Grenzen beginnt, nicht bei einer Neuentwicklung.