Keine (Public) Cloud ist für die Ewigkeit. Mit diesen Best Practices gelingt die Cloud-zu-Cloud-Migration.Sinesp | shutterstock.com In der Vergangenheit war Cloud-Migration vor allem ein Synonym dafür, lokale Workloads in Public-Cloud-Infrastrukturen zu verlagern. Zu diesem Zweck gibt es auch jede Menge unterstützende Leitfäden und Tools. Mittlerweile ist rund die Hälfte aller Unternehmen in der Public Cloud angekommen – nur um mit einer neuen Migrationsherausforderung konfrontiert zu werden: Wie lassen sich Workloads optimal von einer Public Cloud in eine andere verschieben? Cloud-zu-Cloud-Migrationen sind für die meisten Anwender absolutes Neuland. Leider stehen hilfreiche, unterstützende Ressourcen zu diesem Thema ebenfalls nur in überschaubarem Umfang zur Verfügung. Zwar bieten einige Cloud-Anbieter dedizierte Tools (etwa Azure Migrate oder AWS Server Migration Service), mit denen bestimmte Objekttypen zwischen Clouds migriert werden können. Diese lassen jedoch komplexe Probleme außen vor, die beispielsweise entstehen, wenn Netzwerke neu konfiguriert oder Hunderte von Terabyte an Daten mit begrenzter Bandbreite übertragen werden müssen. Mit diesem Artikel möchte ich Business-Anwendern auf Grundlage meiner Cloud-Expertise eine Hilfestellung an die Hand geben, um möglichst reibungslos von einer Public Cloud in eine andere zu migrieren. Dazu blicken wir zunächst auf die Gründe für solche Migrationsvorhaben sowie die Problemstellungen, die dabei entstehen können. Abschließend geben wir Ihnen einige Best Practices für Cloud-zu-Cloud-Migrationen an die Hand. Warum Unternehmen die Public Cloud wechseln Es gibt verschiedene Gründe, warum Unternehmen von einer Public Cloud in eine andere wechseln wollen – oder müssen. Zum Beispiel, weil: nach einer Übernahme oder Fusion mehrere Cloud-Instanzen genutzt werden, die im Rahmen einer IT-Umstrukturierung in einer Plattform konsolidiert werden sollen. eine spezifische Public Cloud aufgrund ihres Preisgefüges, ihrer Performance oder den verfügbaren Standorten nicht mehr optimal geeignet ist, sodass ein Wechsel zu einer alternativen Public-Cloud-Plattform nötig wird. Auch wenn ein Multicloud-Ansatz an dieser Stelle einige Flexibilitäts- und Kostenvorteile erschließen könnte, er bringt auch Nachteile mit sich. Ein ganz wesentlicher ist die zusätzliche Komplexität: Mehrere Clouds zu nutzen, bedeutet auch zusätzliche Ressourcen überwachen und managen zu müssen – und erfordert außerdem zusätzliche Tools, um sämtliche potenziellen Performance- und Security-Probleme identifizieren zu können. Und dann haben wir noch nicht über die dafür nötigen IT-Experten gesprochen. Deshalb ist es für diverse Anwenderunternehmen attraktiver, sich auf eine Public Cloud zu fokussieren – statt zu versuchen, mehrere verschiedene zu nutzen. Scott Wheeler ist Cloud Practice Lead bei Asperitas Consulting.Scott Wheeler 5 Cloud-zu-Cloud-Migrationshürden Auf den ersten Blick scheint es nicht besonders diffizil, von einer Public Cloud in eine andere zu wechseln. Schließlich bieten sämtliche Public Clouds in etwa dieselben Kern-Services und basieren auf denselben Konzepten. Auf den zweiten Blick erkennt man jedoch schnell, dass Public-Cloud-Plattformen weit weniger einheitlich sind, als sie zunächst scheinen. Die folgenden Hürden können eine Cloud-zu-Cloud-Migration erschweren – oder zumindest verlangsamen: 1. Service-Differenzen Obwohl die grundlegenden Arten von Services, die Public Clouds bieten, weitgehend identisch sind, gibt es mit Blick auf die Implementierung Unterschiede. Einen Workload von einer Cloud in die andere zu verschieben und einfach davon auszugehen, dass alles einwandfrei funktioniert, kann deshalb zu bösen Überraschungen führen. Sie sollten davon ausgehen, Ihre Konfigurationen anpassen zu müssen. Nehmen wir als Beispiel CosmosDB und DynamoDB: Es handelt sich um verwaltete NoSQL-Datenbanken, die auf Azure, beziehungsweise AWS bereitgestellt werden. Auf hoher Ebene erfüllen sie denselben Zweck. Im Hintergrund werden Prozesse wie Datenreplikation oder -indizierung jedoch unterschiedlich gehandhabt. Auch preislich unterscheiden sich die Angebote. Und es gibt keine Garantie dafür, dass eine Konfiguration, die die Performance für CosmosDB optimiert, das auch im Fall von DynamoDB (in gleichem Maße) tut. Aus diesem (und weiteren) Gründen ist es nicht ratsam, Daten aus Cosmos zu extrahieren und einfach in DynamoDB zu übertragen. Stattdessen steht ein komplexer Migrationsprozess an, bei dem die Daten offline genommen, transformiert und anschließend übertragen werden müssen. Das erfordert möglicherweise auch umfassende Änderungen an Konfigurationen und Datenstrukturen. 2. Latenz-Challenges Wie schnell Daten innerhalb einer Public-Cloud-Instanz verschoben werden können, hängt in hohem Maße davon ab, wo sich der spezifische Workload oder Service befindet. Daten zwischen Cloud-Regionen auf demselben Kontinent zu verschieben, ist in der Regel mit geringeren Latenzen verbunden als bei einer interkontinentalen Datenübertragung. Weil sich die Regionen der einzelnen Cloud-Anbieter jedoch mit Blick auf die jeweilige Verortung der Rechenzentren unterscheiden, kann die Latenz nach einer Cloud-Migration zu einem Problem werden, wenn die Regionen in der neuen Cloud nicht sorgfältig ausgewählt und konfiguriert werden. Latenzprobleme können auch auftreten, wenn ein Unternehmen SaaS-Dienste oder lokale Anwendungen nutzt, die nicht in der Cloud gehostet werden – dabei aber Daten über Public-Cloud-Ressourcen gesendet oder empfangen werden müssen. In diesem Fall kann die Entfernung des Rechenzentrums zum Standort, an dem SaaS- und lokale Ressourcen gehostet sind, die Übertragungsgeschwindigkeit beeinträchtigen und damit Netzwerkverzögerungen begünstigen. Es ist deshalb essenziell, die Cloud-Abhängigkeiten und -Wechselwirkungen mit Blick auf die gesamte IT-Umgebung des Unternehmens zu verstehen. 3. Automatisierungs-Umschwung Um ihre Kunden dabei zu unterstützen, Workloads zu integrieren und Daten zu migrieren, bieten die Cloud-Provider Automatisierungs-Tools an. Diese sind im Regelfall mit weiteren Tools verbunden, die ausschließlich in der jeweiligen Cloud-Umgebung funktionieren – und von deren jeweiligen Konfigurationseinstellungen und Sprachen abhängig sind. Auch in diesem Bereich ist es nicht möglich, die Tools einfach von einer Public Cloud in die andere zu schieben. Vielmehr müssen diese übersetzt oder neu erstellt werden – es sei denn, es handelt sich um Cloud-unabhängige Lösungen von Drittanbietern. Selbst in diesem Fall ist die Wahrscheinlichkeit jedoch hoch, dass zumindest die entsprechenden Konfigurationen aktualisiert werden müssen. 4. Kosten-Explosionen Selbst bei vergleichbaren Service-Typen kann deren Preisgestaltung erheblich von Anbieter zu Anbieter variieren. Eine Workload-Konfiguration, die in einer Cloud aus Preis-Leistungs-Perspektive optimal ist, kann deshalb in einer anderen suboptimal sein. Das kann potenziell zu massiver Geldverschwendung führen, wenn die Konfiguration im Rahmen des Migrationsprozesses nicht an die neue Preisstruktur angepasst wird. 5. Bandbreiten-Einschränkungen Die einfachste Möglichkeit, Daten während einer Migration von einer Public Cloud in eine andere zu verschieben, führt über eine VPN-Verbindung. Leider wird dabei das öffentliche Internet der Cloud-Anbieter genutzt, was die Datenübertragungsleistung einschränkt. Außerdem kann das im Fall von großen Datenmengen wesentlich teurer ausfallen als eine dedizierte Verbindung. Sollen bei einer Cloud-zu-Cloud-Migration also viele Terabyte an Daten übertragen werden, kann das erhebliche logistische und finanzielle Hürden aufwerfen. 5 Best Practices, um zwischen Public Clouds zu migrieren Eine Zauberformel – oder zumindest eine spezielle Migrationssoftware – für Cloud-zu-Cloud-Migrationen wäre toll, ist aber nicht existent. Unabhängig davon, wie genau Sie vorgehen, ist eines sicher: Von einer Public Cloud in eine andere zu wechseln, ist komplex und erfordert jede Menge Zeit und Aufwand. Allerdings gibt es aus meiner Sicht einige Best Practices, die Sie einsetzen können, um diesen Prozess so reibungslos wie möglich zu gestalten: 1. Besser planen Eine möglichst sorgfältige Planung ist in Zusammenhang mit Cloud-zu-Cloud-Migrationen das A und O. Entwickeln Sie belastbare Strategien, testen Sie diese mit Dummy-Workloads und finden Sie heraus, was funktioniert und was nicht. Je mehr Zeit Sie für den Planungsprozess aufwenden, desto geringer ist das Risiko, während der Migration auf unerwartete Hindernisse zu stoßen. 2. Realistische Zeitpläne definieren Zeitpläne, die auf realistischen Erwartungen beruhen, sind von Seiten des Managements des Öfteren nicht zu erwarten, weil die Führungskräfte in der Regel die Feinheiten solcher Migrationsprojekte nicht auf dem Schirm haben. Deshalb empfiehlt es sich, von vorneherein transparent zu kommunizieren, wenn es um die Dauer eines Migrationsvorhabens geht. Die schlechte Alternative wäre, dem Management Dinge zu versprechen, die nicht gehalten werden können – und den Zeitplan während der Migration immer wieder anzupassen. 3. Unkritische Workloads zuerst Starten Sie eine Cloud-zu-Cloud-Migration nicht mit Business-kritischen Workloads. Fokussieren Sie sich lieber auf solche, die sich in der Entwicklungs- oder Testphase befinden. Wenn aufgrund einer Planungslücke etwas schiefgeht, machen sich Probleme bei unkritischen Workloads „besser“. Geschäftskritische Applikationen und Daten sollten sie für eine spätere Migrationsphase „reservieren“. 4. Neue Deployments pausieren Ein wichtiger, aber regelmäßig übersehener Aspekt bei der Cloud-zu-Cloud-Migration: Neue Deployments für Anwendungen sowie Änderungen an Plattformen oder Konfigurationen sollten während des Migrationsprozesses auf Eis gelegt werden. Angenommen die Entwickler stellen die neue Version einer Anwendung in einer Cloud bereit, während das IT-Team gerade dabei ist, die ältere Version in eine andere Cloud zu verschieben: In diesem Fall müssten Sie die Migration komplett wiederholen und sämtliche Änderungen, die während der Migration an einer Cloud-Plattform vorgenommen werden, in der neuen Plattform reproduzieren. 5. Interconnection-Services nutzen Die Internetverbindungen zwischen Public Clouds sind relativ langsam. Eine Möglichkeit, die Bandbreite zu erhöhen – und damit die Migration von Cloud zu Cloud zu beschleunigen – führt über Cloud-Interconnections. Diese Lösungen (wie sie beispielsweise Megaport, NuSummit oder Equinix anbieten) bieten dedizierte Verbindungen zwischen Clouds mit hoher Bandbreite. Das ermöglicht, Daten wesentlich schneller zu migrieren. Der Nachteil: Interconnection-Services sind nicht billig. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Zwischen Public Clouds migrieren – so geht‘s
Keine (Public) Cloud ist für die Ewigkeit. Mit diesen Best Practices gelingt die Cloud-zu-Cloud-Migration.Sinesp | shutterstock.com In der Vergangenheit war Cloud-Migration vor allem ein Synonym dafür, lokale Workloads in Public-Cloud-Infrastrukturen zu verlagern. Zu diesem Zweck gibt es auch jede Menge unterstützende Leitfäden und Tools. Mittlerweile ist rund die Hälfte aller Unternehmen in der Public Cloud angekommen – nur um mit einer neuen Migrationsherausforderung konfrontiert zu werden: Wie lassen sich Workloads optimal von einer Public Cloud in eine andere verschieben? Cloud-zu-Cloud-Migrationen sind für die meisten Anwender absolutes Neuland. Leider stehen hilfreiche, unterstützende Ressourcen zu diesem Thema ebenfalls nur in überschaubarem Umfang zur Verfügung. Zwar bieten einige Cloud-Anbieter dedizierte Tools (etwa Azure Migrate oder AWS Server Migration Service), mit denen bestimmte Objekttypen zwischen Clouds migriert werden können. Diese lassen jedoch komplexe Probleme außen vor, die beispielsweise entstehen, wenn Netzwerke neu konfiguriert oder Hunderte von Terabyte an Daten mit begrenzter Bandbreite übertragen werden müssen. Mit diesem Artikel möchte ich Business-Anwendern auf Grundlage meiner Cloud-Expertise eine Hilfestellung an die Hand geben, um möglichst reibungslos von einer Public Cloud in eine andere zu migrieren. Dazu blicken wir zunächst auf die Gründe für solche Migrationsvorhaben sowie die Problemstellungen, die dabei entstehen können. Abschließend geben wir Ihnen einige Best Practices für Cloud-zu-Cloud-Migrationen an die Hand. Warum Unternehmen die Public Cloud wechseln Es gibt verschiedene Gründe, warum Unternehmen von einer Public Cloud in eine andere wechseln wollen – oder müssen. Zum Beispiel, weil: nach einer Übernahme oder Fusion mehrere Cloud-Instanzen genutzt werden, die im Rahmen einer IT-Umstrukturierung in einer Plattform konsolidiert werden sollen. eine spezifische Public Cloud aufgrund ihres Preisgefüges, ihrer Performance oder den verfügbaren Standorten nicht mehr optimal geeignet ist, sodass ein Wechsel zu einer alternativen Public-Cloud-Plattform nötig wird. Auch wenn ein Multicloud-Ansatz an dieser Stelle einige Flexibilitäts- und Kostenvorteile erschließen könnte, er bringt auch Nachteile mit sich. Ein ganz wesentlicher ist die zusätzliche Komplexität: Mehrere Clouds zu nutzen, bedeutet auch zusätzliche Ressourcen überwachen und managen zu müssen – und erfordert außerdem zusätzliche Tools, um sämtliche potenziellen Performance- und Security-Probleme identifizieren zu können. Und dann haben wir noch nicht über die dafür nötigen IT-Experten gesprochen. Deshalb ist es für diverse Anwenderunternehmen attraktiver, sich auf eine Public Cloud zu fokussieren – statt zu versuchen, mehrere verschiedene zu nutzen. Scott Wheeler ist Cloud Practice Lead bei Asperitas Consulting.Scott Wheeler 5 Cloud-zu-Cloud-Migrationshürden Auf den ersten Blick scheint es nicht besonders diffizil, von einer Public Cloud in eine andere zu wechseln. Schließlich bieten sämtliche Public Clouds in etwa dieselben Kern-Services und basieren auf denselben Konzepten. Auf den zweiten Blick erkennt man jedoch schnell, dass Public-Cloud-Plattformen weit weniger einheitlich sind, als sie zunächst scheinen. Die folgenden Hürden können eine Cloud-zu-Cloud-Migration erschweren – oder zumindest verlangsamen: 1. Service-Differenzen Obwohl die grundlegenden Arten von Services, die Public Clouds bieten, weitgehend identisch sind, gibt es mit Blick auf die Implementierung Unterschiede. Einen Workload von einer Cloud in die andere zu verschieben und einfach davon auszugehen, dass alles einwandfrei funktioniert, kann deshalb zu bösen Überraschungen führen. Sie sollten davon ausgehen, Ihre Konfigurationen anpassen zu müssen. Nehmen wir als Beispiel CosmosDB und DynamoDB: Es handelt sich um verwaltete NoSQL-Datenbanken, die auf Azure, beziehungsweise AWS bereitgestellt werden. Auf hoher Ebene erfüllen sie denselben Zweck. Im Hintergrund werden Prozesse wie Datenreplikation oder -indizierung jedoch unterschiedlich gehandhabt. Auch preislich unterscheiden sich die Angebote. Und es gibt keine Garantie dafür, dass eine Konfiguration, die die Performance für CosmosDB optimiert, das auch im Fall von DynamoDB (in gleichem Maße) tut. Aus diesem (und weiteren) Gründen ist es nicht ratsam, Daten aus Cosmos zu extrahieren und einfach in DynamoDB zu übertragen. Stattdessen steht ein komplexer Migrationsprozess an, bei dem die Daten offline genommen, transformiert und anschließend übertragen werden müssen. Das erfordert möglicherweise auch umfassende Änderungen an Konfigurationen und Datenstrukturen. 2. Latenz-Challenges Wie schnell Daten innerhalb einer Public-Cloud-Instanz verschoben werden können, hängt in hohem Maße davon ab, wo sich der spezifische Workload oder Service befindet. Daten zwischen Cloud-Regionen auf demselben Kontinent zu verschieben, ist in der Regel mit geringeren Latenzen verbunden als bei einer interkontinentalen Datenübertragung. Weil sich die Regionen der einzelnen Cloud-Anbieter jedoch mit Blick auf die jeweilige Verortung der Rechenzentren unterscheiden, kann die Latenz nach einer Cloud-Migration zu einem Problem werden, wenn die Regionen in der neuen Cloud nicht sorgfältig ausgewählt und konfiguriert werden. Latenzprobleme können auch auftreten, wenn ein Unternehmen SaaS-Dienste oder lokale Anwendungen nutzt, die nicht in der Cloud gehostet werden – dabei aber Daten über Public-Cloud-Ressourcen gesendet oder empfangen werden müssen. In diesem Fall kann die Entfernung des Rechenzentrums zum Standort, an dem SaaS- und lokale Ressourcen gehostet sind, die Übertragungsgeschwindigkeit beeinträchtigen und damit Netzwerkverzögerungen begünstigen. Es ist deshalb essenziell, die Cloud-Abhängigkeiten und -Wechselwirkungen mit Blick auf die gesamte IT-Umgebung des Unternehmens zu verstehen. 3. Automatisierungs-Umschwung Um ihre Kunden dabei zu unterstützen, Workloads zu integrieren und Daten zu migrieren, bieten die Cloud-Provider Automatisierungs-Tools an. Diese sind im Regelfall mit weiteren Tools verbunden, die ausschließlich in der jeweiligen Cloud-Umgebung funktionieren – und von deren jeweiligen Konfigurationseinstellungen und Sprachen abhängig sind. Auch in diesem Bereich ist es nicht möglich, die Tools einfach von einer Public Cloud in die andere zu schieben. Vielmehr müssen diese übersetzt oder neu erstellt werden – es sei denn, es handelt sich um Cloud-unabhängige Lösungen von Drittanbietern. Selbst in diesem Fall ist die Wahrscheinlichkeit jedoch hoch, dass zumindest die entsprechenden Konfigurationen aktualisiert werden müssen. 4. Kosten-Explosionen Selbst bei vergleichbaren Service-Typen kann deren Preisgestaltung erheblich von Anbieter zu Anbieter variieren. Eine Workload-Konfiguration, die in einer Cloud aus Preis-Leistungs-Perspektive optimal ist, kann deshalb in einer anderen suboptimal sein. Das kann potenziell zu massiver Geldverschwendung führen, wenn die Konfiguration im Rahmen des Migrationsprozesses nicht an die neue Preisstruktur angepasst wird. 5. Bandbreiten-Einschränkungen Die einfachste Möglichkeit, Daten während einer Migration von einer Public Cloud in eine andere zu verschieben, führt über eine VPN-Verbindung. Leider wird dabei das öffentliche Internet der Cloud-Anbieter genutzt, was die Datenübertragungsleistung einschränkt. Außerdem kann das im Fall von großen Datenmengen wesentlich teurer ausfallen als eine dedizierte Verbindung. Sollen bei einer Cloud-zu-Cloud-Migration also viele Terabyte an Daten übertragen werden, kann das erhebliche logistische und finanzielle Hürden aufwerfen. 5 Best Practices, um zwischen Public Clouds zu migrieren Eine Zauberformel – oder zumindest eine spezielle Migrationssoftware – für Cloud-zu-Cloud-Migrationen wäre toll, ist aber nicht existent. Unabhängig davon, wie genau Sie vorgehen, ist eines sicher: Von einer Public Cloud in eine andere zu wechseln, ist komplex und erfordert jede Menge Zeit und Aufwand. Allerdings gibt es aus meiner Sicht einige Best Practices, die Sie einsetzen können, um diesen Prozess so reibungslos wie möglich zu gestalten: 1. Besser planen Eine möglichst sorgfältige Planung ist in Zusammenhang mit Cloud-zu-Cloud-Migrationen das A und O. Entwickeln Sie belastbare Strategien, testen Sie diese mit Dummy-Workloads und finden Sie heraus, was funktioniert und was nicht. Je mehr Zeit Sie für den Planungsprozess aufwenden, desto geringer ist das Risiko, während der Migration auf unerwartete Hindernisse zu stoßen. 2. Realistische Zeitpläne definieren Zeitpläne, die auf realistischen Erwartungen beruhen, sind von Seiten des Managements des Öfteren nicht zu erwarten, weil die Führungskräfte in der Regel die Feinheiten solcher Migrationsprojekte nicht auf dem Schirm haben. Deshalb empfiehlt es sich, von vorneherein transparent zu kommunizieren, wenn es um die Dauer eines Migrationsvorhabens geht. Die schlechte Alternative wäre, dem Management Dinge zu versprechen, die nicht gehalten werden können – und den Zeitplan während der Migration immer wieder anzupassen. 3. Unkritische Workloads zuerst Starten Sie eine Cloud-zu-Cloud-Migration nicht mit Business-kritischen Workloads. Fokussieren Sie sich lieber auf solche, die sich in der Entwicklungs- oder Testphase befinden. Wenn aufgrund einer Planungslücke etwas schiefgeht, machen sich Probleme bei unkritischen Workloads „besser“. Geschäftskritische Applikationen und Daten sollten sie für eine spätere Migrationsphase „reservieren“. 4. Neue Deployments pausieren Ein wichtiger, aber regelmäßig übersehener Aspekt bei der Cloud-zu-Cloud-Migration: Neue Deployments für Anwendungen sowie Änderungen an Plattformen oder Konfigurationen sollten während des Migrationsprozesses auf Eis gelegt werden. Angenommen die Entwickler stellen die neue Version einer Anwendung in einer Cloud bereit, während das IT-Team gerade dabei ist, die ältere Version in eine andere Cloud zu verschieben: In diesem Fall müssten Sie die Migration komplett wiederholen und sämtliche Änderungen, die während der Migration an einer Cloud-Plattform vorgenommen werden, in der neuen Plattform reproduzieren. 5. Interconnection-Services nutzen Die Internetverbindungen zwischen Public Clouds sind relativ langsam. Eine Möglichkeit, die Bandbreite zu erhöhen – und damit die Migration von Cloud zu Cloud zu beschleunigen – führt über Cloud-Interconnections. Diese Lösungen (wie sie beispielsweise Megaport, NuSummit oder Equinix anbieten) bieten dedizierte Verbindungen zwischen Clouds mit hoher Bandbreite. Das ermöglicht, Daten wesentlich schneller zu migrieren. Der Nachteil: Interconnection-Services sind nicht billig. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!
Zwischen Public Clouds migrieren – so geht‘s Keine (Public) Cloud ist für die Ewigkeit. Mit diesen Best Practices gelingt die Cloud-zu-Cloud-Migration.Sinesp | shutterstock.com In der Vergangenheit war Cloud-Migration vor allem ein Synonym dafür, lokale Workloads in Public-Cloud-Infrastrukturen zu verlagern. Zu diesem Zweck gibt es auch jede Menge unterstützende Leitfäden und Tools. Mittlerweile ist rund die Hälfte aller Unternehmen in der Public Cloud angekommen – nur um mit einer neuen Migrationsherausforderung konfrontiert zu werden: Wie lassen sich Workloads optimal von einer Public Cloud in eine andere verschieben? Cloud-zu-Cloud-Migrationen sind für die meisten Anwender absolutes Neuland. Leider stehen hilfreiche, unterstützende Ressourcen zu diesem Thema ebenfalls nur in überschaubarem Umfang zur Verfügung. Zwar bieten einige Cloud-Anbieter dedizierte Tools (etwa Azure Migrate oder AWS Server Migration Service), mit denen bestimmte Objekttypen zwischen Clouds migriert werden können. Diese lassen jedoch komplexe Probleme außen vor, die beispielsweise entstehen, wenn Netzwerke neu konfiguriert oder Hunderte von Terabyte an Daten mit begrenzter Bandbreite übertragen werden müssen. Mit diesem Artikel möchte ich Business-Anwendern auf Grundlage meiner Cloud-Expertise eine Hilfestellung an die Hand geben, um möglichst reibungslos von einer Public Cloud in eine andere zu migrieren. Dazu blicken wir zunächst auf die Gründe für solche Migrationsvorhaben sowie die Problemstellungen, die dabei entstehen können. Abschließend geben wir Ihnen einige Best Practices für Cloud-zu-Cloud-Migrationen an die Hand. Warum Unternehmen die Public Cloud wechseln Es gibt verschiedene Gründe, warum Unternehmen von einer Public Cloud in eine andere wechseln wollen – oder müssen. Zum Beispiel, weil: nach einer Übernahme oder Fusion mehrere Cloud-Instanzen genutzt werden, die im Rahmen einer IT-Umstrukturierung in einer Plattform konsolidiert werden sollen. eine spezifische Public Cloud aufgrund ihres Preisgefüges, ihrer Performance oder den verfügbaren Standorten nicht mehr optimal geeignet ist, sodass ein Wechsel zu einer alternativen Public-Cloud-Plattform nötig wird. Auch wenn ein Multicloud-Ansatz an dieser Stelle einige Flexibilitäts- und Kostenvorteile erschließen könnte, er bringt auch Nachteile mit sich. Ein ganz wesentlicher ist die zusätzliche Komplexität: Mehrere Clouds zu nutzen, bedeutet auch zusätzliche Ressourcen überwachen und managen zu müssen – und erfordert außerdem zusätzliche Tools, um sämtliche potenziellen Performance- und Security-Probleme identifizieren zu können. Und dann haben wir noch nicht über die dafür nötigen IT-Experten gesprochen. Deshalb ist es für diverse Anwenderunternehmen attraktiver, sich auf eine Public Cloud zu fokussieren – statt zu versuchen, mehrere verschiedene zu nutzen. Scott Wheeler ist Cloud Practice Lead bei Asperitas Consulting.Scott Wheeler 5 Cloud-zu-Cloud-Migrationshürden Auf den ersten Blick scheint es nicht besonders diffizil, von einer Public Cloud in eine andere zu wechseln. Schließlich bieten sämtliche Public Clouds in etwa dieselben Kern-Services und basieren auf denselben Konzepten. Auf den zweiten Blick erkennt man jedoch schnell, dass Public-Cloud-Plattformen weit weniger einheitlich sind, als sie zunächst scheinen. Die folgenden Hürden können eine Cloud-zu-Cloud-Migration erschweren – oder zumindest verlangsamen: 1. Service-Differenzen Obwohl die grundlegenden Arten von Services, die Public Clouds bieten, weitgehend identisch sind, gibt es mit Blick auf die Implementierung Unterschiede. Einen Workload von einer Cloud in die andere zu verschieben und einfach davon auszugehen, dass alles einwandfrei funktioniert, kann deshalb zu bösen Überraschungen führen. Sie sollten davon ausgehen, Ihre Konfigurationen anpassen zu müssen. Nehmen wir als Beispiel CosmosDB und DynamoDB: Es handelt sich um verwaltete NoSQL-Datenbanken, die auf Azure, beziehungsweise AWS bereitgestellt werden. Auf hoher Ebene erfüllen sie denselben Zweck. Im Hintergrund werden Prozesse wie Datenreplikation oder -indizierung jedoch unterschiedlich gehandhabt. Auch preislich unterscheiden sich die Angebote. Und es gibt keine Garantie dafür, dass eine Konfiguration, die die Performance für CosmosDB optimiert, das auch im Fall von DynamoDB (in gleichem Maße) tut. Aus diesem (und weiteren) Gründen ist es nicht ratsam, Daten aus Cosmos zu extrahieren und einfach in DynamoDB zu übertragen. Stattdessen steht ein komplexer Migrationsprozess an, bei dem die Daten offline genommen, transformiert und anschließend übertragen werden müssen. Das erfordert möglicherweise auch umfassende Änderungen an Konfigurationen und Datenstrukturen. 2. Latenz-Challenges Wie schnell Daten innerhalb einer Public-Cloud-Instanz verschoben werden können, hängt in hohem Maße davon ab, wo sich der spezifische Workload oder Service befindet. Daten zwischen Cloud-Regionen auf demselben Kontinent zu verschieben, ist in der Regel mit geringeren Latenzen verbunden als bei einer interkontinentalen Datenübertragung. Weil sich die Regionen der einzelnen Cloud-Anbieter jedoch mit Blick auf die jeweilige Verortung der Rechenzentren unterscheiden, kann die Latenz nach einer Cloud-Migration zu einem Problem werden, wenn die Regionen in der neuen Cloud nicht sorgfältig ausgewählt und konfiguriert werden. Latenzprobleme können auch auftreten, wenn ein Unternehmen SaaS-Dienste oder lokale Anwendungen nutzt, die nicht in der Cloud gehostet werden – dabei aber Daten über Public-Cloud-Ressourcen gesendet oder empfangen werden müssen. In diesem Fall kann die Entfernung des Rechenzentrums zum Standort, an dem SaaS- und lokale Ressourcen gehostet sind, die Übertragungsgeschwindigkeit beeinträchtigen und damit Netzwerkverzögerungen begünstigen. Es ist deshalb essenziell, die Cloud-Abhängigkeiten und -Wechselwirkungen mit Blick auf die gesamte IT-Umgebung des Unternehmens zu verstehen. 3. Automatisierungs-Umschwung Um ihre Kunden dabei zu unterstützen, Workloads zu integrieren und Daten zu migrieren, bieten die Cloud-Provider Automatisierungs-Tools an. Diese sind im Regelfall mit weiteren Tools verbunden, die ausschließlich in der jeweiligen Cloud-Umgebung funktionieren – und von deren jeweiligen Konfigurationseinstellungen und Sprachen abhängig sind. Auch in diesem Bereich ist es nicht möglich, die Tools einfach von einer Public Cloud in die andere zu schieben. Vielmehr müssen diese übersetzt oder neu erstellt werden – es sei denn, es handelt sich um Cloud-unabhängige Lösungen von Drittanbietern. Selbst in diesem Fall ist die Wahrscheinlichkeit jedoch hoch, dass zumindest die entsprechenden Konfigurationen aktualisiert werden müssen. 4. Kosten-Explosionen Selbst bei vergleichbaren Service-Typen kann deren Preisgestaltung erheblich von Anbieter zu Anbieter variieren. Eine Workload-Konfiguration, die in einer Cloud aus Preis-Leistungs-Perspektive optimal ist, kann deshalb in einer anderen suboptimal sein. Das kann potenziell zu massiver Geldverschwendung führen, wenn die Konfiguration im Rahmen des Migrationsprozesses nicht an die neue Preisstruktur angepasst wird. 5. Bandbreiten-Einschränkungen Die einfachste Möglichkeit, Daten während einer Migration von einer Public Cloud in eine andere zu verschieben, führt über eine VPN-Verbindung. Leider wird dabei das öffentliche Internet der Cloud-Anbieter genutzt, was die Datenübertragungsleistung einschränkt. Außerdem kann das im Fall von großen Datenmengen wesentlich teurer ausfallen als eine dedizierte Verbindung. Sollen bei einer Cloud-zu-Cloud-Migration also viele Terabyte an Daten übertragen werden, kann das erhebliche logistische und finanzielle Hürden aufwerfen. 5 Best Practices, um zwischen Public Clouds zu migrieren Eine Zauberformel – oder zumindest eine spezielle Migrationssoftware – für Cloud-zu-Cloud-Migrationen wäre toll, ist aber nicht existent. Unabhängig davon, wie genau Sie vorgehen, ist eines sicher: Von einer Public Cloud in eine andere zu wechseln, ist komplex und erfordert jede Menge Zeit und Aufwand. Allerdings gibt es aus meiner Sicht einige Best Practices, die Sie einsetzen können, um diesen Prozess so reibungslos wie möglich zu gestalten: 1. Besser planen Eine möglichst sorgfältige Planung ist in Zusammenhang mit Cloud-zu-Cloud-Migrationen das A und O. Entwickeln Sie belastbare Strategien, testen Sie diese mit Dummy-Workloads und finden Sie heraus, was funktioniert und was nicht. Je mehr Zeit Sie für den Planungsprozess aufwenden, desto geringer ist das Risiko, während der Migration auf unerwartete Hindernisse zu stoßen. 2. Realistische Zeitpläne definieren Zeitpläne, die auf realistischen Erwartungen beruhen, sind von Seiten des Managements des Öfteren nicht zu erwarten, weil die Führungskräfte in der Regel die Feinheiten solcher Migrationsprojekte nicht auf dem Schirm haben. Deshalb empfiehlt es sich, von vorneherein transparent zu kommunizieren, wenn es um die Dauer eines Migrationsvorhabens geht. Die schlechte Alternative wäre, dem Management Dinge zu versprechen, die nicht gehalten werden können – und den Zeitplan während der Migration immer wieder anzupassen. 3. Unkritische Workloads zuerst Starten Sie eine Cloud-zu-Cloud-Migration nicht mit Business-kritischen Workloads. Fokussieren Sie sich lieber auf solche, die sich in der Entwicklungs- oder Testphase befinden. Wenn aufgrund einer Planungslücke etwas schiefgeht, machen sich Probleme bei unkritischen Workloads „besser“. Geschäftskritische Applikationen und Daten sollten sie für eine spätere Migrationsphase „reservieren“. 4. Neue Deployments pausieren Ein wichtiger, aber regelmäßig übersehener Aspekt bei der Cloud-zu-Cloud-Migration: Neue Deployments für Anwendungen sowie Änderungen an Plattformen oder Konfigurationen sollten während des Migrationsprozesses auf Eis gelegt werden. Angenommen die Entwickler stellen die neue Version einer Anwendung in einer Cloud bereit, während das IT-Team gerade dabei ist, die ältere Version in eine andere Cloud zu verschieben: In diesem Fall müssten Sie die Migration komplett wiederholen und sämtliche Änderungen, die während der Migration an einer Cloud-Plattform vorgenommen werden, in der neuen Plattform reproduzieren. 5. Interconnection-Services nutzen Die Internetverbindungen zwischen Public Clouds sind relativ langsam. Eine Möglichkeit, die Bandbreite zu erhöhen – und damit die Migration von Cloud zu Cloud zu beschleunigen – führt über Cloud-Interconnections. Diese Lösungen (wie sie beispielsweise Megaport, NuSummit oder Equinix anbieten) bieten dedizierte Verbindungen zwischen Clouds mit hoher Bandbreite. Das ermöglicht, Daten wesentlich schneller zu migrieren. Der Nachteil: Interconnection-Services sind nicht billig. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!