Von der Idee zum Betrieb in fünf iterierten Schritten

On-Premises to Cloud – ein praxisbasiertes Vorgehensmodell

| Autor / Redakteur: Benjamin Rimkus* / Florian Karlstetter

On-Premises to Cloud (Op2C): Die Bestimmung der passenden Migrationsstrategie ist eine der wesentlichen Punkte zur Identifizierung der potentiellen Mehrwerte.
On-Premises to Cloud (Op2C): Die Bestimmung der passenden Migrationsstrategie ist eine der wesentlichen Punkte zur Identifizierung der potentiellen Mehrwerte. (Bild: adesso AG)

Die Erhöhung der Flexibilität und Geschwindigkeit bei der Bereitstellung von Ressourcen sind zwei der wesentlichen Gründe für eine Verlagerung von IT-Services in die Cloud. Während ein lokales Deployment von verschiedenen Diensten häufig eine Frage von mehreren Wochen ist, besteht in der Cloud die Möglichkeit, blitzschnell mehrere Server parallel zu provisionieren. Gleiches gilt für Datenbanken und Container bis hin zu KI-Diensten oder einer Data-Warehouse-Plattform.

Auf Knopfdruck steht nahezu jeder beliebige Service direkt in der Cloud zur Verfügung, vorausgesetzt man verwendet das richtige Vorgehensmodell. Aus genau diesen Gründen verlagerte sich bereits vor einiger Zeit die Diskussion darüber, ob Dienste und Applikationen in die Cloud verlagert werden, in Richtung wann und wie eine Cloud-Transformation erfolgen soll.

Genau in dieser Fragestellung liegen aktuell die größten Herausforderungen. In einem Cloud-Migrationsprojekt ist es nicht leicht, den passenden Einstiegspunkt zu ermitteln, da in der Regel ein konkreter Plan fehlt, welcher als roter Faden für das gesamte Vorhaben dient.

Durchdachtes Vorgehen ist essentiell

Es ist also ein passendes Vorgehen essentiell, um zukünftig die gewünschte Flexibilität zu erreichen und durch den gezielten Abbau von lokalen Ressourcen die Grundlage zu schaffen, um mittel- und langfristig die Betriebskosten nachhaltig zu senken. Das Liefermodell der Wahl ist die Hybrid Cloud, die als Grundlage einer gesamten Cloud-Transition dient.

Doch bevor der konkrete Aufbau der Architektur beginnt, ist zuerst die eigene Infrastruktur und Ausgangslage im Detail zu betrachten. Dies passiert während einer initialen IST-Analyse, gefolgt von der Ermittlung und Festlegung der Migrationsstrategie für die einzelnen IT-Services, welche in die Cloud gehören. Aus diesen Gründen werden diese beiden Phasen in den nachfolgenden Abschnitten genauer vorgestellt.

Die im vorliegenden Beitrag behandelten fünf Schritte einer Cloud-Transition finden Sie in Abbildung 1. Hier wird schnell klar, dass vor allem die Schritte 3 und 4 mehrere Iterationen durchlaufen, ähnlich einer agilen Vorgehensweise.

Die Empfehlung ist, nach Abschluss der ersten beiden Phasen, das Projekt in die einzelnen IT-Services zu unterteilen und anschließend iterativ vorzugehen. Schritt für Schritt wird das detaillierte Konzept für den Aufbau und die Verlagerung des jeweiligen IT-Service entwickelt und die Migration durchgeführt.

Schritt 1: IST-Analyse/Standortbestimmung

Abbildung 1: Adesso unterteilt die Cloud-Transition in fünf Schritte. Dabei wird deutlich, dass Schritt 3 und 4 mehrere Iterationen durchlaufen, ähnlich einem agilen Vorgehensmodell.
Abbildung 1: Adesso unterteilt die Cloud-Transition in fünf Schritte. Dabei wird deutlich, dass Schritt 3 und 4 mehrere Iterationen durchlaufen, ähnlich einem agilen Vorgehensmodell. (Bild: adesso AG)

Zentrale Aufgabe bei der IST-Analyse ist eine Antwort auf die folgende Fragestellung zu ermitteln: Wo sollen die einzelnen IT-Services und Workloads zukünftig positioniert werden? Um eine Antwort zu finden, ist eine Top-Down-Portfolio-Analyse (in Anlehnung an Microsoft „Enterprise Cloud Strategy“ (PDF) von Barry Briggs und Eduardo Kassner, ISBN: 978-1-5093-0196-6) durchzuführen. Diese Form der Analyse betrachtet die einzelnen IT-Services aus zwei verschiedenen Blickwinkeln – technisch und organisatorisch –, um die Schwierigkeit einer Migration und die potentiellen Mehrwerte zu identifizieren.

Schwierigkeit der Migration

Diese lässt sich maßgeblich durch die technischen Faktoren des jeweiligen IT-Services bestimmen. Die Kernthemen sind hier Sicherheit, Architektur, Risiken und der Betrieb (technisch).

Sicherheit

  • Kategorisierung der Daten: Einteilung der Daten in drei Klassen – Low-, Middle- und High-Business Impact. Beispielsweise sind Personally Identifiable Informations besonders schützenswert und haben bei Verlust eine negative Auswirkung auf das Geschäft. IT-Services, die PIIs verarbeiten, gehören deshalb in die Kategorie High-Business Impact
  • Ermittlung von Sicherheitsrisiken: Anforderungen an Informationssicherheit und Datenschutz auf Basis des Risikoprofils des Unternehmens
  • Identity- und Accessmanagement: Erfassung des bestehenden Berechtigungskonzepts zur Nutzung des IT-Services

Architektur

  • Zugangspunkte: Ermittlung der internen und externen Zugangspunkte zum jeweiligen IT-Service
  • Schnittstellen
  • Authentifizierung
  • Netzwerkanforderungen:

Welche Anforderungen stellt die Architektur in Richtung Netzwerk (zum Beispiel Quality of Service oder Aufbau in einer dedizierten DMZ)?

Risiken

  • Business Impact: Bewertung der Auswirkungen eines Ausfalls des IT-Services auf das Business
  • Technische Risiken: Ermittlung der Kerninfrastruktur, Abhängigkeiten und Bedrohungen (Risiko und Wahrscheinlichkeit)

Betrieb (technisch)

  • Wartungsintervalle
  • Monitoring
  • Backup

Potentielle Mehrwerte

Diese lassen sich hauptsächlich durch die fachlichen und organisatorischen Faktoren eines IT-Services bestimmen. Die wesentlichen Kernthemen sind Finanzen, IT-Service und der Betrieb (organisatorisch).

Finanzen: Gesamtbetriebskosten (TCO) und Rentabilität (ROI)

IT-Service: Anwender, Skalierbarkeit, Flexibilität

Betrieb (organisatorisch): Business Continuity Management (BCM), Verfügbarkeitsanforderungen, Service Level und Support.

Schritt 2: Migrationsstrategie bestimmen

Je höher das zukünftige Servicemodell, umso größer ist das potentielle Einsparpotential bezüglich Ressourcen und Betriebsaufwände. Dieses Einsparpotential entsteht, weil je nach Service Level mehr Verantwortung für Betrieb und Wartung der Plattform an den Betreiber übertragen wird.

Das zukünftige Servicemodell resultiert aus der Bestimmung der passenden Migrationsstrategie für die einzelnen IT-Services. Diese Ermittlung ist eine der wesentlichen Herausforderungen zur Erhebung der potentiellen Mehrwerte einer Cloud-Migration und bildet die Grundlage der anschließenden Konzeptionierung.

Im Jahr 2011 nannte Gartner fünf verschiedene Migrationsstrategien (The 5 R’s: Rehost | Refactor | Revise | Rebuild | Replace; siehe hierzu auch „Decision Point for Choosing a Cloud Migration Strategy for Applications“). Im Laufe der Zeit wurden diese fünf Ansätze in der Praxis jedoch leicht abgewandelt und überarbeitet, sodass viele zwar immer noch von den 5 R’s sprechen, aber mittlerweile eine Einteilung in sechs Kategorien erfolgt (siehe Abbildung 2). „Alles auf Anfang“; hinzu kam eine Repeat-Kategorie.

Je nach gewählter Migrationsstrategie hat dies maßgebliche Auswirkungen auf die ursprüngliche Architektur. Um dies zu verdeutlichen, werden die Veränderungen anhand einer Web App wie in Abbildung 3 dargestellt. Demnach besteht eine Web App in der Regel aus vier Schichten: Authentifizierung, Datenbank, Applikation und Präsentation.

Abschalten – Retire

Sollte es sich um eine Anwendung handeln, die nur einen sehr geringen Mehrwert im Verhältnis zu den Kosten erzeugt, dann ist zu untersuchen, ob zukünftig noch weitere Investitionen sinnvoll sind. In vielen Szenarien ist hier das ersatzlose Abschalten oder die Zusammenführung mit einer anderen Anwendung eine ernstzunehmende Option. Es ist nicht auszuschließen, dass IT-Services identifiziert werden, die nicht mehr aktiv in Nutzung sind.

Überspringen – Retain

Wenn die Anwendung erst vor einigen Wochen in den Betrieb übergegangen oder gerade im Zuge eines parallellaufenden Projekts modernisiert wird, dann eignet sich diese Anwendung zum jetzigen Zeitpunkt nicht für eine Cloud-Migration. Gleiches gilt für Anwendungen, die beispielsweise aufgrund einer Differenz zwischen den Online-Service-Terms des Providers und der eigenen Compliance-Anforderungen das lokale Rechenzentrum nicht verlassen können. In solchen Fällen ist die Anwendung zurückzustellen und später erneut zu betrachten.

Übertragen – Rehost (IaaS)

Die Eins-zu-eins-Übertragung der Serverinstanzen in die Cloud ist die einfachste Option für eine Migration. Dies bietet sich insbesondere bei Anwendungen an, die einen guten Mehrwert für das Unternehmen erzielen, der Betrieb jedoch zu aufwändig ist. Häufig wird dieses sogenannte Lift-and-Shift auch bei zweistufigen Migrationen angewendet. So kann im ersten Schritt die Anwendung mit den Daten in die Cloud übertragen und im zweiten Schritt die Systemarchitektur modernisiert werden.

Am Referenzbeispiel einer „Windows N-tier Application on Azure with SQL Server“ wird in Abbildung 4 gezeigt, dass die ursprüngliche Architektur bei der Übertragung nach MS Azure auf Netzwerkebene nur geringfügig erweitert wird. Der eigentliche Kern der Landschaft, die Serverinstanzen, bleiben dabei unberührt.

Vereinfachen – Replatform (IaaS/PaaS)

Die Vereinfachung ist zwischen einer Neuentwicklung und der Übertragung einzuordnen. Hier sind minimale Veränderungen an der Architektur durchzuführen, um den Gesamtbetriebsaufwand oder die Lizenzkosten zukünftig zu reduzieren. So ist es denkbar, eine SQL-Datenbank durch eine neuere Version auf Basis eines Database-as-a-Service-Dienstes auszutauschen, die restliche Architektur aber nur an die neue SQL-Version anzupassen.

Neuentwickeln – Refactor (IaaS/PaaS)

Beim Refactoring wird die vorhandene Architektur durch den Einsatz von Cloud-nativen Funktionen neugestaltet (siehe Abbildung 5). Generell ist die Neuentwicklung die aufwendigste Option zur Migration eines IT-Services, kann sich aber bei Kernprozessen, die aktuell einen aufwendigen Betrieb erfordern, schnell amortisieren. Im Gegensatz zum Rehosting ist bei einer vollständigen Neuentwicklung die ursprüngliche Architektur nicht mehr zu erkennen. (Quelle: Microsoft im Beitrag „Run a web application in multiple Azure regions for high availability“)

Ersetzen – Repurchase (SaaS)

Sollte ein äquivalentes Software-as-a-Service-Produkt existieren, so kann die Anwendung vollständig durch ein Cloud-Produkt ersetzt werden. Bei dieser Option ist immer zu prüfen, ob mehrere Anwendungen durch die Einführung eines neuen Produkts abzulösen sind.

Migrationsportfolio zusammenstellen

Benjamin Rimkus, Consultant im Bereich Infrastruktur & Technologie bei der adesso AG.
Benjamin Rimkus, Consultant im Bereich Infrastruktur & Technologie bei der adesso AG. (Bild: Adesso)

Zusammengefasst kann gesagt werden, dass die ersten beiden Schritte das Fundament einer jeden Cloud-Migration bilden. Auf Basis des entwickelten Migrationsportfolios (Abbildung 6) ist anschließend die individuelle Konzeptionierung der einzelnen IT-Services einzuleiten. Dabei empfiehlt es sich, mit einem IT-Service aus dem Quadrant Start Here oder Quick Wins zu beginnen. Diese sind potentiell leichter zu migrieren und erzielen schnell einen Mehrwert für das Unternehmen. Ein weiterer Vorteil ist, durch eine etwas leichtere Migration zu Beginn, erste Erfahrungen für komplexere Migrationen sammeln zu können. Im weiteren Projektverlauf bietet sich dann durchaus eine Parallelisierung der IT-Services an. Das Migrationsportfolio bildet also die Grundlage für die gesamte Cloud-Migration, wie Abbildung 6 zeigt.

Der Autor

Benjamin Rimkus, Jahrgang 1990, studierte Wirtschaftsinformatik (M.Sc.) an der WINGS in Wismar. Beim IT-Dienstleister adesso AG ist er als Consultant im Bereich Infrastruktur & Technologie unterwegs. Seine Tätigkeitsschwerpunkte liegen im Umfeld von Microsoft-Infrastruktur-Diensten wie Azure, Microsoft 365, Active Directory, Exchange und Skype for Business.

Kommentare werden geladen....

Kommentar zu diesem Artikel abgeben

Der Kommentar wird durch einen Redakteur geprüft und in Kürze freigeschaltet.

Anonym mitdiskutieren oder einloggen Anmelden

Avatar
Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
  1. Avatar
    Avatar
    Bearbeitet von am
    Bearbeitet von am
    1. Avatar
      Avatar
      Bearbeitet von am
      Bearbeitet von am

Kommentare werden geladen....

Kommentar melden

Melden Sie diesen Kommentar, wenn dieser nicht den Richtlinien entspricht.

Kommentar Freigeben

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

Freigabe entfernen

Der untenstehende Text wird an den Kommentator gesendet, falls dieser eine Email-hinterlegt hat.

copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45981080 / Allgemein)