Erst das Problem benennen
„Wir brauchen eine moderne Architektur“ ist ein verständlicher Wunsch. Als Entscheidungsgrundlage ist er zu ungenau.
Hilfreicher sind Sätze wie: „Das Reporting bremst die Auftragserfassung.“ Oder: „Drei Teams warten bei jedem Release aufeinander.“ Diese Probleme lassen sich untersuchen. Für sie kann man Ziele festlegen und später prüfen, ob eine Veränderung geholfen hat.
Meine Ausgangsfrage lautet deshalb: Welche konkrete Einschränkung soll die Aufteilung in Services beseitigen? Wenn die Antwort vor allem aus Technologienamen besteht, fehlt noch ein Stück Analyse.
Was ein modularer Monolith bedeutet
Ein modularer Monolith wird als gemeinsame Anwendung veröffentlicht, ist intern aber nach fachlichen Verantwortlichkeiten gegliedert. Aufträge, Abrechnung und Kundenverwaltung haben definierte Schnittstellen. Ein Modul greift nicht nach Belieben auf die Interna eines anderen zu.
In einer .NET-Anwendung können separate Projekte solche Grenzen unterstützen. Allein dadurch entstehen sie allerdings noch nicht. Entscheidend ist, welche Abhängigkeiten erlaubt sind, wem Daten gehören und ob diese Regeln im Alltag eingehalten werden.
Ein gemeinsamer Datenbankserver ist dabei möglich. Das bedeutet nicht, dass jedes Modul sämtliche Tabellen verändern darf. Die technische Nähe soll die fachliche Verantwortung nicht auflösen.
Microservices verlagern solche Grenzen zusätzlich zwischen getrennt betreibbare Dienste. Damit wird unabhängiges Veröffentlichen möglich. Gleichzeitig muss die Anwendung mit Netzwerkfehlern, unterschiedlich verfügbaren Komponenten und verteilten Daten umgehen. Diese Abwägung beschreibt auch der Azure Architecture Center.
Fünf Fragen für die Entscheidung
1. Wer muss unabhängig veröffentlichen können?
Schau auf die letzten Releases: Was hat sie tatsächlich verzögert? Eine gemeinsame Bereitstellung ist nicht automatisch das Problem. Vielleicht fehlen automatisierte Tests oder eine klare Freigabeentscheidung.
Wenn mehrere Teams dagegen regelmäßig fertige Änderungen zurückhalten müssen, weil fachlich unabhängige Bereiche einen gemeinsamen Release-Zug teilen, ist getrennte Bereitstellung ein ernsthafter Kandidat. Dann sollte das Ziel konkret sein: Welches Team kann welche Änderung künftig ohne Abstimmung mit den anderen ausliefern?
2. Welcher Teil braucht wirklich andere Ressourcen?
„Wir müssen skalieren können“ sagt noch wenig. Braucht ein nächtlicher Import viel Arbeitsspeicher, während das Portal tagsüber auf kurze Antwortzeiten angewiesen ist? Oder ist die Datenbankabfrage langsam, unabhängig davon, wie viele Dienste davorstehen?
Ich würde zunächst messen und die Engstelle eingrenzen. Ein gezielt ausgelagerter Worker kann bereits die passende Antwort sein. Daraus folgt keine Verpflichtung, auch Kundenverwaltung, Berechtigungen und Abrechnung separat zu betreiben.
3. Welche Daten müssen gemeinsam korrekt sein?
Nimm einen Geschäftsprozess und spiele ihn bei einem Teilausfall durch. Ein Auftrag wurde angenommen, die Reservierung des Bestands ist aber fehlgeschlagen: Was sieht der Kunde? Wer korrigiert den Zustand? Darf die Bestätigung später kommen?
Diese Antworten gehören vor die technische Aufteilung. Eine fachlich notwendige gemeinsame Transaktion ist ein Grund, eine Grenze besonders sorgfältig zu prüfen. Eine spätere Angleichung der Daten kann funktionieren, wenn der Geschäftsprozess sie zulässt und Fehlerbehandlung vorgesehen ist.
4. Wer betreibt das Ganze am nächsten Morgen?
Zur Entscheidung gehört eine Person oder ein Team, das im Fehlerfall zuständig ist. Kann es einen fehlgeschlagenen Ablauf nachvollziehen, eine problematische Version zurücknehmen und erkennen, welche Kunden betroffen sind?
Martin Fowler nennt schnelle Bereitstellung, Überwachung und enge Zusammenarbeit von Entwicklung und Betrieb als Voraussetzungen für Microservices. Für die Planung heißt das: Den dafür nötigen Aufwand von Anfang an mitbudgetieren. Ein Managed Service übernimmt nicht die Verantwortung für den eigenen Geschäftsprozess.
5. Wie sicher sind die fachlichen Grenzen?
Wenn jede zweite neue Anforderung die Aufteilung verändert, würde ich diese Grenzen zunächst innerhalb einer Anwendung erproben. Fachliche Unsicherheit verschwindet nicht dadurch, dass zwischen zwei Modulen eine HTTP-Verbindung liegt.
Das ist auch der Kern des Monolith-First-Arguments: erst die Aufteilung besser verstehen, dann bei Bedarf verteilen. Daraus folgt kein Versprechen, dass eine spätere Auslagerung kostenlos wird. Sie braucht weiterhin eine eigene Planung.
Ein Beispiel: Kundenportal mit aufwendigem Reporting
Angenommen, ein Team betreut ein Kundenportal. Kunden verwalten Aufträge, Mitarbeiter bearbeiten sie, und ein Monatsreport benötigt zeitweise viel Rechenleistung. Dieses Beispiel ist hypothetisch.
Mein erster Entwurf wäre eine modular aufgebaute Anwendung. Vor einer Aufteilung würde ich messen, ob der Report tatsächlich die interaktive Nutzung beeinträchtigt und wodurch.
Falls eine getrennte Verarbeitung hilft, könnte ein Worker den Report übernehmen. Dann müsste man unter anderem klären, wie aktuell seine Daten sein müssen, wie ein Auftrag wiederholt wird und wo das fertige Ergebnis liegt. Der Rest des Portals könnte gemeinsam veröffentlicht werden.
Entsteht später ein eigenständiges Reporting-Team mit eigenen Release-Anforderungen, lässt sich die Entscheidung erneut treffen. Die Architektur wächst damit entlang eines nachweisbaren Bedarfs.
Die Entscheidung auf einer Seite festhalten
Vor einer größeren Aufteilung würde ich diese fünf Punkte aufschreiben:
- Problem: Was funktioniert heute nicht ausreichend gut?
- Ziel: Woran erkennen wir eine Verbesserung, etwa an kürzerer Release-Wartezeit?
- Alternative: Welche kleinere Änderung könnte dasselbe Problem lösen?
- Kosten: Welche zusätzliche Arbeit entsteht bei Entwicklung, Betrieb und Fehlerbehandlung?
- Prüftermin: Wann bewerten wir die Entscheidung erneut?
Ein modularer Monolith braucht Disziplin. Microservices brauchen sie ebenfalls, ergänzt um die Anforderungen verteilter Systeme. Für mich ist eine Auslagerung dann überzeugend, wenn ihr konkreter Nutzen die zusätzliche Verantwortung rechtfertigt. Die Zahl der Services ist dabei kein Erfolgsmaß.
Steht diese Entscheidung bei dir an?
Ich unterstütze Unternehmen bei der Modernisierung ihrer .NET-Anwendungen und bei Architekturentscheidungen, die zum Team und zum Betrieb passen. Wenn du gerade zwischen Umbau, Aufteilung und Weiterentwicklung abwägst, können wir im kostenlosen Erstgespräch über eure Ausgangslage sprechen.