Anwendungsarchitektur - weniger große Systeme im Vergleich zu mehr kleineren Systemen


8

Betreff: Anwendungsarchitektur, dh " die Wissenschaft und Kunst, sicherzustellen, dass die Anwendungssuite, die von einer Organisation zum Erstellen der Verbundanwendung verwendet wird, skalierbar, zuverlässig, verfügbar und verwaltbar ist. "

Wenn ich mir eine Reihe von Anwendungen in einer Organisation anschaue, sehe ich verschiedene Gründe für das Zusammenführen von Apps, aber manchmal auch gute Gründe, sie getrennt zu halten.

Was sind im Allgemeinen die Vor- und Nachteile von weniger großen Systemen im Vergleich zu kleineren Systemen (wenn man bedenkt, dass viele Systeme Informationen austauschen).

Ich denke an Dinge wie: Weniger, größere Apps bedeuten weniger Installationen zwischen Apps, aber mehr kleinere Apps bedeuten mehr Flexibilität für einzelne Abteilungen.

Gibt es Literatur dazu oder hat jemand eine Liste mit Vor- und Nachteilen, die er entdeckt hat?

Bearbeiten: In meinem Szenario sind viele der Apps möglicherweise von der Stange anpassbar und nicht selbst entwickelt. Sie können jedoch auch allgemeinere Szenarien in Betracht ziehen.


1
Beachten Sie, dass größere Apps keine Installation bedeuten, sondern nur, dass die Installation innerhalb der App erfolgt.
Deadalnix

@deadalnix: vereinbart. Ich gehe davon aus, dass das Verknüpfen von Daten innerhalb einer App weniger Aufwand erfordert als das Verknüpfen von Daten zwischen Apps.
Codeulike

Antworten:


3

Ganz oben auf meinem Kopf

Kleinere Systeme

  • Pro - Skalieren Sie auf Standardhardware oder billigeren virtualisierten Umgebungen.
  • Pro - Kann On-Demand-Skalierung in einer Cloud implementieren.
  • Pro - Weniger systeminterne Abhängigkeiten, dh. 1 Dienst pro Server.
  • Pro- HA / DR (Hochverfügbarkeit / Notfallwiederherstellung) ist normalerweise einfacher zu implementieren
  • Con - Muss horizontal skalierbar sein
  • Con - Je mehr Systeme, desto mehr Verbindungen, desto komplizierter ist die Verwaltung

Größere Systeme

  • Pro - Weniger Verbindungen, was normalerweise bedeutet, dass es weniger kompliziert ist
  • Pro - Reagiert schneller auf hohe Spitzenauslastung, wenn diese innerhalb der Toleranz liegt.
  • Pro - Weniger zu verwaltende Ressourcen
  • Pro - Effizientere Ressourcennutzung (unter der Annahme einer relativ konstanten Nutzung)
  • Con - Kompliziertere systeminterne Abhängigkeiten, dh. N Dienste pro Server
  • Con - HA / DR ist normalerweise schwieriger / komplizierter

Danke, das ist großartig. Wie sehen Sie die Anpassung des Änderungsmanagements? Vielleicht sind lokale Änderungen bei kleineren Systemen einfacher, domänenweite Änderungen bei größeren Systemen einfacher?
Codeulike

Das Änderungsmanagement kann auf weniger Systemen manuell erfolgen, auf vielen Systemen jedoch schnell außer Kontrolle geraten und sollte automatisiert werden.
Dietbuddha

1

In einem größeren System ist es viel einfacher:

  • Teilen Sie Funktionen und Code. Sie werden das Rad etwas weniger neu erfinden. Wenn Sie beispielsweise zehn Anwendungen haben, die Zugriff auf die Datenbank haben müssen, müssen Sie die Verbindungszeichenfolge in allen angeben , dh zehnmal. Oder Sie müssen eine separate Bibliothek erstellen und zehnmal darauf verweisen.

  • Konsolidieren Sie Workflows , einschließlich des Bereitstellungsprozesses.

  • Verwalten des Systems: Weniger zu verwaltende Anwendungen sind im Allgemeinen einfacher .

  • Vereinheitlichen Sie die Benutzererfahrung . Wenn ein Mitarbeiter mit zehn verschiedenen Anwendungen arbeiten muss, kann er leicht verloren gehen: Welche Anwendung muss ausgeführt werden, um A auszuführen? In welcher Anwendung steht die Option B zur Verfügung? Aber nicht übervereinigen . Niemand wird Word, PowerPoint, Outlook, Publisher, Visio, Project und Groove als eine einzige monolithische Anwendung schätzen.

In einigen kleinen Systemen hingegen finden Sie Folgendes:

  • Sie können ein ganzes System verlassen, wenn Sie es nicht mehr benötigen. Oder fangen Sie von vorne an, wenn die Codebasis im Laufe der Zeit unbrauchbar wird. Dies gilt natürlich nur, wenn andere Systeme nicht auf dieses angewiesen sind oder wenn die Schnittstelle leicht genug ist, um in einer neuen Version einfach umgeschrieben zu werden.

  • Sie können ein Team aus neuen Entwicklern bilden und von ihnen erwarten, dass sie die vorhandene Codebasis in kürzerer Zeit verstehen . Wenn es Teil eines großen Projekts ist, werden sie wahrscheinlich mehr Zeit benötigen, es sei denn, die gesamte große Codebasis wird äußerst professionell erstellt und sehr gut überarbeitet (ich habe solche Codebasen in meinem Leben nicht gesehen).

  • Die Systemadministratoren können die Anwendungen einfacher verschieben . Das größere System hingegen lässt sich entweder auf mehreren Servern gut skalieren oder nicht.

  • Die Entwickler können die Codebasis einfacher auf neue Standards migrieren . Das Migrieren einer großen Codebasis macht immer Angst. Wenn Sie sich stattdessen mit einer kleinen Codebasis befassen müssen, dann mit einer anderen, dann mit einer anderen und so weiter, wird es weniger beängstigend.

Abgesehen davon funktionieren solche Vergleiche nur in allgemeinen Fällen, aber Ihre Entscheidung muss nicht aus Pools, sondern aus Ihrem Unternehmensvermögen getroffen werden. Wie ist es organisiert? Gibt es viele kleine oder einige große Entwicklerteams? Gibt es strenge Richtlinien für den Codierungsstil und ähnliche Dinge?

Dies hängt auch von der Anwendung selbst ab. Zum Beispiel wäre es absurd, alle Microsoft Office-Anwendungen als eine einzige App zu versenden. Es würde aber auch die Produktivität beeinträchtigen, beispielsweise Adobe Photoshop in einer Anwendung zum Zeichnen und eine andere zum Retuschieren von Fotos zu trennen. IMO, die Entscheidung, ein Produkt zu vereinheitlichen oder zu trennen, muss eine Geschäftsentscheidung sein, keine rein technische.

Abschließend möchte ich noch auf den zweiten Kommentar der ursprünglichen Frage antworten:

Ich gehe davon aus, dass das Verknüpfen von Daten innerhalb einer App weniger Aufwand erfordert als das Verknüpfen von Daten zwischen Apps

Es ist nicht immer wahr. Wenn Sie beispielsweise mit .NET arbeiten, ist es nicht ungewöhnlich, eine einzelne Anwendung zu versenden, bei der verschiedene Komponenten über WCF ausgetauscht werden. In diesem Fall ist dies vergleichbar mit einer Reihe separater Anwendungen, die über WCF kommunizieren.

Wenn Sie mit mehreren Anwendungen arbeiten müssen, müssen Sie natürlich eine Kommunikationsmöglichkeit für diese festlegen, während eine einzige monolithische Anwendung Sie nicht dazu zwingt. Aber könnten Sie wirklich eine große monolithische Anwendung schreiben?


0

Lesen Sie dies. Es ist die "viele kleine Programme" -Philosophie von Unix. Linux benutzt es auch. Die immense Ausdauer dieser Philosophie (von den späten 1960ern bis heute) legt nahe, dass es das Richtige ist.

http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond

http://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy

http://159.93.17.14/usoft/WWW/LJ/Articles/unixtenets.html

http://www.linuxjournal.com/article/2877


OK, das funktioniert für eine Reihe von Komponenten innerhalb eines Betriebssystems, aber funktioniert es für eine Reihe von Datenbankanwendungen innerhalb einer Organisation? Das ist ein ganz anderes Szenario.
Codeulike

Kein anderes Szenario. Können Sie einige spezifische Unterschiede angeben?
S.Lott

@codeulike: war das deine frage? "Gibt es Literatur dazu?" Wenn ja, hier ist Literatur. Ich verstehe Ihren Kommentar nicht im Zusammenhang mit Ihrer Frage.
S.Lott
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.