,

Cloud Migration - Das Migrationsprojekt erfolgreich bewältigen

Cloud Migration - Das Migrationsprojekt erfolgreich bewältigen

Achtung: Wir haben die Inhalte dieses Blogartikels weiter entwickelt und für Sie kompakt in unserem Cloud-Migration Handbuch zusammengetragen.

Hier geht es zum Download

~

 

Cloud Migrationen sind oft komplexe Projekte, die verschiedenste Technologien, Meinungen von Stakeholdern, Prozessänderungen und mehr beinhalten. Auch wenn jedes Migrationsprojekt anders ist, gibt es etablierte Methoden und Erfahrungen, die man nutzen kann, um dieses erfolgreich zu machen.

Mit Struktur zur Cloud-Migration

Bis zur eigentlichen Migration (in der Abbildung unten "Migrations & Operations") sind im Wesentlichen zwei Schritte zu absolvieren.

Migration Readiness Assessment (MRA)

A migration readiness assessment is a process of gaining insights into how far along an organization is in their cloud journey, understanding their current cloud-readiness strengths and weaknesses, and building an action plan to close identified gap“ (Amazon Web Services)

MRA ist zusammenfassend gesagt eine GAP-Analyse auf die Migrationstauglichkeit ihres Unternehmens.

Migration Readiness & Planning (MRP)

Beim MRP geht es darum, ausgehend von den Ergebnissen des Assessments, 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.

Cloud Migration Phasen Übersicht

Vorbereitung ist alles.

Der Weg zur Migration besteht aus guter Vorbereitung. Diese ist das A und O einer erfolgreichen Migration.

Jede Vorarbeit, die nicht im Rahmen des MRP Projektes durchgeführt wird, hat das Potential die gesamte Migration zu gefährden. Jede Komplexität, die man vorab klären kann, mindert die Schwierigkeiten in einem Projekt, dass durch technische Probleme, menschliche Fehler und Deadlines Herausforderung genug ist.

Doch wer sein Ziel, sein „Why“, den Winning-Factor, vor Augen hat, der weiß, wofür sich der Aufwand letztendlich lohnt.

Find the winning factor

Typischerweise gibt es in einem Cloud-Migrationsprojekt einen oder mehrere Treiber oder Trigger – den Winning-Factor.

Gemeint sind Motivatoren, die den größten Bewegungsgrund darstellen, um das Projekt umzusetzen.

Häufig sind das z.B.

  • Skalierungsprobleme,
  • Datenmengen,
  • Latenzen,
  • oder ein bestimmtes Feature, dass das Business weiterbringt.

Um alle Beteiligten und sich selbst von der Sinnhaftigkeit der Migration zu überzeugen ist die Durchführung eines PoC (Proof-of-Concept) zu empfehlen.

Durch das „On-Demand“ Modell der Service-Provisionierung und Abrechnung kann in kurzer Zeit und meist zu geringen Kosten ein minimales Set an Features implementiert werden, um zu beweisen, dass der Winning-Factor Realität werden kann.

Migration Readiness Assessment (MRA)

[Achtung: Wir haben die Inhalte dieses Blogartikels weiter entwickelt und für Sie kompakt in unserem Cloud-Migration Handbuch zusammengetragen. Hier geht es zum Download]

Ein Migration Readiness Assessment (MRA) ist der erste Schritt zur Vorbereitung einer Cloud-Migration. Ziel ist es einerseits ein Verständnis darüber zu erhalten, was noch getan werden muss, bevor die Migration beginnen kann, andererseits geht es auch darum, schon eine grobe Idee für einen Business Case zu entwickeln, um sicherzustellen, dass sich die Investition in die Migration Readiness & Planning (MRP) Phase lohnt.

A migration readiness assessment is a process of gaining insights into how far along an organization is in their cloud journey, understanding their current cloud-readiness strengths and weaknesses, and building an action plan to close identified gap“, so AWS.

Zusammenfassend könnte man sagen, dass MRA eine GAP-Analyse auf den Reifegrad für eine Cloud-Migration ist.

Cloud Migration Phasen Übersicht - Phase 1 MRA

Die Readiness Reifephasen

Die Einstufung der „Readiness” wird in vier Reifephasen abgebildet:

  1. Project (PoC)
  2. Foundation
  3. Migration
  4. Optimization/Reinvention

Project bedeutet, dass bereits erste Experimente in der Cloud durchgeführt werden oder zumindest daran gedacht wird, PoCs durchzuführen und die Cloud-Plattform zu evaluieren.

Foundation bedeutet, dass erste Experimente und PoCs erfolgt sind und Strukturen implementiert werden, um auch produktive Workloads auf der Cloud Plattform betreiben zu können (Landing Zone).

Migration bedeutet, dass erste Workloads migriert werden und Erfahrungen bei der Migration und dem produktiven Betrieb gesammelt werden.

Optimization/Reinvention bedeutet, dass produktive Workloads bereits migriert auf der Cloud Plattform betrieben werden und die Erfahrungen und das Gelernte in das Migrationsprojekt mit einfließt oder neue Workloads direkt in der Cloud aufgebaut werden.

Die Stufen der „Readiness“ geben einen guten Überblick über typische Phasen, in denen sich Unternehmen befinden können.

Das Assessment

Nach einer groben Readiness Einstufung, geht das Assessment weiter in die Tiefe.

Dazu gibt es von Amazon Web Services ein Assessment-Tool mit vorgefertigten Fragenkatalog. Die zu beantwortenden Fragen decken die sechs Perspektiven des Cloud Adoption Frameworks (CAF) ab. Dieses wurde von AWS entwickelt, um Unternehmen auf ihrem Weg in die Cloud zu helfen, über mehr als Technik und IT nachzudenken und letztendlich messbare Ergebnisse zu erzielen, ohne dabei Teilbereiche zu vergessen. Das Cloud Adoption Framework betrachtet die sechs Bereiche

  • Business,
  • People,
  • Governance,
  • Platform,
  • Security und
  • Operations.

Hier gelangen Sie zum AWS Assessment-Tool.

Nach Beantwortung der Fragen erhält der User eine Auswertungsübersicht, wie nachfolgend beispielhaft dargestellt.

Die Beantwortung der Fragen erzeugt oft einen „Aha“ Moment, weil sich Unternehmen häufig noch nicht über alle relevanten Themengebiete Gedanken gemacht haben. Das Assessment deckt damit auch Schwächen und potenzielle Blockaden auf, macht sie transparent und schafft damit einen Handlungsleitfaden, den es im Nachfolgenden anzugehen gilt.

Business Case

Der Business Case der Cloud Migration ist in der Regel für das Management der wichtigste Teil der Projektvorbereitung. Viele Unternehmen tun sich schwer damit konkrete Zahlen für einen Business Case einer Cloud-Migration zu nennen. Einerseits sind die Abrechnungsmodelle der Cloud-Plattformen vielfältig und eine Wissenschaft für sich, andererseits fehlt oft die Erfahrung um einschätzen zu können, ob die Pläne und Vorhaben auch wirklich so funktionieren oder optimal die Bedürfnisse abbilden.

Grade in den ersten Phasen, in denen die Details für die Kalkulation noch nicht vorliegen, muss man hier mit groben Schätzungen arbeiten. Um an erste Näherungswerte zu kommen, ist es hilfreich, zunächst die Workloads zu Kategorisieren. Jedem Workload kann man dann ein Standard Migrations- und Betriebskonzept versehen und dadurch eine erste Idee der Migration entwickeln. Anhand der Kategorien kann eine Schätzung erfolgen, die jedoch nur als Grundlage dazu dienen sollte, zu entscheiden, ob die MRA und die Migration Readiness & Planning Phase (MRP) durchgeführt werden sollte.

Migration Readiness & Planning (MRP)

[Achtung: Wir haben die Inhalte dieses Blogartikels weiter entwickelt und für Sie kompakt in unserem Cloud-Migration Handbuch zusammengetragen. Hier geht es zum Download]

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

[Achtung: Wir haben die Inhalte dieses Blogartikels weiter entwickelt und für Sie kompakt in unserem Cloud-Migration Handbuch zusammengetragen. Hier geht es zum Download]

Ü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.