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.
Aufgabe 4: Definition des Deep-Dive-Prozesses für Anwendungen
Nachdem Sie die Regeln und Prozesse für die Priorisierung von Anwendungen festgelegt haben, führen Sie eine eingehende Untersuchung der Anwendung durch, um die Priorität der einzelnen Anwendungen zu verfeinern. Sie führen eine eingehende Untersuchung der Anwendung für jeweils eine Anwendung durch, und zwar in der Reihenfolge von der höchsten zur niedrigsten Priorität. Bei Projekten mit mehreren Portfolio-Teams kann jedes Team gleichzeitig eine eingehende Untersuchung einer Anwendung in einer anderen Anwendung durchführen.
Während der eingehenden Untersuchung können Sie auf einige unerwartete Probleme stoßen, z. B. Abhängigkeiten, die sich auf die Komplexität der Migration der Anwendung auswirken. In diesem Fall sollten Sie Ihre Kriterien für die Komplexitätsbewertung, die Sie im vorherigen Schritt definiert haben, ändern und das Bewertungsblatt entsprechend aktualisieren, um genauere Komplexitätsbewertungen für future Anwendungen zu erhalten. Anschließend können Sie die Anwendungsprioritäten mithilfe der neuen Komplexitätswerte aktualisieren.
Diese Aufgabe besteht aus den folgenden Schritten:
Schritt 1: Definieren Sie den Ablauf des Bewerbungsworkshops
Der Workshop-Prozess ist einer der effizientesten Ansätze, um sich intensiv mit Bewerbungen auseinanderzusetzen. Mithilfe dieses Prozesses arbeiten Sie mit den Beteiligten, Anwendungseigentümern und dem Portfolioteam zusammen, um die Anwendung zu bewerten und zu analysieren. Ziel ist es, den aktuellen Status der Anwendung, einschließlich ihrer Architektur, ihres Geschäftszwecks, ihrer Abhängigkeiten und ihrer Umgebung, klar zu verstehen. Anschließend verwenden Sie diese detaillierten Informationen über die Größe und Komplexität der Anwendung, um den Zielstatus der Anwendung zu entwerfen.
Jeder Workshop dauert in der Regel 1—8 Stunden, obwohl Sie möglicherweise feststellen, dass für Anwendungen mit hoher Komplexität zusätzliche Zeit erforderlich ist. Sie können den Workshop auch in mehrere Besprechungen aufteilen, abhängig von der Verfügbarkeit der Ressourcen, Ihren Vorlieben sowie der Größe und Komplexität der Anwendung.
Identifizieren Sie die erwarteten Ergebnisse
Bevor Sie einen Bewerbungsworkshop durchführen, sollten Sie eine Agenda festlegen und die erwarteten Ergebnisse des Workshops oder Informationen definieren, die Sie im Workshop sammeln müssen. Dies ermöglicht es den Workshop-Teilnehmern, sich auf den Workshop vorzubereiten, trägt dazu bei, dass das Meeting zielgerichtet abläuft, und es wird sichergestellt, dass Sie am Ende des Workshops über alle Informationen verfügen, die für die Priorisierung, Planung und Migration der Anwendung erforderlich sind.
Wir empfehlen Ihnen, einen Standardsatz erwarteter Ergebnisse zu definieren und diese in Ihrem Runbook zur Priorisierung von Anwendungen zu dokumentieren. Bei der Vorbereitung eines Workshops verwenden Sie die erwarteten Standardergebnisse und fügen neue Ergebnisse für die spezifische Anwendung hinzu.
Definieren Sie den Standardsatz erwarteter Ergebnisse für Anwendungsworkshops wie folgt:
-
Öffnen Sie Ihr Runbook zur Priorisierung von Anwendungen.
-
Legen Sie im Abschnitt „Erwartete Ergebnisse des Anwendungsworkshops“ eine Reihe von Standardergebnissen für Anwendungsworkshops fest. Bei der Vorbereitung eines Workshops können Sie diese an die spezifischen Anforderungen der Anwendung anpassen.
-
Speichern Sie das Runbook zur Priorisierung von Anwendungen.
-
Behalten Sie die erwarteten Ergebnisse im Runbook zur Anwendungspriorisierung bei. Während Sie Anwendungsworkshops durchführen und mit der Portfoliobewertung und der Wellenplanung fortfahren, können Sie neue erwartete Ergebnisse ermitteln oder Ihre bestehenden Ergebnisse verfeinern.
Im Folgenden finden Sie Beispiele für erwartete Ergebnisse des Bewerbungsworkshops.
| Priorität | Erwartete Ergebnisse des Bewerbungsworkshops |
|---|---|
1 |
Klares Verständnis der aktuellen Architektur der Anwendung, einschließlich der zugehörigen Server, Abhängigkeiten, der Umgebung und der Anwendungsebene |
2 |
Das Team hat die Metadaten gesammelt, um den Entwurf der Zielarchitektur zu unterstützen. Die folgenden Metadaten sind erforderlich:
|
3 |
Der Fragebogen für den Inhaber der Anwendung ist vollständig und alle wichtigen Fragen wurden beantwortet. |
4 |
Das Team hat die gesamte Anwendungsdokumentation zusammengestellt, z. B. das Benutzerhandbuch, die Dokumentation zur Anwendungsarchitektur, die Testdokumentation, die Entwurfsdokumentation und die Dokumentation zur Anwendungsprogrammierschnittstelle (API). |
Definieren Sie die Regeln für den Anwendungsworkshop
Bevor Sie einen Bewerbungsworkshop durchführen, sollten Sie die Regeln festlegen, die für Ihren Workshop gelten. Zu den allgemeinen Regeln gehören die Dauer des Workshops, die Tools, die möglicherweise im Workshop benötigt werden, und alle Überlegungen zur Terminplanung oder Termine, die berücksichtigt werden müssen. Dies trägt dazu bei, dass das Meeting zielgerichtet abläuft, und es wird sichergestellt, dass die im Workshop getroffenen Entscheidungen mit dem Migrationsplan übereinstimmen.
Wir empfehlen Ihnen, die Workshop-Regeln für Anwendungen in Ihrem Runbook zur Priorisierung von Anwendungen zu dokumentieren.
Definieren Sie Ihre Workshop-Regeln für Anwendungen wie folgt:
-
Öffnen Sie Ihr Runbook zur Priorisierung von Anwendungen.
-
Definieren Sie im Abschnitt Regeln für Bewerbungsworkshops die Regeln, die für Ihre Workshops gelten.
-
Speichern Sie das Runbook zur Priorisierung von Anwendungen.
-
Behalten Sie die Regeln im Runbook zur Anwendungspriorisierung bei. Während Sie Anwendungsworkshops durchführen und mit der Portfoliobewertung und der Wellenplanung fortfahren, können Sie neue Regeln identifizieren oder Ihre bestehenden verfeinern.
Im Folgenden finden Sie Beispiele für Regeln für den Bewerbungsworkshop.
| Priorität | Workshop-Regel |
|---|---|
1 |
Die Workshops sollten dienstags und donnerstags für maximal 2 Stunden pro Sitzung geplant werden. |
2 |
Vom 1. Dezember bis 15. Januar ist ein Einfrieren der Infrastruktur geplant. |
3 |
Es gibt einen praktischen Workshop für Migrationstools. |
4 |
Der Rechenzentrumsvertrag läuft am 31. März aus. Workloads müssen bis zum 31. März evakuiert werden, um Strafen und kostspielige Vertragsverlängerungen zu vermeiden. |
5 |
Die biometrische Anwendung und die Erfassung der Zeit- und Anwesenheitserfassung werden beibehalten. |
Definieren Sie den Ablauf des Bewerbungsworkshops
Es ist wichtig, dass Sie einen Standardprozess für die Durchführung von Bewerbungsworkshops definieren. Dies gewährleistet ein einheitliches Erlebnis und setzt Erwartungen an die Workshop-Teilnehmer fest, was die Effizienz des Workshops verbessern kann.
Der Bewerbungs-Workshop-Prozess besteht aus drei Phasen:
-
Vorbereitung auf den Workshop — Die Vorbereitung auf den Workshop trägt dazu bei, dass die Sitzung reibungslos verläuft und die Teilnehmer wissen, was erwartet wird. Um sich auf den Workshop vorzubereiten, erstellen Sie eine Agenda und definieren die erwarteten Ergebnisse, Sie identifizieren die Teilnehmer, Tools und die für den Workshop benötigten Informationen und planen den Workshop. Wenn Sie den Workshop mindestens eine Woche im Voraus planen, hat das Team Zeit, seinen Terminkalender zu blockieren, sich auf den Workshop vorzubereiten und alle nützlichen Informationen zu sammeln.
-
Durchführung des Workshops — Bei der Durchführung des Workshops beschränken Sie die Diskussion auf die Tagesordnungspunkte und stellen sicher, dass Sie die erwarteten Ergebnisse erzielen. Notieren Sie sich Themen, die Sie für hilfreich halten, die aber nicht auf Ihrer Tagesordnung stehen. Es kann hilfreich sein, den Workshop aufzuzeichnen.
-
Finalisieren Sie die Workshop-Ergebnisse — Nach dem Workshop sollte Ihr Team einen klaren Überblick über den aktuellen Stand der Anwendung und über mögliche Schwachstellen, Risiken, Herausforderungen und Hindernisse haben, die sich auf die Priorisierung und Migration auswirken könnten. Zu den allgemeinen Aufgaben nach dem Workshop gehören: Neupriorisierung der Anwendung, Entwurf des future Status der Anwendung und Aktualisierung des Runbooks mit allen erwarteten Ergebnissen, Regeln oder Prozessänderungen, die für den nächsten Workshop hilfreich sein könnten.
Die Runbook-Vorlage für die Priorisierung von Anwendungen umfasst ein step-by-step Standardverfahren für die Vorbereitung, Durchführung und den Abschluss eines Anwendungsworkshops. Definieren Sie Ihren Bewerbungs-Workshop-Prozess wie folgt:
-
Öffnen Sie Ihr Runbook zur Priorisierung von Anwendungen.
-
Passen Sie im Abschnitt Ablauf des Anwendungsworkshops den Standardprozess an die Anforderungen Ihres Anwendungsfalls an.
-
Speichern Sie das Runbook zur Priorisierung von Anwendungen.
-
Behalten Sie den Prozess im Runbook zur Anwendungspriorisierung bei. Bei der Durchführung von Anwendungsworkshops können Sie feststellen, welche Änderungen Sie an diesem Prozess vornehmen möchten.
Austrittskriterien für Schritt
-
Sie haben die Workshop-Agenda sowie die Ressourcen und Artefakte definiert, die zur Unterstützung des Workshops erforderlich sind.
-
Sie haben das erwartete Ergebnis des Workshops definiert und die Informationen identifiziert, die Sie im Workshop sammeln müssen.
-
Sie haben den Workshop-Prozess getestet und verfügen über die Informationen, die Sie benötigen, um die Zuordnung der Anwendungen und die Festlegung des Zielstatus zu unterstützen.
-
Sie haben in Ihrem Runbook zur Priorisierung von Anwendungen Folgendes dokumentiert:
-
Erwartete Ergebnisse des Anwendungsworkshops
-
Regeln für den Bewerbungsworkshop
-
Ablauf des Bewerbungsworkshops
-
Schritt 2: Definieren Sie den Prozess zur Anwendungszuweisung
Bei der Anwendungszuordnung wird jeder Anwendung ein Migrationsmuster zugewiesen, das Sie in Schritt 4: Überprüfen Sie die Migrationsmuster identifiziert und validiert haben. In diesem Schritt definieren Sie die Regeln, die Sie zur Evaluierung der Anwendung verwenden werden. Anschließend definieren Sie den Prozess, den Sie zur Bewertung der einzelnen Anwendungen verwenden werden. Wenn Sie jede Anwendung dem Anwendungsfall des Migrationsmusters zuordnen, können Sie das Migrationstool, alle für die Durchführung der Migration erforderlichen Fähigkeiten und die Komplexität des Migrationsmusters identifizieren.
Sie migrieren eine Anwendung nicht immer zu einem einzigen Muster. Weitere Informationen dazu, wann Sie möglicherweise mehrere Muster für dieselbe Anwendung benötigen, finden Sie weiter Definieren Sie den Prozess der Anwendungszuordnung unten in diesem Abschnitt.
Regeln für die Anwendungszuordnung
Die Regeln für die Anwendungszuweisung helfen Ihnen dabei, die Anwendung zu bewerten und das geeignete Migrationsmuster zu identifizieren. Jede Regel besteht aus allen Informationen, die Sie verwenden sollten, um die Anwendung zu bewerten und die Kriterien für das Muster zu erfüllen.
In den Portfolio-Playbook-Vorlagen enthält die Runbook-Vorlage für die Priorisierung von Anwendungen einen Abschnitt zur Dokumentation Ihrer Anwendungszuordnungsregeln. Definieren Sie Ihren Prozess wie folgt:
-
Öffnen Sie Ihr Runbook zur Priorisierung von Anwendungen.
-
Definieren Sie im Abschnitt Regeln für die Anwendungszuweisung Ihre Anwendungszuordnungsregeln.
-
Speichern Sie das Runbook zur Priorisierung von Anwendungen.
-
Behalten Sie die Regeln im Runbook zur Anwendungspriorisierung bei.
Die folgende Tabelle enthält Beispiele für Regeln zur Anwendungszuweisung.
Anmerkung
Das Muster IDs und die Namen in dieser Tabelle entsprechen den Beispielmustern inSchritt 4: Überprüfen Sie die Migrationsmuster. Verwenden Sie das Muster IDs und die Namen, die Sie in Ihrem Runbook zur Priorisierung von Anwendungen definiert haben.
| Priorität | Zuordnungsregel |
|---|---|
1 |
Identifizieren Sie anhand von Nutzungsdaten oder Überwachungstools, ob es sich bei der Anwendung um eine Zombie-Anwendung oder eine Anwendung im Leerlauf handelt. Wenn es sich bei der Anwendung um eine Zombie- oder Inaktivanwendung handelt, wählen Sie Muster 8: Anwendung stilllegen und fahren Sie dann die Server im Anwendungsstapel herunter. |
2 |
Stellen Sie fest, ob die Migration dieser Anwendung in die Cloud einen geschäftlichen Nutzen bietet. Anwendungen, die nur vor Ort verwendet werden und nicht über Filialen oder geografische Standorte hinweg gemeinsam genutzt werden, wie z. B. Zeiterfassungsanwendungen, müssen in der Regel nicht in die Cloud migriert werden. Wenn die Migration dieser Anwendung keinen geschäftlichen Nutzen bietet, wählen Sie Pattern 9: Retain on premises. |
3 |
Stellen Sie fest, ob das Betriebssystem (OS) der Anwendung von AWS Migrationsdiensten AWS, einem Anbieter oder Ihrem Rehost-Migrationstool unterstützt wird, und gehen Sie dann wie folgt vor:
|
4 |
Stellen Sie fest, ob die Anwendung über eine SaaS-Version (Software as a Service) oder eine gleichwertige Version verfügt, und bewerten Sie dann die Vorteile und Kosten der Umstellung auf diese neue Plattform. Wenn diese Kriterien erfüllt sind, wählen Sie Muster 10: Rückkauf und Upgrade auf SaaS. |
5 |
Identifizieren Sie, ob die lokalen Datenbanken der Anwendung zu einem homogenen Service in der Cloud migriert werden können, z. B. die Migration einer lokalen Oracle-Datenbank zu Amazon RDS for Oracle oder die Migration einer lokalen MySQL-Datenbank zur Amazon Aurora MySQL-Compatible Edition-Datenbank. Wenn diese Kriterien erfüllt sind, verwenden Sie Pattern 2: Replatform to Amazon RDS mit AWS DMS und AWS SCT. |
6 |
Stellen Sie fest, ob die Anwendung Microsoft.NET Core (.NET 5 oder .NET 6), Java, PHP oder eine andere Open-Source-Programmiersprache verwendet und ob die Anwendung in Microsoft Windows Server gehostet wird. Prüfen Sie, ob die Kosten für die Umstellung der Plattform vertretbar sind. Wenn diese Kriterien erfüllt sind, wählen Sie Pattern 7: Replatform from Windows to Linux on Amazon EC2. |
7 |
Identifizieren Sie den lokalen und gemeinsam genutzten lokalen Dateispeicher, von dem Ihre Anwendung abhängig ist, und bestimmen Sie dann, ob er in die Migration einbezogen werden muss. Wenn der lokale und der gemeinsam genutzte Dateispeicher migriert werden müssen, wählen Sie Muster 4: Replatform to Amazon EFS mit AWS DataSync oder. AWS Transfer Family |
8 |
Stellen Sie fest, ob es sich bei den Servern der Anwendung um Mainframe- oder Midrange-Server wie IBM AS/400 oder Apache Spark handelt, und stellen Sie sicher, dass die Anwendungen mit Emulatoren kompatibel sind. Wenn diese Kriterien erfüllt sind, verwenden Sie Pattern 6: Replatform Mainframe- oder Midrange-Server mithilfe eines Emulators auf Amazon EC2 umstellen. |
9 |
Stellen Sie fest, ob es sich um eine ältere, monolithische oder Mainframe-basierte Anwendung handelt, die aufgrund ihrer Einschränkungen die Anforderungen des Unternehmens nicht mehr erfüllen kann. Ermitteln Sie beispielsweise, ob die Anwendung skalierbar ist, sich in verwandte Anwendungen integrieren lässt oder teuer und schwierig zu warten ist. Wenn die Anwendung eines dieser Kriterien erfüllt, wählen Sie Pattern 11: Re-Architect the application. |
Definieren Sie den Prozess der Anwendungszuordnung
Wenn Sie Anwendungen den Migrationsmustern zuordnen, ist es hilfreich, vom Discovery-Team Discovery-Daten für die Anwendung anzufordern. Diese Daten enthalten in der Regel Informationen wie ein empfohlenes Migrationsmuster (manchmal auch R-Muster oder R-Score genannt), Nutzungsinformationen, Anwendungsabhängigkeiten und andere Informationen, die Sie bei der Bewertung verwenden können. Wenn Sie sich eingehend mit dieser Anwendung befassen, entscheiden Sie sich möglicherweise dafür, das zuvor identifizierte Migrationsmuster zu ändern.
Wenn Sie über die Daten verfügen, können Sie die Anwendung mit den geschäftlichen und technischen Kriterien vergleichen, die Sie in angegeben habenSchritt 2: Identifizieren Sie die geschäftlichen und technischen Faktoren. Sie haben Ihre Treiber in Ihrem Runbook zur Priorisierung von Anwendungen aufgezeichnet. Wenn Sie die Anwendung anhand der Kriterien bewerten, müssen Sie möglicherweise mehrere Migrationsmuster für die Anwendung auswählen, oder Sie können Muster aufgrund von Kosten, Zeitplan oder anderen Einschränkungen eliminieren.
Im Folgenden finden Sie ein Beispiel für einen Geschäftstreiber, bei dem Sie mehrere Migrationsmuster in einer einzigen Anwendung verwenden müssen. Sie möchten eine lokale SQL Server-Datenbank zu Amazon DynamoDB migrieren, aber da der Vertrag für das Rechenzentrum ausläuft, möchte das Unternehmen sie früher als geplant migrieren, um sie neu zu plattformieren. Um diesem Geschäftstreiber Rechnung zu tragen, überarbeiten Sie den Migrationsplan für die Anwendung und verfolgen nun einen zweistufigen Ansatz. Zunächst hosten Sie die Anwendung erneut in der Cloud, um sie aus dem Rechenzentrum zu entfernen. Später, nachdem sich die Anwendung in der Cloud befindet, können Sie sie gemäß dem vorgeschlagenen Zeitplan auf eine neue Plattform umstellen.
Sie sollten auch berücksichtigen, ob es sich bei der Anwendung um eine n-Tier-Anwendung handelt, d. h. um eine Anwendung, die aus mehreren Ebenen besteht. Eine Anwendungsebene ist eine Gruppe von physischen Servern, die horizontale Ebenen Ihrer Anwendung hosten. N-Tier-Anwendungen sind komplexer, da für jede Ebene möglicherweise eine andere Strategie erforderlich ist und Sie die Anwendungsebenen möglicherweise in verschiedenen Wellen migrieren möchten. Wenn Sie beispielsweise über eine Anwendung verfügen, die aus Präsentations-, Business Service- und Datenbankebenen besteht, besteht die Möglichkeit, dass Sie jeder Ebene ein anderes Muster zuordnen können.
Anschließend bewerten Sie die Anwendung anhand Ihrer Anwendungszuordnungsregeln, die Sie in Ihrem Runbook zur Anwendungspriorisierung definiert haben. Weitere Informationen finden Sie in Regeln für die Anwendungszuordnung weiter oben in diesem Abschnitt.
Nachdem Sie Ihre Anwendung einem oder mehreren Mustern zugeordnet haben, überprüfen und verifizieren Sie diese Entscheidung mit dem Anwendungseigentümer. Der Anwendungseigentümer sollte das ausgewählte Muster bestätigen und Ihnen bei der Planung und Durchführung der Migration behilflich sein. Zu diesem Zeitpunkt können Anwendungsbesitzer auch Einblicke geben, die auf ihren Erfahrungen basieren, oder über Probleme, die sie im Zusammenhang mit der Migration erwarten, berichten.
Wenn Sie die Anwendung einem oder mehreren Migrationsmustern zugeordnet und die Muster mit dem Anwendungseigentümer bestätigt haben, notieren Sie die Anwendung, die Muster-ID, den Musternamen und die relevanten Treiber in einer Anwendungszuordnungstabelle in Ihrem Runbook zur Anwendungspriorisierung.
In den Portfolio-Playbook-Vorlagen umfasst die Runbook-Vorlage für die Priorisierung von Anwendungen einen Standardprozess für die Anwendungszuweisung. step-by-step Definieren Sie Ihren Prozess wie folgt:
-
Öffnen Sie Ihr Runbook zur Priorisierung von Anwendungen.
-
Passen Sie im Abschnitt Ablauf des Anwendungsworkshops den Standardprozess an die Anforderungen Ihres Anwendungsfalls an.
-
Speichern Sie das Runbook zur Priorisierung von Anwendungen.
-
Behalten Sie den Prozess im Runbook zur Anwendungspriorisierung bei.
Die folgende Tabelle ist ein Beispiel für eine Anwendungszuordnungstabelle. Die bereitgestellte Runbook-Vorlage für die Priorisierung von Anwendungen enthält eine leere Tabelle, in der Sie Ihre Ergebnisse aus dem Anwendungszuordnungsprozess aufzeichnen können.
Anmerkung
Das Muster IDs und die Namen in dieser Tabelle entsprechen den Beispielmustern in. Schritt 4: Überprüfen Sie die Migrationsmuster Verwenden Sie das Muster IDs und die Namen, die Sie in Ihrem Runbook zur Priorisierung von Anwendungen definiert haben.
| Anwendungsname | Muster-ID | Name des Musters | Geschäftliche und technische Faktoren wurden angesprochen |
|---|---|---|---|
Website des Unternehmens |
1 |
Rehosten Sie mithilfe von Application Migration Service oder Cloud Migration Factory auf Amazon EC2 |
|
HR-System |
8 |
Die Anwendung zurückziehen |
|
Beantragung von Zeit und Anwesenheit |
9 |
Vor Ort aufbewahren |
|
PO-System |
3 |
Replatform zu Amazon EC2 mit CloudFormation |
|
CRM-System |
10 |
Rückkauf und Upgrade auf SaaS |
|
System des Anlagevermögens |
7 |
Replatform von Windows auf Linux auf Amazon EC2 |
|
ERP-Dateispeicher |
4 |
Umstieg auf Amazon EFS mithilfe von oder AWS DataSync AWS Transfer Family |
|
Ledger-System |
6 |
Rehosten Sie Mainframe- oder Midrange-Server mithilfe eines Emulators auf Amazon EC2 |
|
Hauptbuch |
11 |
Gestalten Sie die Anwendung neu |
|
Austrittskriterien für Schritt
-
Sie haben in Ihrem Runbook zur Priorisierung von Anwendungen Folgendes dokumentiert:
-
Regeln für die Anwendungszuordnung
-
Verfahren zur Zuordnung von Anwendungen
-
-
Sie haben die Zuordnungsregeln und -prozesse mithilfe einer oder mehrerer proof-of-concept (POC) -Anwendungen validiert.
Schritt 3: (Optional) Definieren Sie den Zielstatus der Anwendung
In diesem Schritt definieren Sie die Attribute und den Prozess, mit dem Sie den Zielstatus oder zukünftigen Status der Anwendung dokumentieren. Der Zielstatus gibt an, wie die Anwendung nach der Migration in der Ziel-Cloud-Umgebung funktioniert. Die Zielumgebung hängt von Ihrer Zielplattform oder Ihrem Service und Ihren Geschäftsanforderungen ab. Die Zielumgebung könnte das AWS Cloud oder AWS Managed Services (AMS) sein.
Die Definition des Zielstatus hilft Projektmanagern, Migrationsberatern, Architekten, Anwendungseigentümern und Stakeholdern, effektiv zusammenzuarbeiten. Mithilfe dieses Prozesses kann das Team Probleme im Voraus identifizieren und lösen und die Zielzustandsumgebung effizienter implementieren.
Für einige Anwendungen ist dieser Schritt optional. Sie können diesen Schritt überspringen, wenn es sich bei der Anwendung, die Sie migrieren, um eine eigenständige Anwendung oder um eine Anwendung mit geringer Komplexität handelt. Bei Migrationsstrategien, bei denen die Anwendung nicht verändert wird, z. B. beim Rehost, ist dieser Schritt möglicherweise nicht erforderlich. Bei komplexeren Migrationsstrategien wie Replatform und Re-Architect sollten Sie jedoch den Zielstatus definieren, bevor Sie mit der Migration beginnen.
Der Workshop vermittelt Ihnen ein tiefes Verständnis des aktuellen Status der Anwendung. Es empfiehlt sich daher, den Zielstatus nach Abschluss des Workshops zu entwerfen. Darüber hinaus bietet die Zuordnung der Anwendung zu ihrem Migrationsmuster zusätzliche Erkenntnisse und hilft Ihnen zu erkennen, ob eine Definition des Zielstatus erforderlich ist. Wenn Sie die Anwendung beispielsweise mithilfe von Application Migration Service oder Cloud Migration Factory dem Muster Rehost to Amazon EC2 zuordnen, haben Sie festgestellt, dass die Strategie Rehost lautet, und Sie müssen den Zielstatus für diese Anwendung wahrscheinlich nicht definieren.
Attribute für den Zielstatus
Wir empfehlen Ihnen, bei der Definition des Zielstatus und bei Entscheidungen über die Anwendung die folgenden Zielstatusattribute zu berücksichtigen:
-
AWS Well-Architected Tool— Vergleichen Sie den Zielstatus der Anwendung mit dem AWS Well-Architected Framework, um die Sicherheit, Leistung und Belastbarkeit der Anwendung in der Cloud zu verbessern.
-
Ziellandezone — In der Regel sollten Sie bis zum Ende der Mobilisierungsphase eine komplette landing zone eingerichtet haben, die für die Durchführung von Pilotanwendungen bereit ist. Die landing zone sollte bereits mit einer Architektur für mehrere Konten, Identitäts- und Zugriffsmanagement, Governance, Datensicherheit, Netzwerkdesign und Protokollierung konfiguriert sein. Sie verwenden eine Pilotanwendung, um zu überprüfen, ob die landing zone vollständig ist. Stellen Sie sicher, dass Sie Ihre Pilotanwendung in der vorhandenen Ziellandzone starten und ausführen können. Wenn Sie die landing zone für die Anwendung ändern müssen, informieren Sie das Landezone-Team über Ihre Anforderungen. Beispielsweise benötigt Ihre Anwendung möglicherweise Zugriff auf einen Dienst, der in einem separaten Konto gehostet wird, oder Ihre Anwendung erfordert möglicherweise ein spezielles Routing zu einer Virtual Private Cloud (VPC).
-
Abhängigkeiten — Identifizieren Sie alle Anwendungen, auf die Ihre Anwendung angewiesen ist, um ordnungsgemäß zu funktionieren. Beispielsweise ist Ihre Anwendung möglicherweise von Datenbanken, Speichern oder Diensten von Drittanbietern abhängig, z. B. einem Zahlungsgateway oder einem externen Webdienst, oder Ihre Anwendung ist möglicherweise von anderen Anwendungen in Ihrer Umgebung abhängig. Um auf diese Abhängigkeiten zugreifen zu können, benötigen Sie möglicherweise ein spezielles Routing oder eine spezielle Konfiguration, z. B. eine Verbindung zu einem Verzeichnisdienst zur Authentifizierung.
-
Abhängige Anwendungen — Identifizieren Sie alle Anwendungen, die auf Ihre Anwendung angewiesen sind, um ordnungsgemäß zu funktionieren. Möglicherweise müssen Sie diese Anwendungen neu konfigurieren und aktualisieren, um Ausfallzeiten während der Migration zu vermeiden.
-
Sicherheit und Compliance — Überprüfen Sie die Zielumgebung zusammen mit dem Sicherheits- und Compliance-Team und identifizieren Sie etwaige Lücken. Die Anwendung kann aus mehreren Komponenten, logischen Schichten oder mehreren Ebenen bestehen. Je nach Ihren Compliance-Anforderungen sind Sie möglicherweise nicht in der Lage, einige dieser Komponenten in Ihre Zielumgebung zu migrieren, oder Sie benötigen möglicherweise zusätzliche Sicherheitsmaßnahmen, wenn Sie den Workload migrieren. Zu den allgemeinen Sicherheits- und Compliance-Anforderungen gehören die Aufbewahrung von Daten, Verschlüsselung bei der Übertragung und Verschlüsselung im Ruhezustand. Diese erfordern eine zusätzliche Konfiguration in Ihrer Zielumgebung. Beispielsweise müssen Sie möglicherweise Zertifikate konfigurieren, um die Kommunikation zu sichern, oder Sie benötigen möglicherweise Verschlüsselungsschlüssel, um die Daten im Ruhezustand zu sichern. Möglicherweise müssen Sie auch mehrere Migrationsmuster für die Anwendung auswählen, sodass einige Anwendungsebenen lokal bleiben und andere Ebenen in die Cloud migriert werden.
-
Speicherabhängigkeiten — Überprüfen Sie die Speicherabhängigkeiten Ihrer Anwendungen und ermitteln Sie, wie sich die Migration der Anwendung in die Zielumgebung auf diese Abhängigkeiten auswirken würde. Wenn die Anwendung beispielsweise von Netzwerkspeicher wie Network Attached Storage (NAS) oder einem Storage Area Network (SAN) abhängig ist, müssen Sie einen Speicherdienst in der Cloud wie Amazon Simple Storage Service (Amazon S3) oder Amazon einplanen. FSx Sie müssen auch planen, wie Sie Ihre Daten in die Ziel-Cloud-Umgebung migrieren, damit Ihre Anwendung am Laufen bleibt.
-
Datenbank — Überprüfen Sie die Migrationsstrategie für alle Datenbanken, die die Anwendung verwendet. Werden Sie auf einen neuen Datenbankservice wie Amazon Relational Database Service (Amazon RDS), Amazon Aurora oder Amazon DynamoDB umsteigen? Werden Sie Ihre Datenbank in der Zielumgebung rehosten? In einigen Fällen, insbesondere bei einer monolithischen Datenbank, müssen Sie die Datenbank umgestalten, um technischen Anforderungen wie Latenz unter einer Sekunde gerecht zu werden oder um die Funktionen eines bestimmten Datenbanktyps zu nutzen. AWS Wie bei den Anforderungen an die Datenresidenz müssen Sie festlegen, welche Daten vor Ort aufbewahrt und welche in die Cloud migriert werden sollten. Beispielsweise müssen Sie möglicherweise eine lokale Datenbanktabelle für Kundeninformationen beibehalten und den Rest der Datenbank in die Cloud migrieren.
-
Anwendungskomponenten — Überprüfen Sie die Komponenten, von denen Ihre Anwendung abhängt. Stellen Sie fest, ob Ihre Anwendung von einer Komponente abhängt, die von der Zielumgebung nicht unterstützt wird. Wenn die Zielumgebung nicht alle Anwendungskomponenten unterstützt, müssen Sie die Anwendung umgestalten, um das Problem zu beheben. Wenn Sie beispielsweise über eine .NET Framework-Anwendung verfügen, die nur von Windows-Komponenten wie Component Object Model (COM) Interop, COM+ oder der Windows-Registrierung abhängig ist, müssen Sie die Anwendung auf .NET Core umgestalten, um die Anwendung auf einem Linux-Betriebssystem neu zu plattformieren.
-
Anwendungsebenen — Identifizieren Sie die Anzahl der Ebenen in Ihrer Anwendung. Handelt es sich bei der Anwendung um eine n-stufige, zweistufige oder eigenständige Anwendung? Vergewissern Sie sich, dass Sie das Migrationsmuster für jede Stufe verstehen. Beispielsweise könnte Ihre Anwendung über eine Präsentations- (oder Web -) Ebene verfügen, die die Benutzeroberfläche hostet, eine Anwendungsebene, die Unternehmensdienste hostet, und eine Datenbankebene, die Datenbanken hostet, und für jede Ebene ist möglicherweise ein anderes Migrationsmuster erforderlich.
-
Disaster Recovery — Identifizieren Sie den aktuellen und zukünftigen Disaster Recovery (DR) -Plan der Anwendung, einschließlich Recovery Point Objective (RPO) und Recovery Time Objective (RTO). Entscheiden Sie, ob Sie den vorhandenen lokalen DR-Plan verwenden oder eine neue DR-Strategie in der Cloud ausprobieren möchten. Weitere Informationen finden Sie in den Abschnitten Disaster Recovery-Optionen in der Cloud und Wiederherstellungsziele (RTO und RPO) im Whitepaper Disaster Recovery of Workloads auf AWS: Recovery in the Cloud.
Definieren Sie den Zielzustandsprozess
Um den Zielstatus der Anwendung zu definieren, empfehlen wir Ihnen, die bereitgestellte Vorlage, Arbeitsblatt zum Zielstatus der Anwendung (Excel-Format), zu verwenden, die in den Portfolio-Playbook-Vorlagen verfügbar ist. Die Vorlage enthält Standardattribute, die Sie verwenden oder ändern können. Definieren Sie den Prozess zur Dokumentation des Zielstatus der Anwendung wie folgt:
-
Öffnen Sie das Arbeitsblatt mit dem Zielstatus der Anwendung.
-
Überprüfen Sie die Standardattribute und nehmen Sie alle Änderungen für Ihren Anwendungsfall vor.
-
Speichern Sie das Arbeitsblatt.
-
Öffnen Sie Ihr Runbook zur Anwendungspriorisierung.
-
Gehen Sie im Abschnitt Status der Zielanwendung wie folgt vor:
-
Legen Sie im Abschnitt Wann dieser Prozess abgeschlossen sein muss, Kriterien fest, anhand derer das Portfolioteam bestimmen kann, ob es den Zielstatus der Anwendung definieren muss.
-
Aktualisieren Sie den Attributabschnitt nach Bedarf.
-
Aktualisieren Sie den Prozessabschnitt nach Bedarf für Ihren Anwendungsfall.
-
-
Speichern Sie das Runbook zur Anwendungspriorisierung.
Beispiele für den Zielstatus der Anwendung
Die folgende Tabelle zeigt ein Beispiel dafür, wie Sie das Arbeitsblatt Anwendungszielstatus verwenden, um den Zielstatus der Anwendung zu dokumentieren.
| Anwendung | Beispiel |
|---|---|
Zielplattform |
AWS Cloud |
Landezone |
Erfordert Zugriff auf einen lokalen Verzeichnisdienst Erfordert AWS Control Tower die zentralisierte Verwaltung mehrerer Konten und Dienste im gesamten Unternehmen |
Abhängigkeiten |
Active Directory, Zahlungsgateway, Inventarsystem |
Abhängige Anwendungen |
Keine |
Sicherheit |
Verschlüsselung bei Speicherung und Übertragung |
Compliance |
PCI, SOC |
Speicherabhängigkeiten |
Startlaufwerk angeschlossen, NAS, Netzwerkfreigabe |
Datenbank |
Aktuell: Oracle DB Cloud: Amazon RDS for Oracle |
Komponente der Anwendung |
.NET Framework 4.5 |
Anwendungsebenen |
N-stufig Frontend, Unternehmensdienste, Datendienste und Agenten, Datenbank |
Wiederherstellung nach einem Notfall |
RPO: 1 Minute, RTO: 5 Minuten Die aktuelle DR-Strategie ist Warm-Standby DR in allen US-Regionen |
Austrittskriterien für Schritt
-
Im Arbeitsblatt Zielstatus der Anwendung haben Sie die Attribute definiert, die Sie in den Zielstatusprozess einbeziehen möchten.
-
In Ihrem Runbook zur Priorisierung von Anwendungen haben Sie Folgendes getan:
-
Sie haben Kriterien dafür festgelegt, wann das Portfolio-Team voraussichtlich den Zielstatus der Anwendung festlegen wird.
-
Sie haben den Prozess zur Definition des Zielstatus auf der Grundlage Ihres Anwendungsfalls aktualisiert.
-
Schritt 4: Schließen Sie den detaillierten Bewerbungsprozess ab
Jetzt definieren Sie, wie der Portfolio-Workstream den Workshop, die Regeln und Prozesse, die Sie in dieser Aufgabe festgelegt haben, verwendet, um sich eingehend mit der Anwendung zu befassen. Auf diesen Prozess bezieht sich der Portfolio-Workstream in der Implementierungsphase der Migration.
Passen Sie diesen Prozess im Runbook zur Anwendungspriorisierung wie folgt an:
-
Öffnen Sie Ihr Runbook zur Anwendungspriorisierung.
-
Passen Sie im Abschnitt Phase 2: Ausführliche Informationen zur Anwendung an, wie es für Ihren Anwendungsfall und Ihre Umgebung erforderlich ist.
-
Speichern Sie das Runbook zur Anwendungspriorisierung.
-
Teilen Sie dem Team Ihr Runbook zur Priorisierung von Anwendungen zur Überprüfung mit.
