Microservices oder Monolith: die richtige SaaS-Architektur

Kurz gefasst: Für die meisten SaaS-Produkte ist ein gut strukturierter, modularer Monolith der richtige Start: eine Anwendung, ein Deployment, eine Datenbank, aber mit klaren Grenzen zwischen den fachlichen Modulen. Microservices lohnen sich, wenn mehrere Teams unabhängig voneinander ausliefern müssen oder einzelne Teile ganz andere Anforderungen an Skalierung, Technik oder Verfügbarkeit haben. Wer sauber modularisiert, kann einzelne Module später gezielt herauslösen.

Was die beiden Ansätze unterscheidet

Ein Monolith ist eine Anwendung, die als Ganzes gebaut, getestet und ausgeliefert wird. Alle Funktionen teilen sich einen Prozess und meist eine Datenbank. Aufrufe zwischen Modulen sind einfache Funktionsaufrufe.

Bei Microservices ist das System in eigenständige Dienste aufgeteilt, die jeweils eigene Daten verwalten und über das Netzwerk kommunizieren, etwa per HTTP-API oder Nachrichtenwarteschlange. Jeder Dienst kann unabhängig deployt und skaliert werden.

Die Entscheidung betrifft dabei vor allem die Organisation: Microservices verschieben Komplexität aus dem Code in den Betrieb.

Was Microservices wirklich kosten

Verteilte Systeme sind schwer

Netzwerkaufrufe können fehlschlagen, langsam sein oder doppelt ankommen. Jeder Dienst braucht Wiederholungslogik, Timeouts und eine Strategie für Teilausfälle. Daten, die früher in einer Transaktion geschrieben wurden, verteilen sich auf mehrere Datenbanken. Konsistenz muss dann über Muster wie Sagas oder Outbox-Tabellen hergestellt werden.

Betrieb und Beobachtbarkeit

Statt einer Anwendung betreiben Sie viele. Jede braucht Deployment-Pipeline, Logging, Metriken und Alarme. Um einen Fehler über mehrere Dienste zu verfolgen, ist verteiltes Tracing nötig, etwa mit OpenTelemetry. Wie man das aufsetzt, beschreiben wir im Artikel zu Monitoring und Observability.

Entwicklungsgeschwindigkeit am Anfang

Eine neue Funktion, die drei Dienste berührt, erfordert drei abgestimmte Änderungen, Versionierung von Schnittstellen und koordinierte Releases. Für ein kleines Team, das noch nach Product-Market-Fit sucht, ist das ein spürbarer Bremsklotz.

Der modulare Monolith als Mittelweg

Ein modularer Monolith wird als eine Anwendung ausgeliefert, ist intern aber in klar getrennte Module gegliedert, etwa Abrechnung, Benutzerverwaltung, Berichte. Jedes Modul hat eine definierte Schnittstelle, und andere Module greifen nicht direkt auf seine Tabellen oder internen Klassen zu.

Diese Disziplin bringt viele Vorteile von Microservices, ohne deren Betriebsaufwand. Teams können an getrennten Modulen arbeiten, Grenzen bleiben sichtbar, und Abhängigkeiten lassen sich mit Werkzeugen prüfen. In TypeScript-Projekten hilft ein Monorepo mit getrennten Paketen; mehr dazu in unserem Beitrag zu Monorepos mit Turborepo.

Weitere Grundsatzentscheidungen, die sich später kaum rückgängig machen lassen, etwa Mandantenfähigkeit und Datenmodell, behandeln wir im Artikel zur Architektur von SaaS-Produkten.

Wann es Zeit ist, aufzuteilen

Es gibt einige klare Signale, dass sich das Herauslösen eines Dienstes lohnt:

• Mehrere Teams blockieren sich regelmäßig gegenseitig bei Releases.
• Ein Teil des Systems hat eine völlig andere Last als der Rest, etwa Bild- oder Videoverarbeitung, und soll unabhängig skalieren.
• Ein Modul braucht eine andere Technologie, zum Beispiel Python für Machine Learning neben einem Node.js-Backend.
• Ein Bereich hat strengere Anforderungen an Verfügbarkeit oder Sicherheit und soll isoliert laufen.

Wenn keines davon zutrifft, ist die Aufteilung meist verfrüht. Lösen Sie dann zuerst das Modul heraus, das den größten Schmerz verursacht, und nicht alles auf einmal. Für Hintergrundaufgaben mit schwankender Last kann auch eine Serverless-Architektur eine leichtere Alternative zum vollwertigen Dienst sein.

Häufige Fragen (FAQ)

Skaliert ein Monolith überhaupt?

Ja, deutlich weiter, als viele annehmen. Ein Monolith lässt sich horizontal skalieren, indem mehrere Instanzen hinter einem Load Balancer laufen. Engpässe liegen meist in der Datenbank, und die haben Microservices genauso.

Ist ein Wechsel vom Monolithen zu Microservices später teuer?

Bei einem ungeordneten Monolithen ja, weil alles mit allem verknüpft ist. Bei einem modularen Monolithen mit klaren Schnittstellen lässt sich ein Modul vergleichsweise gezielt herauslösen. Die Vorarbeit liegt in der Modularisierung, nicht im Umzug.

Wie viele Entwickler braucht man für Microservices?

Eine feste Zahl gibt es nicht. Als Faustregel sollte jeder Dienst ein Team haben, das ihn verantwortet und betreibt. Wenn ein kleines Team viele Dienste betreut, überwiegt meist der Aufwand.

Brauchen Microservices zwingend Kubernetes?

Nein. Kubernetes ist verbreitet, aber auch Managed-Container-Dienste oder Plattformen wie Fly.io und Render können Dienste betreiben. Kubernetes lohnt sich eher bei vielen Diensten und einem Team, das sich mit dem Betrieb auskennt.

Fazit

Die Architekturfrage entscheiden in der Praxis Teamgröße und Produktphase. Ein modularer Monolith hält Ihnen beide Wege offen, und wer sauber modularisiert, entscheidet über Microservices dann, wenn echte Gründe vorliegen.

Wenn Sie die Architektur für ein neues SaaS-Produkt planen, sprechen Sie mit uns über Webentwicklung.