Laden...

Technologien für eine N-Tier Architektur (Client - Server - Datenkbank)

Erstellt von LastCry vor 5 Jahren Letzter Beitrag vor 5 Jahren 1.168 Views
L
LastCry Themenstarter:in
2 Beiträge seit 2019
vor 5 Jahren
Technologien für eine N-Tier Architektur (Client - Server - Datenkbank)

Hallo,

unsere Software ist derzeit 15 Jahre alt und muss in naher Zukunft erneuert werden.
Daher wird nach neuen Technologien gesucht. Was würdet ihr für
Technologien einsetzen bzw. empfehlen für folgende Anforderung:

Einsatzgebiet: Industrie (Produktion / Logistik / BDE ...)

Client:

  • Ein Client muss Presentationslogiken zur Laufzeit vom Application Server nachladen können,
    ohne neustart (Pluginsystem)

Application Server

  • Sollte sogut wie nie neugestartet werden.

  • Neue Backendlogiken oder Presentationslogiken (für den Client) müssen ebenfalls zur Laufzeit
    auf dem Application Server bereitgesetellt werden können.

  • Ausführen von Prozessen (Backendlogik / Datenbank - Funktionen / Prozeduren) auf dem
    Application Server sollte möglichst isoliert ablaufen.

  • Datenbank (Oracle / MSSQL)

Hauptziel des ganzen ist Robustheit und ein Pluginsystem. Wir setzen momentan auf das .NET 4.0 Framework.
Unsere momentane Architektur setzt hauptsächlich auf Appdomain / Net-Remoting / WCF / Protobuf.
Wenn man nun neu aufsetzen würde, welche Technologien bietet sich an, bzw. würden sich in
naher Zukunft anbieten? Danke!

16.807 Beiträge seit 2008
vor 5 Jahren

Da kann man Dir circa 784532 Technologien nennen; aber zu einer Technologieauswahl gehören nicht nur technische Dinge, sondern Dinge wie: bekommt ihr Mitarbeiter für diese Technologien?
Wie und wo wird die Technologie betrieben? etc etc..

Das ist in meinen Augen keine wirkliche Anforderungsliste - klingt eher nach einem Einhorn-Wunschkonzert. 😃
Wer wünscht sich nicht, dass man eine Applikation nie neustarten muss und das alles und immer austauschbar ist - zur Laufzeit.
Nur ist das halt ganz ganz weit weg von DevOps und Co.

Und auch scheint eure Architktur eher auf alten Prinzipien zu basieren; wollt ihr das nicht auch mal überholen? Ansonsten baut ihr halt wieder nen teuren Monolithen.. 😉
Moderne Architekturen mit Anforderungen wie Always-On würden Dinge wie eine Austauschbarkeit auf IT-organisatorischer Ebene lösen; nicht auf teurer, komplexer Software-Ebene - zum Beispiel basierend auf Event Sourcing und Co.
Gerade im Logistikbereich ist Event Sourcing ein extrem großes Thema. Die gesamte Amazon Handelsplattform, die Bahn oder auch der Hamburger Hafen basiert auf solchen oder in diese Richtung gehende Architekturmustern.

Ansonsten, wenn ihr nur 1:1 Austauschen wollt - nicht alle Wünsche werden erfüllbar sein - dann kommst im Backend-Bereich so oder so in der .NET Welt nicht (mehr) an ASP.NET Core vorbei.
Alles andere kann man mit den Bierdeckel-Anforderungen nicht beantworten 😉
Letzten Endes kommt ihr an nem entsprechenden Evaluierungs- und Technologie-Workshop sowieso nicht vorbei; egal welchen Weg ihr geht.

C
2.121 Beiträge seit 2010
vor 5 Jahren

Besser wäre das anders herum aufzuziehen, erst nach neuen Technologien Ausschau halten und das Projekt dann erneuern wenn man welche findet die tatsächlich Mehrwert bieten.

Kurz ausgedrückt nicht aus Tatendrang, sondern weil nötig 😉

Es gibt uralte Systeme die immer noch erweitert werden. Warum? Weil sie funktionieren und auch mit alter Technologie noch erweiterbar sind. Ein wichtiger Faktor ist dabei die Manpower. Vergesst nicht dass ihr eine neue Technologie erst beherrschen müsst. Außerdem wollt ihr sicher nicht alles neue doppelt machen, einmal "old school" im jetzigen System weil man es da schon braucht, und dann nochmal neu im neuen System das möglicherweise noch lange nicht einsetzbar ist.

Edit: Ich sollte das etwas präziser formulieren. Natürlich darf und sollte man neues einsetzen wenn es machbar ist. Aber nicht aus der Motivation heraus, los lasst uns was neues machen - jetzt müssen wir nur noch schauen womit. Was ist der Hauptgrund um das jetzige System erneuern zu müssen?
Man darf tatsächlich nicht unterschätzen wie viel Zeit eine radikale Umstellung auf alles neue was sich finden lässt, in Anspruch nimmt. Auch der Stillstand beim bestehenden Projekt ist einem anfangs nicht unbedingt bewusst.

L
LastCry Themenstarter:in
2 Beiträge seit 2019
vor 5 Jahren

Danke für die Antworten. Die Software bzw. Architektur soll nicht von heute auf morgen erneuert werden, sondern in naher Zukunft. Das eigentliche Problem ist, dass die jetzige Architektur kaum Wartbar ist, da zu komplex, es wurde zu "groß" gedacht und diverse Core-Entwickler nicht mehr zur Verfügung stehen. Die Software ließe sich bestimmt schlanker und übersichtlicher gestalten. Da Appdomains, WCF und diverses von MS nicht weiter unterstützt bzw. entwickelt wird, wollte ich neue Ansätze hören

16.807 Beiträge seit 2008
vor 5 Jahren

Aber einfach Technologien tauschen wäre der falsche Ansatz bei so einer Situation.... damit ist Dir nicht geholfen; ihr bohrt am falschen Zahn.
Auch neue Technologien kann man falsch einsetzen...

Wenn eure Architektur (sowohl Solution wie auch Software) einfach Käse ist, dann muss halt auch das verbessert werden.