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.
AWS Anwendungsdesign und Migrationsstrategie
Das Entwerfen und Dokumentieren des future Zustands Ihrer Anwendung ist ein wichtiger Erfolgsfaktor für die Migration. Wir empfehlen, ein Design für jede Art von Migrationsstrategie zu erstellen, unabhängig davon, wie einfach oder komplex sie ist. Bei der Erstellung des Designs werden potenzielle Hindernisse, Abhängigkeiten und Möglichkeiten zur Optimierung der Anwendung selbst in Fällen aufgedeckt, in denen keine Änderung der Architektur zu erwarten ist.
Wir empfehlen außerdem, den future Status der Anwendung unter Berücksichtigung AWS einer Migrationsstrategie zu betrachten. Stellen Sie zu diesem Zeitpunkt sicher, dass Sie definieren, wie die Anwendung AWS als Ergebnis dieser Migration aussehen wird. Das daraus resultierende Design wird als Grundlage für die weitere Entwicklung nach der Migration dienen.
Die folgende Liste enthält Ressourcen zur Unterstützung des Entwurfsprozesses:
-
AWS Das Architecture Center
kombiniert Tools und Anleitungen wie das AWS Well-Architected Framework. Außerdem bietet es Referenzarchitekturen, die Sie für Ihre Anwendung verwenden können. -
Die Amazon Builders' Library
enthält mehrere Ressourcen darüber, wie Amazon Software entwickelt und betreibt. -
AWS Die Solutions Library
bietet eine Sammlung von Cloud-basierten Lösungen, die von uns geprüft wurden AWS, für Dutzende von technischen und geschäftlichen Problemen. Sie umfasst eine große Sammlung von Referenzarchitekturen. -
AWS Prescriptive Guidance
bietet Strategien, Leitfäden und Muster, die den Entwurfsprozess und bewährte Verfahren für die Migration unterstützen. -
AWS Die Dokumentation enthält Informationen zu AWS Diensten, einschließlich Benutzerhandbüchern und API Referenzen.
-
Das Ressourcencenter für die ersten Schritte
bietet mehrere praktische Tutorials und ausführliche Informationen zum Erlernen der Grundlagen, sodass Sie sofort darauf aufbauen können. AWS
Je nachdem, wo Sie sich auf dem Weg zur Cloud befinden, gibt es möglicherweise bereits AWS Grundlagen. Zu diesen AWS Grundlagen gehören die folgenden:
-
AWS Regionen wurden identifiziert.
-
Konten wurden erstellt oder können auf Anfrage bezogen werden.
-
Allgemeine Netzwerke wurden implementiert.
-
Innerhalb der Konten wurden grundlegende AWS Dienste bereitgestellt.
Umgekehrt befinden Sie sich möglicherweise noch in einem frühen Stadium des Prozesses, und die AWS Grundlagen sind noch nicht geschaffen. Ein Mangel an fundierten Grundlagen könnte den Umfang Ihres Anwendungsdesigns einschränken oder weitere Arbeiten zu deren Definition erfordern. In diesem Fall empfehlen wir, das grundlegende Design der landing zone parallel zum Anwendungsdesign zu definieren und umzusetzen. Das Anwendungsdesign hilft dabei, Anforderungen wie AWS Kontostruktur, Netzwerke, virtuelle private Cloud (VPCs), Classless Inter-Domain Routing (CIDR) -Bereiche, gemeinsame Dienste, Sicherheit und Cloud-Betrieb zu identifizieren.
AWS Control Tower
future Status der Anwendung
Legen Sie zunächst die anfängliche Migrationsstrategie für diese Anwendung fest. Zum jetzigen Zeitpunkt gilt die Strategie als initiativ, da sie sich im Rahmen der future Staatsgestaltung ändern könnte, wodurch potenzielle Einschränkungen aufgedeckt werden können. Informationen zur Bestätigung der ursprünglichen Annahmen finden Sie im Entscheidungsbaum mit 6 Rs. Dokumentieren Sie auch mögliche Migrationsphasen. Wird diese Anwendung beispielsweise in einem einzigen Ereignis migriert (alle Komponenten werden gleichzeitig migriert)? Oder handelt es sich um eine schrittweise Migration (einige Komponenten werden später migriert)?
Beachten Sie, dass die Migrationsstrategien für eine bestimmte Anwendung möglicherweise nicht eindeutig sind. Dies liegt daran, dass mehrere R-Typen verwendet werden könnten, um die Anwendungskomponenten zu migrieren. Der erste Ansatz könnte beispielsweise darin bestehen, die Anwendung ohne Änderungen nach oben zu verschieben. Die Komponenten einer Anwendung können sich jedoch in unterschiedlichen Infrastrukturressourcen befinden, für die möglicherweise unterschiedliche Behandlungen erforderlich sind. Eine Anwendung besteht beispielsweise aus drei Komponenten, die jeweils auf einem separaten Server ausgeführt werden, und auf einem der Server läuft ein veraltetes Betriebssystem, das in der Cloud nicht unterstützt wird. Für diese Komponente ist ein Replattform-Ansatz erforderlich, während die anderen beiden Komponenten, die in unterstützten Serverversionen ausgeführt werden, erneut gehostet werden können. Es ist wichtig, jeder Anwendungskomponente und der zugehörigen Infrastruktur, die migriert wird, eine Migrationsstrategie zuzuweisen.
Dokumentieren Sie als Nächstes den Kontext und das Problem und verknüpfen Sie vorhandene Artefakte, die den aktuellen Status definieren:
-
Warum wird diese Anwendung migriert?
-
Was sind die vorgeschlagenen Änderungen?
-
Was sind die Vorteile?
-
Gibt es irgendwelche größeren Risiken oder Hindernisse?
-
Was sind die aktuellen Nachteile?
-
Was ist im Geltungsbereich und was außerhalb des Geltungsbereichs?
Wiederholbarkeit
Denken Sie während der gesamten Entwurfsarbeit darüber nach, wie diese Lösung und Architektur für diese Anwendung für andere Anwendungen wiederverwendet werden können. Kann diese Lösung verallgemeinert werden?
Voraussetzungen
Dokumentieren Sie die funktionalen und nichtfunktionalen Anforderungen für diese Anwendung, einschließlich der Sicherheit. Dies beinhaltet aktuelle und future staatliche Anforderungen, abhängig von der gewählten Migrationsstrategie. Orientieren Sie sich bei diesem Prozess an den Informationen, die im Rahmen der ausführlichen Bewerbungsbeurteilung gesammelt wurden.
Architektur der Zukunft
Beschreiben Sie die future Architektur für diese Anwendung. Erwägen Sie, eine wiederverwendbare Schemavorlage zu erstellen, die Bausteine für Ihre Quellumgebung (lokal) und AWS Zielumgebung (z. B. AWS ZielregionVPCs, Konto und Availability Zones) enthält.
Erstellen Sie eine Tabelle mit Komponenten, die migriert werden, und Komponenten, die neu sein werden. Schließen Sie andere Anwendungen und Dienste (entweder lokal oder in der Cloud) ein, die mit dieser Anwendung interagieren.
In der folgenden Tabelle sind Beispielkomponenten aufgeführt. Sie stellt keine Referenzarchitektur oder geprüfte Konfiguration dar.
Name |
Beschreibung |
Details |
---|---|---|
Anwendung |
Externer Dienst (eingehende Verbindung) |
Der Dienst verwendet Daten von exponierten Daten. API |
DNS |
Namensauflösung (intern) |
Amazon Route 53 wurde als Teil der Basiskontoeinstellungen bereitgestellt |
Application Load Balancer |
Verteilt den Verkehr auf die Back-End-Dienste |
Ersetzt den lokalen Load Balancer. Migrieren Sie Pool A. |
Anwendungssicherheit |
DDoS-Schutz |
Implementiert mit AWS Shield |
Sicherheitsgruppe |
Virtuelle Firewall |
Beschränken Sie den Zugriff auf Anwendungsinstanzen auf Port 443 (eingehend). |
Server A |
Frontend |
Rehosten Sie mithilfe von Amazon Elastic Compute Cloud (AmazonEC2). |
Server B |
Frontend |
Rehosten Sie mit AmazonEC2. |
Server C |
Anwendungslogik |
Rehosten Sie mit AmazonEC2. |
Server D |
Anwendungslogik |
Rehosten Sie mit AmazonEC2. |
Amazon Relational Database Service (AmazonRDS) — Amazon Aurora |
Datenbank |
Ersetzt die Server E und F |
Überwachen und Warnen |
Steuerung ändern |
Amazon CloudWatch |
Audit-Protokollierung |
Kontrolle ändern |
AWS CloudTrail |
Patchen und Fernzugriff |
Wartung |
AWS Systems Manager |
Resource access (Ressourcenzugriff) |
Sichere Zugriffskontrolle |
AWS Identity and Access Management (IAM) |
Authentifizierung |
Benutzerzugriff |
Amazon Cognito |
Zertifikate |
SSL/TLS |
AWS Certificate Manager |
API1 |
Extern API |
APIAmazon-Gateway |
Objektspeicher |
Hosting von Bildern |
Amazon-Simple-Storage-Service (Amazon-S3) |
Anmeldeinformationen |
Verwaltung und Hosting von Anmeldeinformationen |
AWS Secrets Manager |
AWS Lambda Funktion |
Abrufen von Datenbankanmeldedaten und Schlüsseln API |
AWS Lambda |
Internet-Gateway |
Ausgehender Internetzugang |
Internet-Gateway zu einem VPC |
Privates Subnetz 1 |
Backend und DB |
Verfügbarkeitszone 1 — VPC 1 |
Privates Subnetz 2 |
Backend und DB |
Verfügbarkeitszone 2 — VPC 1 |
Öffentliches Subnetz 1 |
Frontend |
Verfügbarkeitszone 1 — VPC 1 |
Öffentliches Subnetz 2 |
Frontend |
Verfügbarkeitszone 2 — VPC 1 |
Backup-Dienste |
Datenbanken und EC2 Instanz-Backup |
AWS Backup |
DR |
EC2Resilienz von Amazon |
AWS Elastic Disaster Recovery |
Nachdem die Komponenten identifiziert wurden, zeichnen Sie sie mit Ihrem bevorzugten Tool in einem Diagramm auf. Teilen Sie den ursprünglichen Entwurf mit den wichtigsten Stakeholdern der Anwendung, einschließlich Anwendungseigentümern, Unternehmensarchitekten und den Plattform- und Migrationsteams. Erwägen Sie, die folgenden Fragen zu stellen:
-
Ist das Team generell mit dem Design einverstanden?
-
Können die Betriebsteams es unterstützen?
-
Kann das Design weiterentwickelt werden?
-
Gibt es andere Optionen?
-
Entspricht das Design den Architekturstandards und Sicherheitsrichtlinien?
-
Fehlen Komponenten (z. B. Code-Repositorys, CI/CD-Tools, Endpunkte)? VPC
Architektonische Entscheidungen
Im Rahmen des Entwurfsprozesses werden Sie wahrscheinlich mehr Optionen für die Gesamtarchitektur oder bestimmte Teile davon finden. Dokumentieren Sie diese Optionen zusammen mit der Begründung für eine bevorzugte oder ausgewählte Option. Diese Entscheidungen können als architektonische Entscheidungen dokumentiert werden.
Stellen Sie sicher, dass die wichtigsten Optionen so detailliert aufgeführt und beschrieben werden, dass ein neuer Leser die Optionen und Gründe für die Entscheidung, eine Option einer anderen vorzuziehen, verstehen kann.
Umgebungen im Softwarelebenszyklus
Dokumentieren Sie alle Änderungen an aktuellen Umgebungen. Beispielsweise werden Test- und Entwicklungsumgebungen in neu erstellt AWS und nicht migriert.
Tagging
Beschreiben Sie die obligatorische und empfohlene Kennzeichnung für jede Infrastrukturkomponente sowie den Tagging-Wert für diesen Entwurf.
Migrationsstrategie
Zu diesem Zeitpunkt des Entwurfs sollten die ursprünglichen Annahmen zur Migrationsstrategie validiert sein. Bestätigen Sie, dass ein Konsens über die gewählte R-Strategie besteht. Dokumentieren Sie die allgemeine Strategie zur Anwendungsmigration und die Strategien für einzelne Anwendungskomponenten. Wie bereits erwähnt, benötigen verschiedene Anwendungskomponenten möglicherweise unterschiedliche R-Typen für die Migration.
Darüber hinaus sollten Sie die Migrationsstrategie an den wichtigsten Geschäftsfaktoren und Ergebnissen ausrichten. Beschreiben Sie außerdem alle schrittweisen Migrationsansätze, z. B. die Verschiebung von Komponenten im Rahmen verschiedener Migrationsereignisse.
Weitere Informationen zur Bestimmung Ihrer 6 Rs finden Sie in den AWS Migration Hub Strategieempfehlungen
Migrationsmuster und Tools
Mit einer definierten Migrationsstrategie für die Anwendungs- und Infrastrukturkomponenten können Sie nun spezifische technische Muster untersuchen. Eine Rehost-Strategie kann beispielsweise mithilfe von Migrationstools wie dem AWS Application Migration
In ähnlicher Weise können Sie Tools wie AWS
App2Container
Bewerten Sie die verschiedenen Muster und Optionen, die zur Erreichung des Ziels zur Verfügung stehen. Berücksichtigen Sie die Vor- und Nachteile sowie die Einsatzbereitschaft der Migration. Verwenden Sie die folgenden Fragen, um Ihnen bei Ihrer Analyse zu helfen:
-
Können Migrationsteams diese Muster unterstützen?
-
Wie ist das Gleichgewicht zwischen Kosten und Nutzen?
-
Kann diese Anwendung, dieser Dienst oder diese Komponente in einen verwalteten Dienst verschoben werden?
-
Wie hoch ist der Aufwand, dieses Muster zu implementieren?
-
Gibt es Vorschriften oder Compliance-Richtlinien, die die Verwendung eines bestimmten Musters verhindern?
-
Kann dieses Muster wiederverwendet werden? Wiederverwendbare Muster werden bevorzugt. Manchmal wird ein Muster jedoch nur einmal verwendet. Erwägen Sie das Gleichgewicht zwischen dem Aufwand eines Einwegmusters und einem alternativen wiederverwendbaren Muster.
AWS Prescriptive Guidance
Servicemanagement und Betrieb
Bei der Erstellung von Anwendungsentwürfen für die Migration zu AWS sollten Sie die Betriebsbereitschaft berücksichtigen. Berücksichtigen Sie bei der Bewertung der Bereitschaftsanforderungen mit Ihren Anwendungs- und Infrastrukturteams die folgenden Fragen:
-
Sind sie bereit, es in Betrieb zu nehmen?
-
Sind Verfahren zur Reaktion auf Vorfälle definiert?
-
Was ist das erwartete Service Level Agreement (SLA)?
-
Ist eine Aufgabentrennung erforderlich?
-
Sind die verschiedenen Teams bereit, die Unterstützungsmaßnahmen zu koordinieren?
-
Wer ist wofür verantwortlich?
Überlegungen zur Umstellung
Was ist angesichts der Migrationsstrategie und der Migrationsmuster wichtig zu wissen, wenn die Anwendung migriert wird? Die Umstellungsplanung ist eine Aktivität, die erst nach dem Entwurf erfolgt. Dokumentieren Sie jedoch alle Überlegungen zu Aktivitäten und Anforderungen, die erwartet werden können. Dokumentieren Sie beispielsweise die Anforderung, gegebenenfalls einen Machbarkeitsnachweis durchzuführen, und skizzieren Sie die Test-, Audit- oder Validierungsanforderungen.
Risiken, Annahmen, Probleme und Abhängigkeiten
Dokumentieren Sie alle offenen Risiken, Annahmen und potenziellen Probleme, die noch nicht gelöst sind. Weisen Sie diesen Punkten klare Zuständigkeiten zu und verfolgen Sie die Fortschritte, sodass der Gesamtentwurf und die Strategie für die Umsetzung genehmigt werden können. Dokumentieren Sie außerdem die wichtigsten Abhängigkeiten bei der Implementierung dieses Entwurfs.
Schätzung der Betriebskosten
Verwenden Sie den AWS Preisrechner