Eine Checkliste für die Migration zu AWS

1. Vorbereitung der Applikationsarchitektur

Eine brauchbare Checkliste für eine AWS-Migration startet mit einer Prüfung einer Anwendung. Das Migrationsteam muss entscheiden, ob die Anwendung Cloud-ready ist. Zusätzlich müssen eventuelle Einschränkungen für die Geschäftsprozesse und Kostenschätzungen dargestellt werden.

• Auflisten der Vor- und Nachteile einer Verschiebung der Anwendung zu AWS. Was sind die geschäftlichen und technologischen Gründe? Alle in Frage kommenden leitenden Angestellten kontaktieren, die mit der Migration zu tun haben.
• Bewertung, inwiefern die Anwendung für die Cloud bereit ist. Ist sie entwickelt für eine flexible Skalierung mit getrennten Komponenten oder ist sie monolithisch aufgebaut? Muss sie vor der Migration neu zusammengesetzt werden? Wird sich die gesamte Applikation auf AWS befinden oder nur einige Komponenten wie zum Beispiel das Frontend?
• Beschreiben, welche besonderen Anwendungskomponenten innerhalb des Unternehmens verbleiben müssen. Die technologischen und/oder geschäftlichen Gründe für ein Unterbleiben der Migration definieren. Eventuell einen Migrationsplan für diese internen Komponenten erzeugen, um sie in der Zukunft in die Public Cloud zu verschieben. Ermitteln, ob AWS Outposts – das Angebot des Cloud Providers für eine Managed On-premise Infrastruktur – für diese Komponenten geeignet ist. Outposts ist seit Ende 2019 verfügbar und erweitert die Entscheidungsfindung für eine AWS-Migration um einen neuen Faktor.
• Bewerten von Applikationsdatenbanken. Sollen Datenbanken zu Amazon Relational Database Serviceoder Amazon Aurora migrieren oder sollte das Unternehmen eine Oracle- oder Microsoft SQL Server-Installation zu EC2 portieren? Oder soll das Migrationsteam die Datenbank oder mehrere Datenbankenalternativ On-Premise behalten und nur die Prozess- oder App-Ausführung zu AWS verschieben?
• Daten sichern. Man muss planen, wie die Anwendung Daten sicher zu diesen Clouds und Endpunkten bringt und zurückholt, entweder über das öffentliche Internet oder über dedizierte Fiber-Verbindungen. Man muss festlegen, wie die Daten im Ruhezustand (at rest) und bei Transfer (in-flight) geschützt werden und dieses Design mit dem Security-Team zusammen überprüfen.
• Aufzeichnen, welche Integrations- und Abhängigkeitstrends die Anwendungskomponenten aufweisen.Die Migrationsteams müssen verstehen, wie sich die Workloads durch die Komponenten bewegen und wo potentielle Probleme liegen. AWS bietet einen Application Discovery Service an, der die lokale Umgebung kontrolliert. Unternehmen können sich aber auch auf Abhängigkeitskarten der Applikationen und Tracking-Tools zur Bestandsüberprüfung verlassen, die bereits in ihren Rechenzentren bestehen.
• Kosten schätzen. Die Cloud ist nicht notwendigerweise billiger, und die Teams müssen die Kosten für den Datenverkehr, für Speicher, Compute und Skalierung berechnen. AWS bietet den Simple Monthly Calculator für verschiedene Services wie zum Beispiel EC2-Instanzen, Elastic Load Balancing und mehr an, mit Beispielen für Anwendungsinstallationen. Ein Unternehmen kann sich auch den Cost Management Tools von Third-Party-Anbietern zuwenden.

Unternehmen können völlig in einem einzigen Weg zur Applikationsmigration aufgehen – zum Beispiel alles neu für den optimalen Cloud-Einsatz umbauen und umorganisieren. Um wirklich erfolgreich zu sein, braucht man eine Kombination von Cloud, Agile und DevOps, aber jede verschobene Technologie muss laut Buchner in Übereinstimmung mit den Projektzielen beurteilt werden. Wenn die Anwendung in zwei Jahren ausläuft, sollte man sich daran halten. Aber wenn die Anwendung eine Investition für das Geschäft ist, sollte man die Extrazeit zu ihrer Modernisierung in Anspruch nehmen.

2. Hosting auf AWS

Sobald das Migrationsteam die Anforderungen an Ressourcen und Betrieb versteht, kann es bestimmen, wie ihre Anwendungen in der Cloud gehostet werden sollten. Man sollte diesen Bereich der Checkliste benutzen, um die Hosting-Auswahl von AWS zu bewerten.

• Definieren einer Infrastruktur-Strategie. Erfordert die Anwendung eine dedizierte Amazon VPC oder sollte man sie in Multi-Tenant-Instanzen installieren? AWS empfiehlt, einen Account in einer AWS Landing Zone mit mehreren Anwendern einzurichten, um die Migration zu ermöglichen.
• Einrichten von Applikations-Instanzen. Diese Instanzen müssen der Nachfrage nach Ressourcen und den Skalierungsanforderungen der Anwendung entsprechen. Beispiele hierfür sind billigere T3 virtuelle Maschinen, nicht festgelegte M5-Instanzen und andere EC2-Instanzenarten, die für Compute, Storage und anderes optimiert sind. Das Migrationsteam könnte sich auch höherwertigen AWS-Angeboten wie Elastic Beanstalk oder sogar AWS Lambda für Serverless Execution zuwenden.
• Eingebaute Skalierung. Administratoren können Anwendungen so konfigurieren, dass sie automatisch mit AWS Auto Scaling skalieren, aber sie sollten sich vorsichtig verhalten angesichts der Kosten, die jede hinzugefügte Ressource verursachen kann. Grenzen hierfür lassen sich durch manuelles Nachjustieren oder durch Skalierungs-Regelwerke verwirklichen. Man sollte die Erweiterung von Applikationen zusammen mit einem Content Delivery Network wie zum Beispiel AWS CloudFront oder einem anderen Drittanbieter-Tool wie zum Beispiel CloudFlare planen.
• Storage einrichten, um verschiedenen Daten- und Redundanzanforderungen zu entsprechen. AWS bietet S3 Object Storage, Elastic Block Store und andere Storage Services an, einschließlich S3 Glacier für Archive. Man sollte Storage Lifecycle Management nutzen, mit dem Daten zwischen „heißen“ und „kalten“ Speicherschichten bewegt werden. Um eine große Menge an Daten zu AWS zu bewegen, sollte man Snowball in Erwägung ziehen, ein physisches Gerät, das bei den Anwendern angeliefert wird und dann die Anwendungsdaten zu AWS transportiert.
• Die Hosting-Umgebung so einrichten, dass sie geographischen Beschränkungen oder Auflagen entspricht. Um Latenzen zu reduzieren, sollte eine Anwendung zum Beispiel in AWS-Regionen in der Nähe zu den größeren Kundenstandorten installiert werden. Oder die Speichersysteme sollten an eine bestimmte Region angeschlossen sein, um die Compliance mit Gesetzen zur Datenaufbewahrung zu garantieren.

Unternehmen, die an das Wachstum von Hardware-Ressourcen im eigenen Rechenzentrum gewöhnt sind, neigen dazu, übergenau bei der Instanzen-Planung in der Cloud zu sein, warnt Buchner. Das sei eine überholte Denkart. „In der Cloud kann man die Ressourcen-Zuteilung innerhalb von ein paar Minuten ändern, so dass man die beste Auswahl treffen sollte, sie dann anwenden und von da aus jederzeit ändern kann“, sagt Buchner.

3. Anwendungen installieren

Sobald Server-Instandhaltung und -Management standardisierten Cloud-Instanzen weichen, sollten Unternehmen zu automatisierten Prozessen und zu Infrastructure as Code (IaC) wechseln. Die Cloud-Migration wird sinnvoller mit einem gut geplanten Installations-Toolkit und mit Prozessen, die Agile- und DevOps-Methodologien miteinander verbinden.

Die Anwendung und benachbarte Komponenten zu AWS migrieren. Amazon besitzt eine Reihe von eigenen Services für die Migration, einschließlich AWS Database Migration Service, AWS Server Migration Service, CloudEndure Migration und VMWare Cloud on AWS.

Eine CI/CD-Pipeline einrichten. Solche Pipelines installieren die Anwendung und passen sie an AWS an. AWS bietet selbst CodeBuild und CodePipeline an und unterstützt unabhängige Pipelines wie zum Beispiel eine integrierte, mit Jenkins miteinander verbundene Tool-Suite.

IaC-Templates für die Konfiguration von Anwendungsinfrastruktur erzeugen. CloudFormation von AWS mit CloudFormer-Templates oder Drittanbieter-Tools wie zum Beispiel Terraform von Hashicorp benutzen. Diese ermöglichen schnelle Entwicklung und Standardisierung.

Wenn man die Checkliste für diese AWS-Migration durchgeht, muss man genauso schwierige Aufgaben wie auch jene beachten, die nicht die eigenen Workloads betreffen.

Wenn man weiter eine Entwicklung des Waterfall-Modells im Auge hat, sollte man dennoch nicht Agile- und DevOps-Installationen erlauben, Barrieren gegen eine Cloud-Migration aufzubauen. Die DevOps-Einführung ist lokal schwieriger durchzuführen und muss anders als Cloud-basierte Pipelines umgesetzt werden, merkt Buchner an. Anstatt zweimal DevOps zu lernen, sollte man mit dem Cloud-Einstieg beginnen und damit die Agile- und DevOps-Aneignung im Unternehmen vorantreiben.

4. Betrieb und Support

Eine erfolgreiche Cloud-Migration steht am Anfang und nicht am Ende des Lebenszyklus einer Anwendung. Der Rest des Lebenszyklus – Monitoring, Incident Detection sowie Response- und Ressourcen-Management – ist der geeignete Punkt, an dem das IT-Team Performance- und Security-Probleme verhindern und Dev-Ops-Prozesse verbessern kann.

• Das Monitoring der Anwendungs-Performance aktualisieren. Die Feedback-Loop von DevOps mit Cloud Operations Monitoring vervollständigen. Neue grundlegende Performance-Messungen der Applikation einrichten, besonders wenn Komponenten eine neue Architektur für Cloud Services bekommen. Neue Benachrichtigungsschwellenwerte festsetzen sowie Monitoring-Tools von anderen Anbietern im Vergleich zu AWS CloudWatch
• Monitoring der Infrastrukur-Ressourcen basierend auf dem Modell der geteilten Verantwortlichkeit (shared-responsibility). Performance und Verfügbarkeit der physischen Infrastruktur fallen nun in die Verantwortung von AWS, aber alles darüber hinaus gehört zu den Aufgaben des eigenen IT-Teams. Dort muss man wissen, ob die Anwendung mit Problemen zu kämpfen hat, ob ihre Instanzen falsch konfiguriert sind oder Bottlenecks aufweisen und ob die AWS-Rechenzentren in Verantwortung zu ziehen sind. Man sollte Probleme auf der AWS-Seite Service Health Dashboard verfolgen.
• Präventive Sicherheitsmaßnahmen einrichten. Der Security-Umkreis ändert sich, wenn eine Anwendung in die Public Cloud verlagert wird. Welche Firewalls sind eingerichtet? Könnten virtuelle Firewalls den Verkehr der Instanzen wirksam kontrollieren? Man sollte sich die Zeit nehmen, um sich über größere Security-Verletzungen zu informieren und darüber, wie man sie vermeiden kann.
• Security-Monitoring und -Verteidigung aktivieren. Penetration-Tests, Vulnerability-Scans und andere Informationsmöglichkeiten nutzen. Unternehmen mit mehreren AWS-Zugängen sollten sich eine Governance-Option wie zum Beispiel AWS Control Tower genauer ansehen.
• Log-Konsolidierung und -Archive einrichten. Unternehmen mit hybriden Cloud-Anwendungen finden zentralisiertes Log-Management wegen der unterschiedlichen Informationsquellen der Logs schwierig. Sie brauchen eventuell verschiedene Quellen, um die Logs von AWS und den internen Einstellungen zusammenzuführen.
• Mit Prozessen für Incident Response arbeiten. Cloud-Management unterscheidet sich stark von internen Aufgaben, bei denen Administratoren die Server kontrollieren und sogar direkt physisch nach Fehlern suchen können. Man sollte On-Demand-Ressourcen als einen Landing Place nutzen, um im Bedarfsfall sofort alle problematischen Updates zurückfahren zu können.
• Anwendungs-Backup und Prozesse für Disaster Recovery überdenken. Entweder die Site für Disaster Recovery in eine andere AWS-Region oder Availability Zone verlegen oder sicherstellen, dass das Failoverzu lokalen Servern abläuft.
• Alles unter Kontrolle. Ressourcen hinzufügen ist mit AWS leichter als On-Premise, so dass man Größe und Skalierungsgrenzen nach der Migration regelmäßig überprüfen sollte. So viel wie nötig anpassen oder erweitern und innerhalb des verfügbaren Budgets bleiben. Das automatische Skalieren der Ressourcen von AWS kann Performance-Probleme der Anwendungen verdecken, so dass man die Rechnungen hinsichtlich unerwarteter Verwendungen prüfen sollte.

Security ist für die meisten Unternehmen, die Anwendungen vom eigenen Rechenzentrum zu AWS bewegen, ein Problem. Man sollte mit einfachen Kontrollen starten, zum Beispiel mit dem AWS-Tool Trusted Advisor, um das zu erreichen, was Buchner „hell leuchtende Sicherheitslöcher“ nennt. Es gibt auch ausgefeilte kommerzielle Security AuditTools. Der nächste Schritt ist dann eine Überprüfung von etwa drei Stunden mit dem AWS Well-Architected Framework, das Betriebsabläufe, Security, Zuverlässigkeit, Performance und Kostenoptimierung durchleuchtet. Und im Fall von Anwendungen mit besonders hohen Sicherheitsansprüchen können Unternehmen Sicherheitsspezialisten hinzuziehen, die Anwendung, Netzwerk, Zugangskontrolle und andere gefährdete Zonen genau durchsuchen.

5. Projektmanagement und Kosten

Die Checkliste einer AWS-Migration ist nicht beendet, wenn das Projekt schließlich in der Cloud gelandet ist. Überlegungen zum Projektmanagement wie zum Beispiel die Bewertung von Anwendungen und Teamentscheidungen bleiben sogar nach der Migration wichtig. Man sollte häufig auf sie zurückkommen, um sicherzustellen, dass das Projekt auf dem richtigen Weg ist. Und man sollte nicht vergessen, dass sich Training und Ausprobieren immer wieder lohnen.

• Langfristig die Ziele und Zwecke der Migration definieren. Wie wird das Unternehmen AWS-Accounts und Ausgaben managen, sobald mehr Anwendungen migriert werden? Wird jede Abteilung ihre eigene AWS-Installation managen, oder wird die Cloud-Einführung unter einer zentralen Kontrolle geschehen? Wie werden die verabschiedeten Entscheidungen zu diesem Projekt innerhalb des Unternehmens verbreitet?
• Einen Zeitplan aufstellen, der auf dem Migrationsplan beruht. Ferien und wichtige geschäftliche Ereignisse berücksichtigen, um einen realistischen Zeitplan aufzustellen.
• Die AWS-Kenntnisse der Mitarbeiter festhalten und entsprechende Trainings organisieren. Die Kenntnisse und Fähigkeiten weiter zu entwickeln, ist besonders abhängig von den täglichen Aufgaben der Team-Mitglieder. Trainingszeiten auch für die Zukunft und ständige Verbesserungen festlegen.
• Die richtigen Tools und Services auswählen. Die Tools sollten den Anforderungen des Unternehmens entsprechen, und diese müssen die Administratoren ausbilden, um sie auch einzusetzen. Man sollte die Tools häufig überprüfen, da neue Funktionen und Features auftreten und sich die Herstellerlandschaft verändert. Man sollte die Endanwender befragen, ob die Tools voll eingesetzt werden und so funktionieren wie beabsichtigt.
• Formalisieren der Kommunikation und des Wissensaustauschs im Unternehmen. Alle sollten das gleiche Forum benutzen – Anwendungsarchitekten, Entwickler, Administratoren und Sicherheitsspezialisten sowie Benutzer der Anwendungen und leitende Mitarbeiter. Man sollte die laufende Dokumentation, IaC-Vorlagen und anderes Wissen und Know-how für das Projekt zentral zusammenfassen – in einem Wiki oder an einem anderen Ablageort.
• Kostenschätzungen und Simulationen, um ein Budget nach der Migration zu planen. Die Ausgaben für eine Cloud können schnell außer Kontrolle geraten. Der Budget-Plan sollte variable und zyklische Anforderungen berücksichtigen, und außerdem sollte er einen Mechanismus enthalten, der Alarmzeichen gibt, sobald eine Anwendung von der Norm abweicht.

Wenn sich Unternehmen in die Cloud bewegen, müssen sie mit der Zeit ein Account-Management einplanen. Wenige Unternehmen kümmern sich am Anfang um dieses Problem, bemerkt Buchner: Ein mittelgroßes Unternehmen könne leicht bei 120 AWS-Accounts enden. Und mehr Accounts bedeuten mehr Passwörter, mehr Overhead, größere Budget-Umfänge und möglicherweise unnötige Komplexität. Unternehmen können mit AWS Organizations ihre Accounts umorganisieren – und wahrscheinlich müssen sie dem mehr Zeit widmen, nachdem sie erfolgreich ein paar Ausflüge in die Cloud gestartet haben.

Buchner rät, die Accounts nach drei verschiedenen Konzepten aufzuteilen: 1) Die Accounts gehören zu unabhängigen Teams oder Geschäftseinheiten ohne Überlappungen; 2) das Unternehmen muss genau wissen, welche Kosten mit verschiedenen Workloads verbunden sind; und 3) aus Security- und Compliance-Gründen, wenn verschiedene Applikationen nebeneinander auf AWS laufen.