Weitere Überlegungen - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Weitere Überlegungen

Bisher haben wir die Verwendung von API Gateway und Windows-Containern zur Modernisierung Ihrer älteren ASP.NET-Webdienste besprochenAWS. Hier sind einige weitere Überlegungen, die Sie berücksichtigen sollten:

  • Sicherheit

  • Umgestaltung von Servicedomänen

  • Sequenzierung von Webservice-Upgrades, wenn viele Dienste modernisiert werden müssen

Diese werden in den folgenden Abschnitten erläutert.

Authentifizierung und Autorisierung

Moderne APIs nutzen im Allgemeinen tokenbasierte Authentifizierungs- und Autorisierungsstandards (JSON Web Token oder JWT) wie OAuth 2.0 und OpenID Connect, wohingegen ältere ASP.NET-Webdienste traditionell entweder auf einer Standardauthentifizierung oder einer integrierten Windows-Authentifizierung für eine Windows Active Directory-Domäne beruhten. In Fällen, in denen die alten und neuen Authentifizierungs- und Autorisierungsansätze nicht kompatibel sind, empfehlen wir Ihnen, diese Sicherheitsmechanismen zu aktualisieren, bevor Sie Ihren Webservice modernisierenAWS. Der Versuch, Identitäten zuzuordnen oder den Sicherheitsstatus sicher zwischen dem alten und dem neuen System zu übertragen, ist möglicherweise kein großer Aufwand, kann jedoch zu Sicherheitslücken führen.

Domain-getriebenes Design

Bei der Aufteilung eines Monolithen in einzelne Services ist domänengetriebenes Design (DDD) eine bewährte Methode, die häufig verwendet wird, um Systeme in kohärente Geschäftsbereiche zu modellieren. DDD ist ein Ansatz zur Entwicklung von Software für komplexe Anforderungen, indem die Implementierung mit einem sich entwickelnden Modell der Kerngeschäftskonzepte verknüpft wird. Die Prämisse besteht darin, den Hauptfokus des Projekts auf die Kerndomäne und die Domänenlogik zu legen und die Systemdesigns auf einem Modell zu basieren, das das Geschäft widerspiegelt. Wenn Sie DDD bei der Modernisierung einer bestehenden, monolithischen Anwendung verwenden, müssen Sie von den Funktionen und Benutzerabläufen des Monolithen ausgehend rückwärts arbeiten. Sie können DDD in Kombination mit dem Strangler-Muster verwenden, um den Prozess zu steuern, den Monolithen zu durchbrechen und zu bestimmen, welche Dienste erwürgt werden sollen. Daher der Begriff domänengetriebenes Design.

Zwischenstaaten und Zielstaat

Wenn Sie mehr als ein paar ASP.NET-Webdienste modernisierenAWS, empfiehlt es sich, zunächst zu definieren, wie Ihre Zielstatus-Architektur aussehen soll, nachdem alle Dienste modernisiert wurden. Die Zielstatus-Architektur ist jedoch nicht unbedingt der Endstatus oder der Endstatus, da sich die Geschäftskontexte häufig ändern und der Systemzielstatus bei Bedarf aktualisiert werden sollte, um mit den Geschäftszielen in Einklang zu bleiben. Wenn Sie den Zielstatus definiert haben, können Sie von dort aus rückwärts arbeiten, um Zwischenstate-Architekturen zu definieren, die die Zielzustandsvision schrittweise erfüllen. Sie können sich diese Zwischenstaatenarchitekturen als die Entwicklung der Würgerfeige vorstellen, die den Baum hinaufsteigt, während sie auf große Teile des Wirtsbaums trifft und ihn verschlingt. Interimstate-Architekturen führen häufig temporäre oder überlappende Konstrukte ein, die nicht Teil der Endzustandsarchitektur sind, um den Übergang zum Zielzustand zu erleichtern. Die Modernisierung des SOAP-basierten ASP.NET-Webdienstes ist ein Beispiel dafür: Ein Windows-basierter Container wird vorübergehend eingeführt, um die Lücke zwischen aufrufenden Systemen zu schließen, die vom Legacy-Dienst abhängig sind, bis sie auf die neue REST-API aktualisiert werden können.