Strukturplanug Klappe die 2. Microservices zu ModulMonolith

Diskutiere Strukturplanug Klappe die 2. Microservices zu ModulMonolith im Application Tier Bereich.
M

M.L.

viele verschiedene Paradigmen abgeschaut
Vielleicht läuft die Endarchitektur auf eine Kombination versch. Paradigmen hinaus:
(und wird ein Fall für teures Refactoring oder die DB erweist sich als Datengrab....)
 
NicoDeluxe

NicoDeluxe

Achso, und mit "langsamer desto mehr Daten in der Tabelle sind" meinst du, dass es langsamer wird wenns 100 statt 5 Kunden sind?
Jo genau so meint ich das. Wenn ein Monolith pro User existiert, könnten die Daten direkt in die echte Datenbank (ohne Daten vorher zu chachen) Dann würde das Hersteller Modul die Artikel nehmen, zurechtbasten, berechnen und an die Persistenz geben. In dem Monolith würde dann komplette Netzwerkgeschichte wegfallen (
 
mrBrown

mrBrown

In dem Monolith würde dann komplette Netzwerkgeschichte wegfallen (
Ist das Netzwerk aktuell an irgendeiner Stelle ein Problem? An keiner Stelle klingt das irgendwie nach Netzwerkproblemen.

Jo genau so meint ich das. Wenn ein Monolith pro User existiert, könnten die Daten direkt in die echte Datenbank (ohne Daten vorher zu chachen) Dann würde das Hersteller Modul die Artikel nehmen, zurechtbasten, berechnen und an die Persistenz geben.
Der Cache dient aktuell dazu, das ganze schneller zu machen.

Durch den Cache haben die Hersteller-Services zwar viel, aber konstante Last, die Last kannst du problemlos steuern und die Services beliebig vertikal und horizontal skalieren – der Master-Service hat dadurch aber kaum konstante Last, der komplizierte Teil (das finden der Änderungen), findet in der Hersteller-Services statt, und hat damit genug Reserven für das Frontend.

Wenn du das jetzt wieder in einen Service mergest, hat der sowohl die hohe Grundlast, muss aber zusätzlich noch Reserven für das Frontend haben.

(Service meint jeweils DB + Applikation)

Vor allem landest du damit dann aber auch wieder beim Ursprungsproblem:
Wir hatten das System bereits als Monolith aber wenn der Service abgestürzt ist> Alle Herstellerimporte betroffen, Frontend konnte keine Daten mehr anzeigen usw.

Mach dir einfach mal eine Pro- und Contra-Liste, in der du alle möglichen Relevanten Punkte zwischen beiden (und anderen) Lösungen vergleichst. Relevant wären zB Ausfallsicherheit, Deployment, Monitoring, ... und was auch immer euch wichtig ist.

Und zusätzlich solltest du deine Probleme mit der aktuellen Lösung mal konkret rausfinden. Hier hast du Gefühl ein Duzend Probleme erwähnt, aber keines davon so wirklich. Aber alle davon klingen relativ klein und einfach behebbar.
 
NicoDeluxe

NicoDeluxe

Vor allem landest du damit dann aber auch wieder beim Ursprungsproblem:
Damals hatten wir einen Monolith für 50 Kunden, dabei konnte der RAM zu Ende gehen etc. Jetzt würden wir pro Kunden einen Monolith auf einen eigenen Server stellen. Je nach dem was der Kunde gebucht hat würde er einen entsprechend starken Server bekommen.
 
Thema: 

Strukturplanug Klappe die 2. Microservices zu ModulMonolith

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben