SaaS-Monolith zu modularer Architektur: erst umstrukturieren, dann aufteilen – wenn ein Test es erfordert

Dieser Leitfaden richtet sich an SaaS-Gruender, CTOs und Engineering Leads, deren Produkt langsam ausgeliefert wird, weil jede Aenderung alles beruehrt. Er setzt ein Live-Produkt mit zahlenden Mandanten voraus. Den Aufbau einer ersten Version behandelt unsere SaaS-MVP-Architektur-Roadmap, das uebergeordnete Bild der SaaS-Platform-Engineering-Leitfaden und die allgemeine Wahl zwischen Neuentwicklung, Refactoring und Replatforming der Leitfaden zu digitaler Transformation und Modernisierung.

Inhalt dieses Leitfadens

• Ist der Monolith wirklich das Problem?
• Das Ziel: ein modularer Monolith vor allen Diensten
• Den Weg waehlen
• Schnittlinien finden, dann Grenzen ziehen
• Schritt fuer Schritt: ein Modularisierungspfad
• Mandanten, Abrechnung und Daten waehrend der Migration
• KI bei einer Modernisierung
• Welche Liefernachweise existieren - und welche nicht
• Alternativen: Wer fuehrt die Arbeit?
• Grenzen dieses Leitfadens
• Haeufig gestellte Fragen
• Naechster Schritt

Ist der Monolith wirklich das Problem?

Ein Monolith ist eine Anwendung, die als eine Einheit deployed wird. Das ist kein Fehler an sich: Martin Fowlers Monolith-first-Empfehlung haelt fest, dass fast alle erfolgreichen Microservice-Geschichten mit einem Monolithen begonnen haben, der zu gross geworden ist, und dass stabile Service-Grenzen schwer zu ziehen sind, bevor man die Domaene kennt. Achten Sie auf folgende Anzeichen, bevor Sie etwas umstrukturieren:

• Aenderungen kollidieren. Mehrere Teams bearbeiten dieselben Dateien, Releases warten aufeinander, und ein kleiner Fix erfordert einen vollstaendigen Regressionstest.
• Ein Fehler legt alles lahm. Ein aufwendiger Report oder Import verlangsamt Anmeldung und Abrechnung fuer alle Mandanten.
• Niemand kann einen Teil erklaeren. Code greift auf die Daten anderer Codeabschnitte zu, sodass eine Aenderung an einer Stelle eine andere kaputt macht.
• Eine Arbeitslast benoetigt eine andere Behandlung. Suche, Medienverarbeitung oder KI-Funktionen benoetigen andere Hardware, Skalierung oder Release-Regeln als der Rest.

Strukturieren Sie nicht um, wenn das Problem anderswo liegt. Langsame Seiten haben oft fehlende Datenbankindizes, instabile Releases oft fehlende Tests, und eine hohe Rechnung oft fehlende Kostenzuordnung - das behandelt unser Leitfaden zu Cloud-Kostenkontrollen. Ist das System alt, nicht mehr unterstuetzt oder insgesamt undurchsichtig, fuehren Sie zunaechst die Checkliste zur Legacy-System-Bewertung durch.

Das Ziel: ein modularer Monolith vor allen Diensten

Ein modularer Monolith ist weiterhin eine einzige deploybare Anwendung, aber ihr Code ist in Module aufgeteilt, jedes mit einer klaren oeffentlichen Schnittstelle und eigenen Daten. Shopifys Engineering-Team beschrieb diesen Ansatz fuer seine grosse Rails-Anwendung: Komponenten mit definierten Grenzen, sodass Entwickler in den fuer sie relevanten Bereichen arbeiten und Tests fuer eine einzelne Komponente statt fuer das Gesamtsystem laufen koennen. Derselbe Artikel listet Erkenntnisse auf, die das Team beim Neustart anders umsetzen wuerde - planen Sie daher fuer Iterationen.

Was ein Modul zu einem echten Modul macht - und nicht nur zu einem Ordner:

1. Eine oeffentliche Schnittstelle. Andere Module rufen Funktionen auf oder senden Ereignisse; sie greifen nie auf interne Strukturen zu.
2. Eigene Daten. Jedes Modul besitzt seine Tabellen. Kein anderes Modul liest oder verknuepft sie direkt.
3. Ein Eigentuemer. Ein Team ist fuer das Verhalten des Moduls und seine Tests verantwortlich.
4. Eine durchgesetzte Regel. Eine Pruefung im Build schlaegt fehl, wenn ein Modul auf die internen Strukturen eines anderen zugreift.

Typische Module fuer ein SaaS-Produkt sind: Identitaet und Zugriff, Mandanten und Berechtigungen, Abrechnung und Abonnements, die Kernproduktdomaenen, Benachrichtigungen und Reporting. Der Mandantenkontext durchlaeuft jedes Modul; der Leitfaden zur Multi-Tenant-Architektur erlaeutert die Isolationsentscheidungen, auf denen diese Wahl beruht.

Den Weg waehlen

Die meisten Produkte enden mit einem modularen Kern und null bis wenigen ausgelagerten Diensten. Teams sollten einen vollstaendigen Microservice-Verbund als ein Ziel betrachten, das man sich verdienen muss - nicht als Ausgangspunkt.

Schnittlinien finden, dann Grenzen ziehen

Eine Schnittlinie ist eine Stelle, an der ein Teil des Codes mit wenig Aufwand vom Rest getrennt werden kann. Finden Sie sie aus Belegen, nicht aus einem Architekturdiagramm:

• Abhaengigkeitskarte. Generieren Sie den tatsaechlichen Import-Graphen. Module mit vielen eingehenden und wenigen ausgehenden Aufrufen sind gute erste Kandidaten; verwobene Kerne kommen zuletzt.
• Dateneigentuem. Listen Sie fuer jede Tabelle auf, welcher Code sie liest und schreibt. Tabellen, die von vielen Bereichen beschrieben werden, zeigen eine Grenze, die noch nicht existiert.
• Aenderungshistorie. Dateien, die sich gemeinsam aendern, gehoeren meist zusammen. Dateien, die sich unabhaengig aendern, deuten auf eine Grenze hin.
• Fachsprache. Namen, die an verschiedenen Stellen unterschiedliches bedeuten - etwa "Account" in der Abrechnung und bei der Anmeldung -, markieren die Grenzen zwischen Domaenen.

Waehlen Sie das erste Modul nach niedrigem Risiko und hohem Lerneffekt: eine klare Funktion, eine kleine Schnittstelle und wenig geteilte Daten. Benachrichtigungen oder Reporting passen oft. Lassen Sie Abrechnung und Identitaet, bis die Methode erprobt ist, und behandeln Sie sie dann mit besonderer Sorgfalt, da Fehler dort jeden Mandanten betreffen.

Mandanten, Abrechnung und Daten waehrend der Migration

Multi-Tenancy ist der Bereich, in dem eine Umstrukturierung unbemerkt schiefgeht. Drei Regeln helfen:

• Mandantenkontext ist nicht optional. Jedes Modul und jeder neue Dienst muss den Mandantenbezeichner empfangen und durchsetzen - idealerweise in gemeinsamem Code, nicht manuell wiederholt.
• Mandanten in Kohorten migrieren. Mit internen und bekannten Mandanten beginnen, Fehler und Performance beobachten, dann ausweiten. Eine Migration, die fuer zehn kleine Mandanten funktioniert, muss nicht fuer einen mit jahrelangen Daten funktionieren.
• Abrechnung und Berechtigungen als Vertrag behandeln. Nutzungsereignisse und Planlimits muessen fuer Kunden identisch bleiben, waehrend sich der darunterliegende Code aendert. Rechnungen und Berechtigungsergebnisse aus alten und neuen Pfaden vergleichen, bevor umgeschaltet wird.

Datenverschiebungen erfordern einen Plan fuer Lese- und Schreibzugriffe waehrend des Uebergangs: Dual Writes, Change Capture oder ein kurzer Freeze - jeweils mit einer anschliessenden Abstimmungspruefung.

Welche Liefernachweise existieren - und welche nicht

Netbase JSC entwickelt und betreibt Multi-Tenant-SaaS-Produkte, was den Rahmen bildet, fuer den dieser Leitfaden geschrieben wurde:

• Cloodo Workspace. Ein digitaler Arbeitsplatz fuer Work-Management mit CRM-, HRM-, Cloud-ERP- und KI-Modulen in einem Produkt, entwickelt und betrieben als Netbase JSC Business Division (Cloodo-Nachweis).
• Cloud-ERP fuer einen US-Kunden (anonym). Ein Multi-Tenant-Cloud-ERP, das Netbase JSC seit 2020 als Offshore-Entwicklungspartner und Managing Partner entwickelt (Cloud-ERP-Nachweis).
• Printcart. Das Web-to-Print-SaaS der Netbase JSC Business Divisions (Printcart-Nachweis).
• Netztech. Ein Shop, der in 35 Arbeitstagen von Magento 1 auf Magento 2 Commerce migriert wurde (Netztech-Nachweis). Es handelt sich um eine Plattformmigration, nicht um eine Monolith-Dekomposition.

Der Lieferlebenszyklus von Netbase JSC umfasst modulare und produktisierte Komponenten, und der SaaS-Produkt-Accelerator ist aus wiederverwendbaren Modulen aufgebaut.

Was nicht existiert. Kein veroeffentlichter Netbase JSC-Nachweis beschreibt die Zerlegung eines Live-SaaS-Monolithen in Module oder Dienste, und keiner veroeffentlicht eine Dauer, eine Deployment-Frequenz, Kosten oder ein Performance-Ergebnis fuer solche Arbeiten. Die obige Methode entstammt den zitierten Quellen und der allgemeinen Engineering-Praxis, nicht einem gemessenen Netbase JSC-Ergebnis.

Alternativen: Wer fuehrt die Arbeit?

Vier Kriterien entscheiden: ob Tests und Monitoring vorhanden sind, wie viele Personen den alten Code verstehen, wie viel Roadmap-Arbeit waehrend der Migration weiterlaufen muss und wer danach die Architektur verantworten soll. Netbase JSC beginnt mit einem Architektur-Review zu Mandantenfaehigkeit, Abrechnung, Sicherheit und Kosten und plant dann die Scheiben. Bei der individuellen Entwicklung durch Netbase JSC behaelt der Kunde das IP, das fuer ihn entwickelt wurde; die meisten Projekte laufen auf Festpreis-Vertraegen, die nach der Discovery vereinbart werden. Das Angebot umfasst SaaS-Entwicklung und Cloud-Platform-Engineering.

Grenzen dieses Leitfadens

• Jede Codebasis ist anders; die erste Abhaengigkeitskarte aendert den Plan oft.
• Frameworks und Programmiersprachen bieten unterschiedliche Werkzeuge zur Durchsetzung von Grenzen; pruefen Sie, was Ihre unterstuetzt.
• Quellen werden fuer das zitiert, was sie dokumentieren; es werden keine Geschwindigkeits-, Kosten- oder Zuverlaessigkeitswerte behauptet.

Naechster Schritt

Teilen Sie uns mit, wie das Produkt heute deployed wird, wie viele Teams es aendern und welcher Teil am meisten schmerzt - wir vereinbaren dann ein Solution-Review, um die Schnittlinien zu kartieren und das erste Modul vorzuschlagen. Sie koennen auch weitere Netbase JSC Insights lesen.

Verwandte Leistungen und Lösungen