Wie erfolgt die Migration in die Cloud?

AWS bietet einen umfassenden dreistufigen Ansatz für ein Migration Acceleration Program (MAP):

• Bewerten,
• Mobilisieren
• Migrieren und modernisieren

Assessment (Bewertung der Migrationsfähigkeit)

Diese Bestandsaufnahme- und Analysephase der Ist-Situation dauert 1 bis 3 Monate und folgende Themen müssen vorrangig bearbeitet werden:

1. Identifizieren der TCO (Total Cost of Ownership) auf AWS (im Allgemeinen wird Migration Evaluator verwendet) und Bestätigen, dass es die MAP-Zugriffsbedingungen erfüllt.
2. Bestätigung des Budgets und der Personalressourcen für die Durchführung der Migration.
3. Identifizieren des vor der Migration erforderlichen Projekts durch ein Migration Readiness Assessment (MRA). Dabei ist die Migrationsfähigkeit wie folgt zu beurteilen:

• Die Fähigkeit der Cloud-Plattform (Landing Zone), Anwendungen in großem Maßstab zu hosten
• Die Fähigkeit der Sicherheitslösungen und -prozesse, das erwartete Sicherheitsniveau im gesamten Portfolio bereitzustellen und skalierbar zu funktionieren
• Die Möglichkeit, Cloud-Finanzmanagement für eine große Anzahl von Anwendungen und AWS-Konten bereitzustellen
• Die Fähigkeiten der Teams zur Durchführung von Cloud-Migrations- und Betriebsaktivitäten
• Die Organisation und Cloud-Governance, um bei einer großen Menge an Anwendungen die richtigen Entscheidungen zu treffen
• Der Grad der Kontrolle über das Anwendungsportfolio
• Die Fähigkeit, komplexe Programme zu verwalten

4. Bestätigung des Sponsorings

Dies ist auch die Zeit, die Mobilisierungsphase im Hinblick auf Ressourcen (intern und extern), Management, Budget und Dauer mit wichtigen Meilensteinen zu gestalten und Verträge mit externen Lieferanten abzuschließen.

Mobilize (Mobilisierung von Ressourcen für die Migration in die Cloud)

Diese Phase dauert typischerweise zwischen 3 und 9 Monaten.

Dadurch können die bei der Bewertung der Migrationsbereitschaft festgestellten Lücken geschlossen, einige Pilotanwendungen (3 bis 5) geübt und die Teams mobilisiert werden, die am Migrationsprogramm beteiligt sein werden.

Bei den oben genannten Schwerpunkten sind daher Arbeiten durchzuführen, die noch nicht als abgeschlossen gelten. Es gibt auch:

1. Ein spezifisches Projekt zur detaillierten Analyse des Anwendungsportfolios, um den Umfang der Migration, den Migrationspfad für jede Anwendung und den Migrationsplan zu ermitteln.
2. Ein Projekt zur Implementierung der für die Migrationsphase erforderlichen Methodik, Organisation, Tools, KPIs und Governance mit der damit verbundenen Vertragsgestaltung.
3. Ein Projekt zum Target Operational Model (TOM)
4. Ein spezifisches Projekt zur Weiterentwicklung von Fähigkeiten, zur Umsetzung des Community-Aufbaus und zur Gestaltung des Kommunikationsplans.
5. Ein Projekt zur Bewältigung all dieser Themen und insbesondere der zahlreichen Abhängigkeiten zwischen ihnen.

Migration und Modernisierung

In Wirklichkeit erstreckt sich die Migrationsphase im großen Maßstab über einen Zeitraum von 1 bis 3 Jahren, wobei die Planung durch Anwendung der in der Mobilisierungsphase vorbereiteten Methodik und Governance erfolgt. Die Migration eines Portfolios von 200 Anwendungen bedeutet, 200 Projekte unterschiedlicher Komplexität und mit unterschiedlichen Teams parallel zu verwalten. Diese Migrationen basieren auf vier wichtigen organisatorischen Säulen:

1. Die Entwicklungsteams, die, idealerweise im DevOps-Modus, alle Entwicklungs-, Test- und Betriebsaktivitäten der Anwendung sicherstellen und deren Anwendungseigentümer den gesamten Migrationszyklus verwaltet („verantwortlich“ für die Migration).
2. Die „Migration Factory“, die die Entwicklungsteams bei den Migrationen auf mehreren Ebenen unterstützen wird:

• Garant der Migrationsmethodik von Vorlagen und zugehörigen Tools (der die Migrationsaktivitäten so schnell wie möglich industrialisiert)

• Programmmanager, der einen konsolidierten Überblick über die Planung, das Budget und den Umfang der Migration bietet

• Globaler Budgetgarant durch Konsolidierung aller Informationen zu den mit der Migration verbundenen Kosten und Erkennung von Abweichungen

• Experten für Migrationstechnologien (Datenmigrationstools, VM-Migrationstools, große Speichermigrationstools usw.) und den Mechanismus zur Auslösung der von AWS bereitgestellten Gutschriften.

• Entwicklung automatisierter Erkennungstools

• Entwicklung und Erweiterung des Migrations-Cockpits (Kontrollpanels, die eine skalierbare Verwaltung der Migration ermöglichen)

• Moderation der Migrations-Community

3. Das CCOE (Cloud Center of Excellence), das die Cloud-Plattform und die Konfiguration verwaltet, um den Anforderungen der verschiedenen zu migrierenden Anwendungen und Geschäftsinhaber gerecht zu werden.

4. Die komplementären Shared-Technology-Services-Einheiten, die Folgendes verwalten:

• IT Sicherheit

• Die Netzwerkinfrastruktur

• Build- und Betriebstools

• Transversale Infrastrukturdienste (DNS, NTP, AD, Dateiübertragungen, Verwaltung von Patches und System-Images usw.) Die Effizienz des Kooperationsmodells zwischen diesen Säulen ist ein wichtiger Garant für den Erfolg des Migrationsprojekts. Das Governance-Modell und die Fähigkeit, Teams zu stärken, innerhalb kurzer Zeit Alarme auszulösen und ergänzendes Fachwissen einzubeziehen, sind weitere Erfolgsfaktoren.

Migrationsausführung

Der Migrationszyklus ist ein Standardanwendungszyklus, der die Release-Management-Praktiken der verschiedenen Entwicklungsfabriken so weit wie möglich nutzen muss. Es basiert auf den folgenden Phasen:

Entdecken: In dieser Phase stellt der Geschäftsinhaber den Mitgliedern der Migrationsfabrik, die die Migration unterstützen werden, Folgendes vor: 

• die mit der Anwendung verbundenen geschäftlichen Probleme, Design der vorhandenen Anwendung,

• unterschiedliche eingehende und ausgehende Ströme

• Dienstleistungsverträge 

• verschiedene Umgebungen und ihre Rollen

• genutzte Kapazitäten

• Schwankungen im Nutzungsniveau an einem typischen Tag, einer typischen Woche und einem typischen Jahr

• und die verschiedenen an der Anwendung beteiligten Stakeholder. Diese Phase kann durch den Einsatz automatisierter Erkennungstools beschleunigt werden, die auf der Nutzung strukturierter technischer Daten (Firewall-Regeln, Backend-Frontend-Links in Load Balancern, Infrastrukturkonfigurationsdateien, Anwendungskonfigurationsdateien, DNS-Einträge usw.) basieren.

Design: Design: In dieser Phase wird das Design der Anwendung nach der Migration zu AWS entsprechend der Art des geplanten Migrationsmusters entwickelt (Rehost, Rebuild, Replatform, Refactor – siehe Kapitel „Anwendungstransformation“).

Technische und finanzielle Designvalidierung: Entwurfsvalidierung und finanzielle Bewertung, um die Einhaltung des Geschäftsfalls zu überprüfen und das umzusetzende Budget festzulegen

Implementieren und bereitstellen: Dazu gehört die Bereitstellung der Infrastruktur der Umgebungen auf Basis von Infrastructure-as-Code und die Transformation der Anwendung, um sowohl die Cloud als auch die Tests optimal zu nutzen

Vor der Umstellung: In dieser Phase werden die Kapazitäten und die Leistung der Anwendung auf AWS validiert, die Betriebstools integriert und die Betriebsanweisungen angepasst. Anschließend wird die Funktionsfähigkeit validiert, die anwendungsübergreifenden Abläufe (intern und extern) getestet, die Akzeptanz des Service-Eigentümers eingeholt und der detaillierte Plan für die Umstellung mit dem zugehörigen Rollback-Plan definiert.

Umstellung: Übertragen Sie benutzer- und anwendungsübergreifende Datenströme an die auf AWS bereitgestellten Instanzen. In dieser Phase sollten der korrekte Lastanstieg und das korrekte Verhalten mit Standardfehlerraten und Standardleistungen validiert werden.

Nach der Umstellung: eine Beobachtungsphase, in der der Betrieb der Anwendung überwacht wird. Am Ende dieser Phase wird die Entscheidung getroffen, nicht zur ursprünglichen Instanz zurückzukehren.

Stilllegung: Dabei handelt es sich um die Vorgänge zur Außerbetriebnahme der ursprünglichen Anwendung und aller zugehörigen Einstellungen. Diese Phase kann die Vernichtung von Daten gemäß den Sicherheitsanweisungen und die Wiederherstellung von Geräten durch einen Makler umfassen.

Bewertung: Basierend auf einem agilen Retrospektivmodell ermöglicht es die Identifizierung von Praktiken, die beibehalten, verbessert oder aufgegeben werden sollen, sowie von neuen Praktiken, die übernommen werden sollen. Ein übergreifender Austausch ermöglicht es, von Best Practices zu profitieren.