Lift-and-shift-Migration

Eine Lift-and-Shift-Migration wird oft als einfachste Art und Weise angepriesen um Workloads aus einem lokalen Rechenzentrum in die Cloud zu verlagern. Anhand meiner eigenen Erfahrungen möchte ich aufzeigen, welche Schritte und Voraussetzungen notwendig sind, um eine Lift-and-Shift-Migration erfolgreich durchzuführen, und welche Fehler man dabei besser vermeiden sollte. 

„Lift-and-shift“ ist eine relativ schnelle und kosteneffiziente Art und Weise, lokale Anwendungen in die Cloud zu verlagern.

[ibm.com]

Was ist Lift-and-shift?

Eine Lift-and-Shift-Migration ist eine 1:1-Migration von virtuellen Maschinen (VMs) aus dem lokalen Rechenzentrum in die Cloud. Die VMs werden dabei mithilfe von providerspezifischen Migrationswerkzeugen in die Cloud geklont und können „auf Knopfdruck“ in der Cloud in Betrieb genommen werden. Bei einer Lift-and-shift-Migration sind keine Anpassungen an der zu migrierenden Anwendung notwendig.

Was beinhaltet eine Lift-and-shift-Migration nicht?

Da es sich bei einer Lift-and-shift-Migration um das 1:1-Abbild einer lokalen VM handelt, werden folgende Ziele damit nicht erreicht:

• Umbenennung von virtuellen Maschinen
  Beispielsweise um damit dem neuen Namenskonzept für Ressourcen in der Cloud zu entsprechen.
• Betriebssystem-Upgrade
  Windows 2016 Server müssen auch nach der Lift-and-shift-Migration noch auf ein neues Betriebssystem migriert werden. 
  
• Elastizität
  Alleine durch die Migration wird keine Elastizität geschaffen. Die Applikation kann auch nicht auf wundersame Weise plötzlich selbständig dynamisch Skalieren.
• Kosteneinsparungen
  Der Betrieb von VMs in der Cloud wird in erster Instanz keinerlei Kosteneinsparungen mit sich bringen. Im Gegenteil.

Welche Voraussetzungen müssen erfüllt sein, damit eine Lift-and-shift-Migration gelingt?

Grundsätzlich handelt es sich bei einer Lift-and-shift-Migration um das Rehosting von Ressourcen in einem externes Rechenzentrum. Sämtliche Anforderungen an die Einbindung dieses neuen Cloud-Rechenzentrums in den bestehenden Betrieb müssen gewährleistet sein. Dazu gehören unter anderem:

• Netzwerkanbindung
  Genügend Bandbreite und geringen Latenzzeiten für hybrides Arbeiten.
• Netzwerkzonierung
  Das Netzwerkzonenkonzept muss auf die Public Cloud erweitert werden.
• AD- und DNS-Anbindung
  Migrierte Systeme benötigen AD- und DNS Zugriff.
• Monitoring- und System Management
  Migrierte Systeme müssen in bestehende Monitoring- und Management Systeme eingebunden werden.
• Firewall Regeln
  Die migrierten Systeme bekommen neue IP-Adressen. Sämtliche Firewall Regeln müssen entsprechend neu bestellt werden. Dafür muss Jemand über die bestehenden Firewall Regeln Bescheid wissen. Worauf leider leider selten Verlass ist. Daher müssen die bestehende Firewall Regeln (automatisiert) aus dem System ausgelesen werden können.
• Firewall Gruppen
  Eine Erleichterung sind Firewall Gruppen. Funktioniert leider nur, wenn sämtliche Firewall Objekte und Rules auch auf die Cloud Firewall repliziert werden. Ansonsten heisst es auch hier: Alle Firewall Regeln nochmals neu erfassen.

Neben diesen technischen Aspekten gibt es aber auch organisatorische Aspekte, welche nicht zu vernachlässigen sind:

• Cloud Strategie
  Im Idealfall folgt die Lift-and-shift-Migration einer übergeordneten Cloud Strategie und bildet den ersten Schritt um lokale Systeme abzulösen und Erfahrungen in der Cloud zu sammeln.
• Einbezug der Application Owner
  Nicht zu vernachlässigen sind Wille und Zeit der Application Owner. Sie sind es, welche die Migration einplanen müssen. Welche die Firewall Regeln neu bestellen müssen. Welche die Applikation testen und freigeben müssen und welche unter anderem auch über den erfolgreichen Ausgang der Cloud Migration bestimmen. Entsprechend tut man gut daran, die Application Owner frühzeitig ins Projekt einzubeziehen und nicht zu verärgern.

Fazit

Eine Lift-and-shift-Migration kann trotz Markting-Versprechen herausfordernd sein. Oftmals ist es einfacher, Systeme in der Cloud neu aufzubauen, als bestehenden Systeme 1:1 zu kopieren. Dennoch eignet sich diese Methode gut, wenn es darum geht Systeme schnell und mit geringem Aufwand auf Seite der Application Owner zu migrieren.

Knackpunkte bei einer Migration bilden sicherlich die Umsetzung des Netzwerkkonzept sowie die nicht zu vernachlässigende Komplexität, welche Firewall Regeln in einem Unternehmensnetzwerk spielen können. Hier tut man gut daran die Netzwerk- und Security-Abteilungen frühzeitig einzubinden.