Festlegung einer Grundlage für das Anwendungsportfolio - 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.

Festlegung einer Grundlage für das Anwendungsportfolio

Um zuverlässige Migrationspläne zu erstellen, müssen Sie eine Ausgangsbasis für das Anwendungsportfolio und die zugehörige Infrastruktur festlegen. Eine Portfolio-Baseline bietet einen umfassenden Überblick über den Migrationsumfang, einschließlich der technischen Abhängigkeiten und der Migrationsstrategie. Die Portfolio-Baseline gibt Aufschluss darüber, welche Anwendungen in den Geltungsbereich der Migration fallen, und gibt Aufschluss darüber, ob die im Abschnitt Grundlegendes zu den Anforderungen an die vollständige Bewertung aufgeführten Daten erfasst wurden. Ebenso wird die gesamte zugehörige Infrastruktur (Rechen- und Speichernetzwerke) verstanden und den Anwendungen zugeordnet.

Technische Abhängigkeiten können in vier Kategorien beschrieben werden:

  • pplication-to-infrastructureA-Abhängigkeiten stellen die Verbindung zwischen Software und physischer oder virtueller Hardware her. Beispielsweise besteht eine Abhängigkeit zwischen einer CRM-Anwendung und den virtuellen Maschinen, auf denen sie installiert ist.

  • Abhängigkeiten zwischen Anwendungen und Komponenten beschreiben, wie Komponenten, die in verschiedenen Infrastrukturressourcen ausgeführt werden, interagieren. Ein Beispiel für eine Abhängigkeit von Anwendungskomponenten ist ein Web-Frontend, das auf virtuellen Maschinen ausgeführt wird, wobei eine Anwendungsebene auf einer anderen virtuellen Maschine ausgeführt wird und eine Datenbank auf einem Datenbankcluster läuft.

  • pplication-to-applicationAbhängigkeiten beziehen sich auf die Interaktion zwischen Anwendungen oder Anwendungskomponenten mit anderen Anwendungen oder deren Komponenten. Ein Beispiel für eine application-to-application Abhängigkeit ist eine Zahlungsabwicklungsanwendung und eine Lagerverwaltungsanwendung. Diese Anwendungen sind unabhängig, interagieren jedoch ständig mithilfe definierter API-Operationen.

  • Abhängigkeiten von pplication-to-infrastructure Diensten sind technisch gesehen application-to-application Abhängigkeiten, da der Infrastrukturdienst selbst eine Anwendung ist. Wir empfehlen jedoch, diese getrennt zu kategorisieren. Der Hauptgrund dafür ist, dass Infrastrukturdienste in der Regel von vielen Anwendungen gemeinsam genutzt werden, sodass sie eine lange Reihe von Abhängigkeiten aufweisen. Sie folgen in der Regel auch einer anderen Migrationsstrategie und einem anderen Migrationsmuster. Ein Load Balancer kann beispielsweise Balancing-Pools für mehrere Anwendungen enthalten. Entscheidend ist die Abhängigkeit vom Pool, der wahrscheinlich zusammen mit der abhängigen Anwendung einzeln migriert wird, während der Load Balancer selbst beibehalten oder außer Betrieb genommen wird. Darüber hinaus trägt die Individualisierung application-to-infrastructure von Dienstabhängigkeiten dazu bei, falsche Abhängigkeitsgruppen zu vermeiden. Eine falsche Abhängigkeitsgruppe liegt vor, wenn mehrere Geschäftsanwendungen gruppiert werden, was bedeutet, dass alle, die eine gemeinsame Abhängigkeit von einem Infrastrukturdienst haben, gleichzeitig migriert werden müssen. Beispielsweise sind Authentifizierungsdienste wie Active Directory wahrscheinlich mit großen Anwendungsgruppen verknüpft. Der Schlüssel liegt darin, diese Anwendungen individuell anzugehen und die Abhängigkeit zu beheben, indem der Dienst, z. B. der AWS Directory Service für Microsoft Active Directory, in der Cloud-Umgebung aktiviert wird.

Wenn Sie eine Ausgangsbasis für das Portfolio festlegen, empfehlen wir Ihnen, eine Migrationsstrategie für jede Anwendungskomponente zu bestätigen. Bei der Migrationsstrategie handelt es sich um eine der 6 Rs für die Migration (siehe Abschnitt Iteration der Migrationsstrategie mit 6 Rs). In der Portfolio-Baseline sollte jeder Anwendung einer der 6 Rs zugeordnet werden. Außerdem sollte jeder Infrastrukturkomponente der Anwendung eine 6R-Strategie zugeordnet werden.

Verwenden Sie automatisierte Discovery-Tools, um eine Basisversion des Portfolios, einschließlich Abhängigkeiten und Migrationsstrategien, zu erstellen (siehe Bewertung des Bedarfs an Discovery-Tools). Ergänzen Sie die Daten durch Informationen, die von wichtigen Stakeholdern wie Anwendungseigentümern und Infrastrukturteams gesammelt wurden. Sammeln Sie so lange Daten, bis Sie ein vollständiges Portfolioinventar erhalten haben, das den im Abschnitt mit den Datenanforderungen für diese Phase beschriebenen Eigenschaften und dem Grad an Genauigkeit entspricht. Der daraus resultierende Datensatz wird maßgeblich dazu beitragen, die Migration voranzutreiben.

Beachten Sie, dass diese Aktivität je nach Umfang Ihres Migrationsumfangs und den verfügbaren Tools mehrere Wochen in Anspruch nehmen kann.