Cloud Migration Pattern
It’s getting cloudy!
Den Weg in den Technologie Himmel durch praxiserprobtes Vorgehen
Viel wurde sich in den letzten Jahren von den Möglichkeiten der Cloud versprochen – schnell und günstig sollte Sie sein und dabei helfen, die technischen Altlasten in den Kernprozessen der Financial Services Industrie zu reduzieren. Ganze 91% der Banken und Finanzinstitute verwenden bereits Cloud Services oder Planen dies in naher Zukunft[1]. Davon verfolgen 75% dieser Finanzdienstleister laut Gartner einen Cloud-first Ansatz[2].
Die Antwort darauf ist auf den ersten Blick simpel: Die Cloud biete attraktive Vorteile wie erhöhte Geschwindigkeit beim Treiben von Innovation, Skalierbarkeit und unschlagbare Bereitstellungszeiten im Vergleich zu on-prem / in-house Lösungen und der Möglichkeit von Pay-as-you-go Lösungen.
Erstgespräch anfragen
Tristan
Pötzsch
André
Rentschler
Niklas
Fischer
Herausforderungen von Cloud Migrationen
- Der Start einer Cloud Migration ohne gut durchdachte Strategie kann zu einer Steigerung der Komplexität und Intransparenz der zukünftigen Infrastruktur führen
- -> Cloud Strategie (nicht nur Migrations-Strategie)
- Eine Migration kann sowohl aufgrund der fehlenden Strategie wie auch aufgrund von Fehlkalkulation beim Budget negativ oder vorzeitig enden.
- -> Budget-Plan für die Migration (der Cloud Strategie)
- Immer wieder kommt es vor das Unternehmen bei der Auswahl der Cloud Service Produkte, solche wählen die einem Vendor Lock-In unterliegen, und machen sich damit abhängig vom Cloud Anbieter. Dies ist aus Sicht von rechtlicher Sicht (BAIT) ein Problem.
- -> Produktauswahl im Einklang mit der Cloud Strategie und dem rechtlichen Rahmen
- Gerade in Europa ist ein wachsames Auge in Richtung Compliance & Security, insbesondere was die EU-DSGVO angeht, gerichtet aber auch anderweitig gibt es viele Aspekte die zu beachten sind, welche mit der Cloud Strategie vereinbart werden müssen.
- -> Data Governance, Compliance Anforderungen wie ISO 27001 und andere im Einklang mit der Cloud Strategie
Migration Pattern
Durch erprobte und in der Praxis erfolgreich durchgeführte Migration Pattern können die Herausforderungen einer solchen Migration minimiert oder teilweise vollkommen eliminiert werden.
Die zwei der sechs best practise Migrations Pattern sind grundsätzlich keine Migrations-Szenarien:
Retire: Alte oder bereits überholte Module werden On-prem abgeschaltet und nicht migriert
Retain: Module deren Migration im ersten Anlauf zu hohe komplexität darstellen werden vorerst im IST-Zustand belassen
Vier der Migration Pattern werden im Folgenden im Detail betrachtet, da sie in den best practises und in der Praxis die höchst frequentierten sind:
Lift and Shift (Rehost / Redeploy)
Szenario: Bei der Methode des Lift and Shift oder auch „Redeploy“ oder „Rehost“ wird eine Applikation in seiner Gänze ohne Veränderung am Code aus dem on-prem-Betrieb in die Cloud verlagert.
Beispiel aus der Praxis: Kunde A möchte seine Bare Metal Hardware-Kapazitäten gegen Cloud-Kapazitäten tauschen. Dafür soll zunächst der Sybase-Server, der auf einem veralteten eigen verwalteten Server des Kunden läuft, in die Cloud auf eine VM migriert werden. Ziel in diesem Praxisbeispiel ist die Auslagerung von Verantwortung, was den betrieb der Infrastruktur betrifft.
Problem: Limitierte Skalierung, benötigte Steigerung der Performance der Applikation, single-point of failure und/oder veraltete Software.
Lösung: Durch das Lift and Shift Vorgehen in die Cloud können die Vorteile der elastischen Skalierung von VM-Gruppen oder Clustern genutzt werden, sowie die Bereitstellung in mehreren Regionen oder verschiedenen Cloud Providern zur Maximierung der Failover-Funktionen.
Vorteile: Verbesserte Backup und Failover Funktion der Applikation, verbesserte Skalierbarkeit auf Modulebene.
Nachteile: Abhängigkeiten der Applikation zu anderen Bausteinen können sehr komplex sein, Integration von Cloud kann in der bestehenden on-prem Architecture weitere Komplexität bringen. Ein weiterer, wichtiger Aspekt ist das dies nur die Vorstufe zu weiterer Änderung sein muss da sonst alte Module, mit alten Eigenschaften in der Cloud laufen und dadurch kein Mehrwert entsteht.
Replatforming
Szenario: Beim Replatforming wird die Applikation, ähnlich wie bei Lift and Shift, in die Cloud verlagert. Allerdings wird nun die Applikation oder Komponenten durch Cloud native Services ersetzt, ohne die ursprüngliche Architektur der Applikation zu verändern.
Beispiel aus der Praxis: Kunde A hat sich nach Absprache mit den Enterprise Architekten gegen ein Lift and Shift vorgehen entschieden. Stattdessen soll ein Replatforming stattfinden. Die Sybase-Instanz solle nicht nur in eine VM in die Cloud, sondern direkt zu einem MS SQL Server, welcher fully managed als VM vom Cloud Provider via Marketplace (oder ähnliches) zu Verfügung gestellt wird, migriert werden.
Problem: Performancesteigerung ohne signifikante Änderungen an der Architektur und erneute Kapitalkosten im on-prem betrieb nicht möglich.
Lösung: Nutzung des Replatforming für des vollständigen oder teilweisen Einsatz von Cloud nativen Lösungen und Ausnutzung von Queues, Cloud nativen Datenbanken etc..
Vorteile: Unveränderte (gewohnte) Applikation mit verbesserter Performance, Möglichkeit der Weiterentwicklung der Applikation cloudnativ.
Nachteile: Bei weiterbestehen der Applikation bleiben auch damit verbundene Performance Probleme ungelöst, Rearchitecture nötig.
Rearchitecting (Refactoring)
Szenario: Eine Applikation, monolithischer Art, wird in einzelne Bestandteile, Microservices, geschnitten, um somit die Teile agiler und freier voneinander in die Cloud migrieren zu können.
Beispiel aus der Praxis: Kunde A hat derzeit einen Applikation Server auf dem sowohl dessen Web-Applikation des Kunden-Front-Ends läuft wie auch diverse APIs. Der Applikation-Server soll dekommisioniert werden und sowohl die Webplattform wie auch die APIs sollen in Containern umgesetzt werden. Da für das Kunden-Front-End größere Akzeptanz-Tests nötig sind verbleibt dieses im ersten Schritt auf dem on-prem Applikation-Server, bestehende APIs hingegen werden sofort in Container deployed und zukünftige werden direkt in der Cloud entwickelt.
Problem: Monolithische Applikationen können nicht agil auf Anforderungsänderungen und Weiterentwicklungen reagieren. Außerdem können diese nicht die potenziale von Lift and Shift oder Replatform nutzen, da bei diesen Applikationen die Probleme von innenheraus entstehen.
Lösung: Applikation wird durch Rearchitecture in kleinere Komponenten zerlegt / geschnitten. Diese Microservices können unabhängig voneinander on-prem laufen oder in die Cloud migriert werden.
Vorteile: optimale Voraussetzung von Skalierung und Performance, Multi-Cloud-Bereitstellung und agile Weiterentwicklung.
Nachteile: Applikation in passende kleine Komponenten zu schneiden ist sehr komplex, Durch rein technisch getriebene Modernisierung muss die Business-Seite reevaluiert werden.
Repurchase
Szenario: In-house programmierte Applikationen, die mittlerweile von externen 3ten oder direkt von Cloud Provider in der Cloud angeboten werden können, oft Teile oder ganze Applikationen ersetzen.
Beispiel aus der Praxis: Kunde A bezieht derzeit aus einer Handvoll selbst programmierten und verwalteten Schnittstellen zu einigen Data-Vendoren Stammdaten zu Wertpapieren. Da die ständige Weiterentwicklung und Verwaltung der Schnittstellen sehr aufwendig ist soll diese Infrastruktur durch Datashare und Pub/Sub (oder ähnliches) ersetzt werden.
Problem: vereinzelte existierende Komponenten bieten nicht mehr die gängigen technologischen Standards und erfüllen die technischen sowie businessseitigen Anforderungen nicht mehr.
Lösung: Applikation wird in der On-Prem Umgebung stillgelegt, und durch einen cloudnativen Service ersetzt.
Vorteil: Optimale Voraussetzung für Skalierung und Performance, Entfall von Wartungs- und Bereitstellungsaufwänden.
Nachteil: Möglicher Vendor-Lock In durch Provider spezifische Services, je nach Applikation können sich Compliance oder Regulatorik Probleme ergeben (z. B. DSGVO).
Cloud Migration in fünf Schritten
Eine Migration, egal welcher Natur, ist immer ein Einzelfall und keine Migration ist wie die andere. Daher behandeln wir bei NEXGEN jede Migration immer mit einem neuen Blick auf die Voraussetzungen und Wünsche unserer Kunden.
Aus diesem Grund haben wir ein eigenes extra dafür angefertigtes Migration Framework entwickelt, dass unseren Kunden Von der Planung bis zum GoLive die Migration so einfach wie möglich gestaltet.