Was wir bei der Migration eines Rechenzentrums in die Cloud gelernt haben

Im November 2019 erhielten wir einen Anruf: Ein österreichischer Kunde bat uns, ihn bei der Migration eines On-Premises-Rechenzentrums in die Oracle Cloud Infrastructure (OCI) zu unterstützen und den anschließenden Betrieb zu übernehmen. Auf Basis der zur Verfügung gestellten Unterlagen erarbeiteten wir ein erstes Grobkonzept. Im Juni 2020 war es so weit, wir bekamen den Zuschlag für das Projekt und die Migration konnte starten. In diesem Artikel stellen wir wichtige Architekturaspekte und praktische Herausforderungen vor, die uns bei diesem Migrationsprojekt begegnet sind.

Warum Lift & Shift als Migrationsstrategie?

Unser Kunde, das Spinout eines europäischen Logistikdienstleisters und seit acht Jahren in Folge im Magic Quadrant von Gartner gelistet, stand kurz vor einer Umfirmierung. Dafür galt es, die virtuellen Server sowie die zentrale Exadata aus dem derzeitigen Rechenzentrum in eine Public Cloud zu überführen. Für die Migration von bestehenden Anwendungen, die in einer On-Premises-Umgebung laufen, können je nach identifizierten Handlungsbedarfen eine oder auch eine Kombination von unterschiedlichen Migrationsstrategien angewendet werden. Aufgrund des kurzen Zeitfensters – die Migration sollte innerhalb eines Monats abgeschlossen sein – entschied sich der Kunde für eine Lift-&-Shift-Migration.

Um welche Architektur ging es?

Die zentrale Anwendung, um die es in diesem Migrationsprojekt ging, besteht aus einer Reihe von unterschiedlichen Modulen, die jeweils in einer separaten JBoss- Instanz bereitgestellt werden.

Das Web Frontend für die Module wird mit einem Apache-Server abgebildet. Dieser nimmt die Requests der Webanwendung entgegen und leitet sie mithilfe des Apache-JServ-Protokolls (AJP) an die jeweiligen Module weiter. Neben eines Webzugangs besteht zusätzlich die Möglichkeit des Datenaustauschs mittels FTP, SFTP, OFTP2, AS2 oder JMS. Unterstützt wird die zentrale Anwendung durch eine Reihe von zusätzlichen Anwendungen. Insgesamt werden für die unterschiedlichsten Anwendungsfälle wie Entwicklung, Test, Schulung, Demo, Produktion usw. bis zu 15 unterschiedliche Umgebungen betrieben.

*Dieser Artikel erschien im Red Stack Magazin, dem Fachmagazin der Deutschen Oracle Anwendergruppe DOAG