Cyberbedrohungen
Los geht’s mit der Migration in die Cloud
Nach der reinen Etablierung der Cloud-Readiness aus Sicht der Organisation und Prozesse beginnen die Long-Runner: Migrationsprojekte. Wie die vier Phasen ablaufen und was dabei zu bedenken und entscheiden ist, lesen Sie hier.
Save to Folio
Sobald ein Unternehmen den Entschluss gefasst hat, auf Services aus der Cloud zu setzen, und danach eine entsprechende Strategie ausgearbeitet hat, werden darauf aufbauend Transformationsprogramme in Gang gesetzt. Diese Transformationsprogramme enthalten neben taktischen und strategischen Organisationsänderungen auch die Migrationen der heutigen Applikationslandschaft, die häufig viel Zeit in Anspruch nehmen. Ein Beispiel aus meiner frühen Tätigkeit betrifft etwa die Konsolidierung eines Versicherers von 21 auf 2 Rechenzentren bei einem deutschen Kunden. Am Ende des Projektes wurden alle relevanten Dienste zentral aus einer Aktiv-Standby-Struktur mit Disaster Recovery-Fähigkeit geliefert. Meine langjährige Beratertätigkeit bei Cloud-Projekten, schon mit den Vorläufern heutiger Initiativen, hat mich gelehrt, dass die Abläufe heutiger Cloud-Migrationsprojekte aus prozessualer Sicht nahezu deckungsgleich mit den früheren Initiativen (Rechenzentrums-Konsolidierungen) sind, technologisch aber deutlich ausgereifter.
Nach dem grundsätzlichen Projekt-Setup läuft die Migration in vier Phasen ab:
- Phase 1: IST-Aufnahme (Discovery & Assessment)
- Phase 2: Migrationsplanung (Migration Wave Planning)
- Phase 3: Migrationsdurchführung (Execution)
- Phase 4: Betriebsübergang (Operations & Optimization)
Eine Grundregel solcher Vorhaben beinhaltetet immer einen Design-Freeze für die Infrastrukturen, denn es gab nur selten erfolgreiche Projekte (erfolgreich = in Budget, in Time!), in denen sich die Verschiebung und Konsolidierung von Diensten mit einer Transformation der Dienste verbinden ließ. Die Konsolidierung und Standardisierung sollten entkoppelt werden, denn wer will schon gern sein Oracle-to-SQL Projekt mit seinen Risiken parallel zur Rechenzentren-Konsolidierung durchführen und die Überlagerung der Risiken zusätzlich managen. Bei der Migration in die Cloud hängt alles von der gewählten Strategie je Workload ab.
Phase 1: Brauchen wir diesen Server eigentlich noch?
Auf dem Weg der Weiterentwicklung und potenziellen Cloud-Migration steht am Anfang die Bestandsaufnahme. Toolgestützt und auch mit viel manuellem Aufwand gilt es alle Assets im Unternehmensnetzwerk zu erfassen (Discovery) und den Applikationsbestand aufzunehmen (Assessment). Der Applikationsbestand ist dabei keine reine Serverliste mit Zuordnung der Applikation, sondern umfasst natürlich auch die Zusammenstellung aller installierten Pakete und ihrer Versionsstände je Asset und (nochmal wichtiger) die Zusammenstellung, welche Assets zusammenhängend welchen (IT) Service erbringen. Eine klare Zuordnung von Assets zu Workloads, aber auch zu ihren fachlichen Ownern ist heute in nicht-Enterprise-ITs erschreckend oft nicht oder nur ungenügend gepflegt vorhanden.
Hier gibt es nicht selten Überraschungen und man findet ein Vielfaches an Versionsständen und Anwendungen, die man ursprünglich nicht so erwartet hat. Allzu schnell fällt dabei auf, dass eigentliche Richtlinien, wie beispielsweise eine „N + 1“ Versionsstrategie im operativen Betrieb schlichtweg vernachlässigt wurden. Somit finden sich nicht nur zwei Patch-Stände einer Software im Einsatz, sondern mannigfache Varianten mit ihren individuellen potenziellen Schwachstellen. Dabei war die ursprüngliche Vermutung, dass beispielsweise doch nur SQL Server erfasst werden, und das kann ja nicht so schwer sein.
Die Geschichte von Haustieren und Herden („Pets and Cattles“)
In der klassischen IT-Umgebung, in der der Admin noch jede Maschine persönlich kennt, wird jede Maschine gehegt und gepflegt wie ein Haustier. Der DNS-Name und die IP sind wohlbekannt, die Maschinen werden installiert, gepatcht, regelmäßig überwacht und von Unrat freigehalten, so gut es geht. Die Administratoren kennen die Macken im täglichen Betrieb und wissen, welchen Service sie hier und da neu starten müssen, weil der Server mal wieder „rumzickt“. Unabhängig von der installierten Workload ist der Betriebsaufwand manuell oder durch eine Softwareverteilung automatisiert relativ hoch, da sie ja zu einem eigenen Zweck erstellt wurde und die Maschine ihr Dasein fristet, bis sie ihren Zweck erfüllt hat – oder durch eine neue Maschine ersetzt wird.
Mit zunehmender Automatisierung und Orchestrierung werden Maschinen vollautomatisiert bereitgestellt (Stichwort: Infrastructure-as-Code) und wenn möglich gleich „stateless“ gehalten. Dieser Automationsgrad dient insbesondere dazu, dass sie bei einem Ausfall zwar Untersuchungen anstellt, aber jederzeit eine neue Maschine den Platz einnehmen kann.
Mit Container-Diensten und Microservices wird dieses Konzept weitergedacht, denn Workloads werden in Services aufgeteilt, die ihr Dasein hinter Loadbalancern versteckt und durch Health-Monitoring überwacht in Gruppen anonymer Container verbringen. Hier drängt sich schon der Gedanke einer Herde auf, in der auch mal ein Tier sterben kann, was aber weniger „schlimm“ ist, denn Neue werden regelmäßig hinzugefügt, solange es die umgebende Situation zulässt. In der Cloud kommen also weitere Container in einen Service hinzu, dessen Last steigt, während bei weniger Last Container abgeschaltet und gelöscht werden; der Ausfall des Einzelnen findet weniger Beachtung als ein Server in der klassischen IT.
Eben jener Unterschied ermöglicht es, mit geringem Aufwand und hoher Automation Workloads effizienter zu gestalten - Haustiere und Herden eben.
Phase 2: Das AWS 6-R Migrations-Modell
Sobald es also einen brauchbaren Überblick über alle Maschinen, Services und Workloads gibt, gilt es, eine Migrationsplanung zu erstellen, so dass Services in ihrer Gesamtheit unter Berücksichtigung ihrer Abhängigkeiten migriert werden können, damit der produktive IT-Betrieb möglichst unterbrechungsfrei weiter erfolgen kann. Die Migration an sich wird zwar Kosten erzeugen, aber ob sie direkte Mehrwerte beinhaltet oder nur kosmetischer Natur ist, muss sich zeigen.
Die 6-R Strategie umfasst folgende Migrationsmodelle:
- Retire: Keine wirkliche Migration, aber die am wenigsten aufwändige Strategie. Ein Workload wird nicht mehr benötigt – also führen Sie die erforderlichen Maßnahmen (bpsw. Archivierung) durch, bauen die Applikation ab und geben die Ressourcen frei, die die Anwendung konsumiert.
- Retain: Auch eine absolut übliche Variante. Sie haben keine valide Migrationsoption für einen Workload gefunden. Gründe können technologischer oder auch wirtschaftlicher Natur sein – manchmal ist der Aufwand nicht gerechtfertigt oder die Risiken rechtfertigen die Migration nicht. Erreicht die Applikation beispielsweise ohnehin bald das Ende ihres Lebenszyklus, dann braucht man sie nicht anfassen. Wichtig: Diese Applikationen prüfen Sie zukünftig regelmäßig erneut, um zu sehen, wie damit umzugehen ist.
- Die eigentlichen Migrationen, bei denen Workloads bewegt werden sind:
- Re-host: Workloads auf physischen oder virtuellen Maschinen können mit sehr wenig Aufwand auf virtuelle Maschinen/IaaS Services in Private oder Public Clouds migriert werden. Dieses Verfahren wird auch als Lift & Shift bezeichnet, wenngleich man damit früher das Transportieren eines Servers von einem Standort zum neuen Rechenzentrum meinte. Gering ist nicht nur der Aufwand an dieser Stelle, sondern leider auch die Vorteile, die sich daraus ergeben. Die VM läuft nach der Migration in der Cloud – nicht mehr und nicht weniger -- eben jene Geschichte von Haustieren und Herden. Re-Hosting kommt dort zum Einsatz, wo sich keine bessere Strategie findet, oder einfach Ressourcen am Quellort freigeschaufelt werden wollen.
- Replace: Dieser Ansatz wird auch Re-Purchase genannt. Die alte Lösung wird durch eine neue Lösung abgelöst, die den Zweck gleich oder besser erfüllt. Besser muss dabei nicht immer die bessere Lösung bedeuten, aber wenn Sie auf einen Standard-Service setzen, können Sie auch einige Schmerzen verkraften, die vielleicht mit dem Betrieb der alten Lösung einhergingen. Replace-Migrationen finden auch beim Move zu SaaS Lösungen häufig statt. Lokale CRM Systeme werden beispielsweise durch Salesforce.com abgelöst, oder die lokale Exchange Plattform durch Microsoft 365 Dienste. Der Vorteil besteht darin, dass mit dem Move zu SaaS die Fertigungstiefe und damit die Betriebsaufwände für solche Dienste massiv reduziert werden, da man sich nicht mehr um die unterliegende Infrastruktur kümmern muss. Das Hardware-Lifecycle-Management, der Betrieb der Plattform, die Facility-Sicherheit, etc. sind nun Aufgabe des Service-Providers.
- Re-Platform: Dort wo sich keine adäquate Lösung für die Ablöse des kompletten Workloads findet, bieten sich Möglichkeiten, Plattform-Dienste der Cloud-Provider zu verwenden. Auf diesem Wege kann man beispielsweise statt des Aufbaus und Betriebs von SQL Always-On Clustern (als ein Beispiel) auf die Nutzung von RDS (Relational Database Services) Diensten der Cloud-Provider setzen und Redundanzfunktionen hinzufügen. Der Service-Betreiber ist also hier für Infrastruktur- und Datenbank-Dienste verantwortlich, während der Anwender seine Datenbanken aus dem Dienst konsumiert. Auch auf diesem Wege können Sie ihre Applikationen und Workloads neu konzipieren und die Aufwände im täglichen Betrieb reduzieren.
- Re-Architect: Die vierte Methode betrifft maßgeblich selbst-entwickelte Applikationen. Historisch entwickelte Monolithen, die fest an bestimmte Architekturen oder Konzepte gebunden sind, werden grundlegend neu gedacht. Hierbei werden neue Architekturen und Konzepte (Cloud-Native, Microservices, serverless Functions, etc.) genutzt, um mit der Zeit die alte Lösung abzulösen. Häufig sind dies lang laufende Projekte, mit denen Unternehmen klassische Unzulänglichkeiten alter Architekturen (insbesondere Skalierungsprobleme) langfristig lösen und Abhängigkeiten zu bestehenden Umgebungen weg-abstrahieren. Die Chance ist enorm, hierbei deutlich mehr aus dem Service zu holen.
Der zeitliche und somit auch der monetäre Aufwand je Methode ist individuell je Workload abzuwägen und hängt auch stark davon ab, wie die Lifecycle-Planung je Service aussieht. Am Ende einer erfolgreichen Migration müssen Sie die Ziele ihrer „Cloudifizierung“ auch nachweisen und die reine Ratio der Cloud Adoption ist sicherlich als KPI unzureichend, wenn die Kosten jedes Budget und jeden Nutzen überschreiten.
Phase 3: Planung beendet, ran an die Migration
In der Migrationsphase geht es nun an die Ausführung. In Migrations- und Projektteams werden die Migrationswellen sukzessive ausgeführt. Typischerweise startet man mit einigen Quick-Wins und solchen Migrationen, die eine hohe Erfolgsaussicht und hohe Visibilität haben, damit die Benutzer und Stakeholder Erfolge sehen.
Je nach Umfang des Programms wird ein PMO (Project Management Office) die Fortschritte überwachen und regelmäßige Status-Berichte zur Verfügung stellen -- denn es wird knirschen und es wird zu Ausfällen kommen. Unwägbarkeiten professionell zu begegnen und „Management of Change“ anwenden, ist hier die Devise.
Da die größten Brocken zum Schluss kommen – als Beispiel ein Megaprojekt, wie die Ablöse eines Mainframes durch Cloud-native Services – gilt es hier auch einen langen Atem zu haben und am Ball zu bleiben. Das richtige Management und ein gutes Auge für frühzeitiges Eingreifen und regelmäßige Prüfung, ob die richtigen Skills in ausreichender Kapazität am Werk sind, gelten hier als Garanten, die Teams vom nächsten Red-Flag-Projekt fernhalten.
Phase 4: Lebenserhaltung und Optimierung
Wer es im Projekt bis zu dieser Phase geschafft hat, gehört zu den wenigen, die die Unternehmung Cloud-Migration hoffentlich mit nicht allzu vielen Blessuren überstanden haben. Vor Start der Migration haben Sie vermutlich ihr Cloud Office gegründet – also die Abteilung, die als Service Broker und Operator der Cloud-Umgebungen fungiert und die Einhaltung der Governance und Sicherheit überwacht.
Nach erfolgter Migration jeder Workload geht die Verantwortung an den operativen Betrieb, sei es ein DevOps-Team oder ein klassischer IT-Betrieb für die Services mit weniger Varianz im täglichen Ablauf. Das Cloud Management Team wird ebenfalls gemeinsam mit dem SOC eine zentrale Rolle spielen bei der Überwachung der Prozesse, der Korrelation der anfallenden Events in der Cloud und bei der Einhaltung der Richtlinien und Gesetze, die für ihr Unternehmen gelten. Mit den Assets, die in die Cloud wandern, wird sich auch die digitale Angriffsfläche natürlich vergrößern. Bleiben Sie also am Ball, was die Absicherung und das kontinuierliche Monitoring anbelangt.
Erfahrung schlägt Motivation
Aus Sicht einer Cloud und Datacenter-Beraters ist diese Art der Projekte in der IT-Infrastruktur die Königsdisziplin. Das Zusammenführen, Standardisieren, Rationalisieren einer Gesamt-IT ist eine spannende Aufgabe, die die Protagonisten Mensch, Prozess & Technologie auf die nächste Ebene der Effizienz heben kann. Der Austausch mit erfahrenen Kollegen und Beratern ist meine dringendste Empfehlung, denn hier wird auch viel Geld verbrannt und man droht, sich am eigenen Vorhaben zu verheben.