,

Cloud Migration Teil 3 - Migration Readiness & Planning (MRP)

Cloud Migration Teil 3 - Migration Readiness & Planning (MRP)

Das Migration Readiness & Planning (MRP) ist nach dem Migration Readiness Assessment (MRA) der zweite Schritt zur Vorbereitung einer Cloud-Migration.

Ziel ist es, alle Grundlagen zu schaffen, damit die Migration beginnen kann. Dementsprechend folgt auf den Abschluss der MRP-Phase das Migrationsprojekt, bzw. die Phase „Migrations & Operations“. Das MRP wird typischerweise im Rahmen eines Consulting Projektes umgesetzt. Grade für Unternehmen mit wenig - oder wenig aktuellem - Cloud-Know-How ist es wichtig sich Unterstützung von Experten zu holen, um sicherzustellen, dass die Pläne auch realistisch und umsetzbar sind.

Beim MRP geht es darum alle Vorarbeiten zu leisten, um eine Organisation auf ein Migrationsprojekt ganzheitlich vorzubereiten. Dazu gehören sämtliche Perspektiven des sogenannten Cloud Adoption Frameworks (CAF), also Business, People, Process, Platform, Security, Operations. (Aus dem Blogpost Cloud Migration Teil 1)

Nachfolgende Abbildung ordnet diese Phase in den Gesamtprozess der Cloud-Migration ein.

Cloud Migration Phasen Übersicht - Phase 2 MRP

Ausgangslage

Sofern ein entsprechendes Migration Readiness Assessment (MRA) durchlaufen wurde, sind beim Start des MRP-Projektes das Assessment, die Readiness Stufe und der „high-level“ Business Case vorhanden, sowie eine Workload-Kategorisierung als Output des Rapid Discovery. Im MRP geht es darum, den Business Case zu konkretisieren, die Zahlenbasis genauer zu schätzen und die Teilbereiche des Assessment in den grünen Bereich (5 von 5 Punkten) zu überführen.

MRP & CAF

Wie in der Abbildung (siehe oben) zu erkennen, ist die MRP-Phase, anders als die MRA-Phase, nicht direkt nach den Perspektiven des Cloud Adoption Framework (CAF) gegliedert. Die Bereiche der MRP Phase sind stattdessen als strukturierte Aufgabenpakete zu verstehen, die jeweils Inhalte von mehreren CAF-Perspektiven adressieren. Nachfolgend ordnen wir einmal die Arbeitspakete des MRP den CAF Perspektiven zu:

CAF Perspektive MRP Mapping
Business Die für die Business Perspektive notwendigen Aspekte wie z.B. erwartete Kosten, erwartete Vorteile, Risiken und Umgang mit solchen werden im Business Case des Migrationsvorhabens abgebildet.
People Der Fokus People wird an mehreren Stellen im MRP betrachtet. Der Business Case beispielsweise dient als Grundlage dafür, die nötige Ressourcen-Unterstützung aus dem Management zu bekommen. In den Planungsbereichen Skills / CoE und Migration & Expertise geht es unter anderem um die Weiterbildung von Mitarbeitern, bzw. auch darum, den Ressourcenbedarf festzulegen. Im Kontext Operating Model wird Organizational Change Management thematisiert, da sich durch das Vorhaben Rollen, Aufgaben, Verantwortlichkeiten und ggf. Organisationsstrukturen ändern können.
Governance Im Bereich Skills / CoE sollten Verantwortlichkeiten und Rollen festgelegt werden, damit die Cloud-Migration organisiert werden kann. Im Bereich Migration Plan wird das Projekt- und ggf. Programm Management und Reporting zur Steuerung des Projektes, bzw. der Projekte thematisiert.
Platform Der Aufbau der Grundstruktur der Cloud, wie z.B. die Account Struktur und die Netzwerkanbindung wird im Planungsaspekt Landing Zone thematisiert. Das Design der technischen Zielarchitektur u.a. im Bereich Discovery & Planning.
Operations Operating Model umfasst u.a. auch um die technische Umsetzung von z.B. Monitoring, Ressourcen Management und Disaster Recovery, Discovery & Planning auch die Betriebs- und Wartungstätigkeiten.
Security Unter dem Planungsaspekt Security & Compliance werden Compliance Regularien geprüft und deren Umsetzung definiert. Zugriffe und Berechtigungen (IAM) werden im Kontext Landing Zone definiert und umgesetzt.

 

Ablauf

Da viele der zu thematisierenden und zu erarbeitenden Bereiche Abhängigkeiten untereinander haben, ist ein iteratives Vorgehen zu empfehlen.

Grundverständnis

Die Fragen aus dem Assessment, die mit 0 oder 1 beantwortet wurden, sollten initial reviewed werden. Es ist für einen erfolgreichen Abschluss des MRP Projektes wichtig, dass direkt am Anfang des Projekts ein solides Grundverständnis über alle Bereiche und deren Relevanz vorhanden ist. Zusätzlich gilt es im Arbeitspaket Grundverständnis zu definieren, welche konkreten Personen welche Verantwortlichkeiten im MRP haben und welche Entscheidungen diese Personen treffen sollen. Der Personenkreis kann natürlich erweitert, oder ausgetauscht werden, es ist aber wichtig mit einer ersten Definition anzufangen.

Wenn das Grundverständnis etabliert ist und die beteiligten Personen definiert sind, steht als nächstes die Appliaction Discovery und das Einholen der Security & Compliance Anforderungen an.

Application Discovery

Während im MRA ein grober Überblick über die Landschaft ausreichend für eine erste Schätzung war, ist es wichtig beim MRP den genauen Scope festzulegen.

  • Um genau welche Server, Komponenten, Applikationen geht es?
  • Wie sind diese dimensioniert (CPU, RAM, Storage)?
  • Welches Betriebssystem und welche Software in welchen Versionen?
  • Wie sind die Abhängigkeiten der Server, Komponenten und Applikationen untereinander?
  • Welche Security & Compliance Anforderungen sind wie umgesetzt?
  • Wie kritisch sind welche Systeme?

Diese und weitere Fragen müssen beantwortet werden, um die notwendige Datengrundlage zu haben. Dabei können auch Tools bei unterstützen, wie z.B. das AWS Application Discovery Service (ADS) Tool. Das ADS gibt es als Appliance-Connector oder Agent zur Sammlung von Daten über Server und Applikationen.

Security & Compliance Anforderungen

Zeitgleich zur Application Discovery sollten auch alle Security & Compliance Anforderungen abgefragt, definiert und geprüft werden. Die Cloud-Plattformen bieten typischerweise diverse Möglichkeiten sehr einfach und kostenlos oder kostengünstig Sicherheitseinstellungen umzusetzen, wie z.B. Verschlüsselung, Key Management, MFA, Infrastructure as Code, sowie diverse Monitoring und Logging Möglichkeiten. Diese sollten initial evaluiert werden und daraus Vorgaben für Architekturen entwickelt werden.

Vorgaben könnten z.B. wie folgt aussehen:

  • Zugriffe mit Administrator-Berechtigungen sollen nur mit vorheriger MFA erlaubt sein
  • Es sollen keine VMs in Public Subnetzen aufgebaut werden
  • Es sollen keine voll-umfänglichen Administrator-Berechtigungen in Accounts vergeben werden, in denen Produktionssysteme betrieben werden

Nach der Appliaction Discovery und dem Einholen der Security & Compliance Anforderungen, ist die Datengrundlage für die Planung von Architektur, Migrationswegen, Kosten, Reihenfolgen und allem weiteren geschaffen. Bei der Planung ist der erste Schritt die Definition der Zielarchitektur.

Architektur & Migrationsweg

Bei der Planung gibt es diverse Möglichkeiten vorzugehen. Die folgenden „6-Rs“ bieten einen guten Überblick über die grundsätzlichen Vorgehensweisen bei einer Migration:

  • Rehost: Man migriert ein Server/System/Container mit möglichst wenigen Änderungen, sozusagen 1:1.
  • Replatform: Man migriert von einem selbstverwalteten System in einen Plattformdienst, also z.B. von einer MYSQL im eigenen Rechenzentrum zum MYSQL PaaS Dienst des Cloudproviders
  • Repurchase: Man löst ein System über einen SaaS Service ab, bzw. steigt auf ein SaaS/Cloud Lizenzmodell um
  • Refactor: Man macht signifikante Änderungen an der Architektur, der Software, oder macht eine komplette Cloud-native Neuentwicklung
  • Retire: Man schaltet das System ab, ohne es zu migrieren
  • Retain: Man lässt das System unverändert laufen, ohne es zu migrieren

Neben den grundsätzlichen Vorgehensweisen, biete die Cloud diverse Services und Features, um mögliche Architekturen abzubilden. Beispielsweise bei „Compute“-Ressourcen gibt es die Optionen virtuelle Maschinen, Container, oder Serverless Functions zu verwenden. Das ist nur der erste Einstieg im Compute Bereich. Man muss zusätzlich die Details innerhalb der Optionen definieren, also z.B. das OS, die Art der Container Orchestration, oder das zu verwendende Framework. Um hier optimale und nachhaltige Architekturentscheidungen zu treffen, ist ein umfassendes Wissen über Cloud-Plattform notwendig. Dafür gibt es die Möglichkeit sich das Wissen im Rahmen einer Ausbildung zum „Solutions Architect“ für die jeweilige Cloud-Plattform anzueignen, oder sich diese Expertise in das Projekt einzukaufen.

Beim Festlegen der Zielarchitektur und des konkreten Migrationswegs sind also die folgenden 4 Dinge zu beachten: die Datenbasis (aus der Appliaction Discovery), die Security & Compliance Anforderungen, die 6-R's und die Möglichkeiten der Cloud-Plattform.

Mit der ersten Iteration der Zielarchitektur und den Migrationswegen können nun die folgenden Bereiche angegangen werden:

  1. Evaluierung & Definition der Landing Zone, sowie Implementierung dieser inkl. PoC zur technischen Validierung
  2. Planung der Reihenfolge unter der Berücksichtigung von
    1. Kosten & Risikobewertung für den Business Case
    2. Prognose der benötigten Skills & Ressourcen zur Durchführung
  3. Definition des Operating Models

Landing Zone

In diesem Planungsabschnitt geht es um die Struktur der Accounts, die Zugriffs- und Berechtigungsstruktur, sowie die Security, Netzwerke und deren Anbindung. Es gilt festzulegen wie diese Grundstruktur der Cloud aufgesetzt werden sollte, damit die verschiedenen Architekturen und Migrationswege bestmöglich umgesetzt werden können. D.h. auch gewisse Shared Services, wie z.B. die Implementierung von Migrationstools, o.ä. kann in diese Aktivität fallen. Um zu validieren, dass das Konzept der Landing Zone auch tragfähig ist, bietet es sich an, die Landing Zone (oder Teile davon) im Rahmen des MRP Projektes zu implementieren. Das kann z.B. im Rahmen eines PoCs erfolgen. Gleichzeitig werden durch diese Aktivitäten wertvolle Erfahrungen und Expertise für die Migration aufgebaut.

Reihenfolge

Um den Migrationsplan zu vervollständigen fehlt noch die Reihenfolge in der die Systeme migriert werden sollen. Die Reihenfolge ist wiederum neben den technischen Aspekten und der Dauer der Migrationswege auch davon abhängig, wann welche Kosten anfallen sollten/können und welche Ressourcen mit welchen Skills wann bereitstehen. Aus der Aktivität der Festlegung der Reihenfolge können nun die Kosten für den Business Case und die Ressourcen & Skill Anforderungen direkt abgeleitet werden.

Operating Model

Aus der Zielarchitektur ergeben sich auch die Anforderungen an den Betrieb. Es muss evaluiert werden, ob die aktuell eingesetzten Tools, Prozesse und Strukturen in der Cloud verwendbar und sinnvoll sind. Durch die Agilität der Cloud-Plattformen sind im Betriebsmodel DevOps Ansätze kaum wegzudenken. Deshalb ist es sinnvoll anhand der wirklich geplanten Architektur das Operating Model neu festzulegen. Man braucht eben auch nur Windows Patchprozesse, wenn noch Windows Server betrieben werden müssen. Sollten einzelne Architekturentscheidungen dazu führen, dass für einzelne Applikationen ganze Teams im Operating benötigt würden, sollte diese Information an das Planungsteam gegeben werden, um die Architekturentscheidung ggf. zu überdenken.

Ergebnisse

Am Ende der MRP Phase sollte nun folgendes erreicht sein:

  • Ein Business Case auf Grundlage der detaillierten Planung
  • Eine Landing Zone, die technisch validiert wurde
  • Ein Migrationsplan, bestehend aus Zielarchitektur, Migrationswegen & Zeitplan
  • Ein Operating Model, angepasst an die echten geplanten Bedarfe
  • Eine Liste an Ressourcen & Skill Anforderungen
  • Ein CoE an Personen, die im Rahmen des MRP ihre jeweiligen Rollen ausgeführt haben

 

Über den Autor des Beitrags: 

Jonas Neumann

Consultant, Arvato Systems AWS Business Group

Leave a reply

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.