Microservices an unabhängigen Änderungen ausrichten
Getrennte Dienste lohnen eine Prüfung, wenn fachliche Grenzen, Datenverantwortung und unabhängige Auslieferung zusammenpassen.
Welche Änderung soll unabhängig möglich werden?
Eine Anwendung auf mehrere Dienste zu verteilen schafft noch keine unabhängige Weiterentwicklung. Müssen dieselben Personen bei jeder Preisregel alle Dienste gemeinsam ändern und ausliefern, bleibt die Abstimmung bestehen. Hinzu kommen Aufrufe über das Netzwerk und weitere Betriebsaufgaben.
Microsoft beschreibt unabhängige Bereitstellung und eigene Datenverantwortung als wesentliche Merkmale. Unser Ausgangspunkt für die Entscheidung ist deshalb eine konkrete Änderung: Welcher fachliche Bereich soll sie ohne gleichzeitige Anpassung anderer Bereiche tragen können?
Beispiel: Angebote und Aufträge bleiben zunächst zusammen
Das folgende Produkt und seine Arbeitsweise sind erfunden. Ein Team betreut Angebote, Aufträge und Berichte. Preisregeln ändern sich gemeinsam in Angebot und Auftrag. Die Berichtsformate haben einen anderen Änderungsbedarf.
Beobachtete Grenze im Beispiel | Vorläufige Entscheidung | Was die Entscheidung stützen muss |
|---|---|---|
Angebot und Auftrag teilen sich dieselbe fachliche Preisänderung. | Gemeinsam ausliefern, intern klar gegliedert. | Zuständigkeit und Modulzugriffe sind ausdrücklich geregelt. |
Berichtsformate können sich unabhängig verändern. | Ein eigenes Modul; einen separaten Dienst bei belegtem Bedarf prüfen. | Stabile Datenschnittstelle, verantwortlicher Betrieb und benötigte Aktualität der Daten sind geklärt. |
In dieser Planung bleibt die Anwendung zunächst ein modularer Monolith: innere Grenzen, gemeinsame Auslieferung. Spring Modulith zeigt beispielhaft die Unterscheidung von öffentlicher Modulschnittstelle und innerer Umsetzung. Diese Trennung ist auch ohne die Wahl dieses konkreten Werkzeugs sinnvoll zu beschreiben.
Nehmen Sie den Betrieb in die Entscheidung auf
Ein separater Berichtsdienst müsste mit Ausfällen seiner Datenquelle umgehen. Jemand müsste Bereitstellung, Überwachung und Fehlerklärung verantworten. Das Team braucht außerdem Regeln, nach denen alte und neue Schnittstellenversionen während einer Umstellung zusammenarbeiten. Ein eigener Prozess allein erfüllt diese Bedingungen nicht.
Halten Sie den Grund für eine spätere Trennung fest: beispielsweise tatsächlich notwendige unabhängige Auslieferung oder eine anders zu behandelnde Last. Prüfen Sie dabei Kopplung, Datenzugriff und Betriebsaufwand erneut. Auch gemeinsam ausgelieferte Module können klar strukturiert sein. Umgekehrt kann ein gut abgegrenzter Dienst gerechtfertigt sein, bevor die übrige Anwendung aufgeteilt wird. Die Zahl der Dienste ist kein Qualitätsmaß für diese Entscheidung.
Quellen
Geschrieben von
- Katharina WeberRedakteurin für Software und TechnologieKatharina Weber betreut bei ASES die Beiträge zur Softwareentwicklung. Sie schreibt über Fragen, die Unternehmen bei der Auswahl von Software, der Entwicklung neuer Anwendungen und der Modernisierung bestehender Systeme beschäftigen.
Weiterlesen
Alle Beiträge
Softwareentwicklung mit ASES
Individuelle Software, Web- und Mobile-Apps