Microservices vs. Monolith: Architektur-Grundlagen

Früher oder später stellst du dir bei einem größeren Projekt die Frage: Baue ich alles in eine große Anwendung oder zerlege ich es in viele kleine Dienste? Diese Entscheidung zwischen Monolith und Microservices prägt deine gesamte Architektur. In diesem Beitrag erkläre ich dir die Unterschiede, Vor- und Nachteile und wann sich welcher Ansatz lohnt.

Der Monolith

Ein Monolith ist eine einzige, zusammenhängende Anwendung. Alle Funktionen, von der Benutzerverwaltung über die Produktlogik bis zur Bezahlung, leben im selben Codebestand und laufen als ein Prozess.

// Alles in einer Anwendung
const express = require("express");
const app = express();

app.use("/users", userRouter);
app.use("/produkte", produktRouter);
app.use("/bezahlung", bezahlRouter);

app.listen(3000);

Der große Vorteil: Alles ist an einem Ort, einfach zu starten, zu testen und zu deployen. Gerade am Anfang eines Projekts ist das oft die schnellste und sinnvollste Lösung.

Microservices

Bei Microservices zerlegst du die Anwendung in viele kleine, eigenständige Dienste. Jeder Dienst kümmert sich um einen klar abgegrenzten Bereich und läuft als eigener Prozess, oft mit eigener Datenbank.

# Jeder Dienst laeuft eigenstaendig
user-service       -> Port 3001
produkt-service    -> Port 3002
bezahl-service     -> Port 3003

Die Dienste kommunizieren über das Netzwerk, typischerweise per HTTP-API oder über einen Message-Broker. Jeder Service kann unabhängig entwickelt, getestet und ausgerollt werden.

Kommunikation zwischen Diensten

Im Monolith ruft eine Funktion einfach eine andere auf. Bei Microservices wird daraus ein Netzwerkaufruf, etwa per HTTP:

// Der Bezahl-Service fragt den Produkt-Service nach dem Preis
async function holePreis(produktId) {
  const antwort = await fetch(
    `http://produkt-service:3002/produkte/${produktId}`
  );
  const produkt = await antwort.json();
  return produkt.preis;
}

Das bringt Flexibilität, aber auch neue Herausforderungen: Netzwerkfehler, Latenz und die Frage, was passiert, wenn ein Dienst gerade nicht erreichbar ist.

Vor- und Nachteile im Überblick

Beide Ansätze haben klare Stärken und Schwächen. Der Monolith punktet mit:

• einfachem Aufsetzen und Deployen,
• direkten Funktionsaufrufen ohne Netzwerk,
• leichterem Debuggen, da alles an einem Ort liegt.

Microservices bieten dafür:

• unabhängiges Skalieren einzelner Dienste,
• getrennte Deployments ohne Risiko für die ganze App,
• die Freiheit, je Dienst andere Technologien zu wählen.

Wann welcher Ansatz?

Eine bewährte Faustregel lautet: Starte mit einem Monolithen. Solange dein Team klein und die Anwendung überschaubar ist, ist der Monolith fast immer die produktivere Wahl. Du vermeidest den Verwaltungsaufwand vieler Dienste und kannst dich auf die Funktionen konzentrieren.

Microservices lohnen sich, wenn:

• große Teams unabhängig an verschiedenen Bereichen arbeiten,
• einzelne Teile sehr unterschiedlich skaliert werden müssen,
• der Monolith zu groß und schwer wartbar geworden ist.

Viele erfolgreiche Systeme beginnen als Monolith und werden erst später, bei Bedarf, in Microservices aufgeteilt.

Fazit

Die Wahl zwischen Monolith und Microservices ist keine Glaubensfrage, sondern hängt von Teamgröße, Skalierungsbedarf und Komplexität ab. Für die meisten Projekte ist der Monolith der richtige Startpunkt, weil er einfach und schnell ist. Microservices sind ein mächtiges Werkzeug, das aber auch Aufwand mitbringt. Entscheide dich bewusst und nicht aus Mode heraus, dann triffst du die richtige Wahl für dein Projekt.