So bereiten Sie sich auf die Cloud-to-Cloud-Migration vor
Oh ja. Es passiert. Um den Prozess weniger schmerzhaft zu gestalten, sollten Sie es zu einem Teil Ihrer übergreifenden Cloud-Strategie machen.
Was haben die folgenden Punkte gemeinsam? Lachse, Kanadagänse, Monarchfalter und Anwendungen.
Wenn Sie erraten haben, dass es sich dabei um Dinge handelt, die von einem Ort zum anderen wandern, können Sie sich auf die Schulter klopfen.
Wenn wir über Cloudmigration sprechen, meinen wir normalerweise den Wechsel von lokalen zu externen Standorten. Aus gutem Grund. Zahlreiche Daten ( einschließlich unserer eigenen ) weisen auf eine zunehmende Nutzung der öffentlichen Cloud hin. Worüber wir fast nie sprechen, ist die umgekehrte Migration. Ich kann jetzt schon die Rufe „Ketzerei!“ hören, aber seien wir realistisch – es passiert, und zwar öfter, als Sie vielleicht denken.
Zum Beispiel:
42 % der Befragten, die ein öffentliches IaaS in der Produktion eingeführt haben, gaben an, dass sie „eine Migration von ihrer aktuellen Strategie beabsichtigen, entweder innerhalb der nächsten vier Jahre oder als fortlaufenden Prozess “. 70 % davon „ planten, eher zu einer Hybrid Cloud zu wechseln, als ausschließlich auf eine Private-Cloud-Lösung umzusteigen .“
Der Grund? Der am häufigsten genannte Faktor war die Kostensenkung (67 %), gefolgt von Sicherheit und Stabilität. Dies wird durch Geschichten wie diese über die Migration von Pubmatic von der öffentlichen zur privaten Cloud bestätigt. Ein wesentlicher Treiber waren die Kosten.
Andere migrieren jedoch, wie wir alle gehört haben, in die entgegengesetzte Richtung. Eine Menge. 57 % der Benutzer einer privaten IaaS-Plattform „ beabsichtigen, zu einer öffentlichen oder Hybrid-Cloud zu migrieren, und 77 % dieser Befragten geben an, dass sie einen hybriden Ansatz planen. “
Ihre Begründung? Skalierbarkeit (71 %), dicht gefolgt von Flexibilität. An dritter Stelle standen mit 50 % der Befragten die Kosten.
Die Skalierbarkeit treibt die Leute in die öffentliche Cloud, und die langfristigen Kosten scheinen sie wieder zurück in die private Cloud zu treiben.
Die Realität ist, dass die meisten Organisationen weder „Public Cloud“-Shops noch „Private Cloud Only“-Shops sind. Sie sind Multi-Cloud , auch nachdem sie Apps hin und her verschoben haben. Die Realität lässt sich durch die Untersuchung von Entwicklungstrends beweisen, wie sie beispielsweise Cap Gemini in seinem Bericht „Cloud Native Comes of Age“ aufzeigt. Darin wird festgestellt, dass „ein Sechstel (15 %) der neuen Anwendungen der Unternehmen der Befragten heute in einer Cloud-nativen Umgebung erstellt werden.“
Wenn nun 15 % Cloud-native sind, bedeutet dies, dass die anderen 85 % es nicht sind. Dazu gehören wahrscheinlich auch Großrechner. Und Client-Server. Und dreistufige Web-Apps. Oh, und auch Microservices in Containerumgebungen.
Die moderne Unternehmensorganisation ist nicht nur Multi-Cloud, sie ist hinsichtlich ihrer Anwendungsarchitekturen auch generationenübergreifend.
Das heißt, die Chancen, dass Sie eine App von vor Ort (privat) nach außerhalb (öffentlich) oder umgekehrt migrieren, sind ziemlich hoch – denn es gibt mehr solche Apps als Cloud-native Apps. Wichtig ist daher, diese Prämisse in Ihre Cloud-Strategie zu integrieren. Mit anderen Worten: Sie müssen sich im Vorfeld darüber im Klaren sein, was Sie tun können, um den (möglicherweise unvermeidlichen) Prozess weniger schmerzhaft zu gestalten.
Vorbereitung auf die Cloud-to-Cloud-Migration
Zu den ersten Überlegungen gehört die erwartete Lebensdauer der App, die Sie verschieben. Wenn es langfristig angelegt ist, ist es ein Kandidat für eine zukünftige Cloud-zu-Cloud-Migration. Wenn dies nicht der Fall ist – weil es werbe-, marketing- oder ereignisbezogen ist –, können Sie direkt zum Ende dieser Liste springen und es bereitstellen.
Nachdem Sie nun festgestellt haben, dass die App eine längere Lebensdauer haben wird, sollten Sie darüber nachdenken, wie Sie die App skalieren und sichern.
SICHERHEITS- SOAP-BOX-SEITENLEISTE Auch wenn die App keine Eingabe- oder Touch-Daten akzeptiert, ist dennoch eine gewisse Sicherheit erforderlich. App-Sicherheit ist ein Stapel, und es gibt Plattformen und Protokolle, die Sie anfällig für Kompromisse machen können, wenn Sie nicht beide schützen. Angriffe durch Manipulation von Metadaten (die auf HTTP-Header abzielen) sind genauso gefährlich (vielleicht sogar noch gefährlicher) als durch benutzerdefinierten Code verursachte Schwachstellen. Alle Apps sind kritisch, wenn es um Sicherheit geht. |
Die schnelle (und einfache) Antwort, wenn die App Cloud-nativ ist, lautet: „Wir verwenden Dienste des Cloud-Anbieters.“ Dies ist eine gültige Option, ebenso wie „Wir verwenden, was wir schon immer verwendet haben“ eine gültige Option ist, wenn die App in einer privaten Cloud vor Ort gespeichert werden soll. Beide Optionen bergen jedoch später das potenzielle Risiko, dass die Dienste und/oder Richtlinien nicht reibungslos von einer Cloud in eine andere migriert werden können. Es ist an der Zeit, sich genau anzusehen, was Sie derzeit für Skalierung und Sicherheit verwenden, und festzustellen, ob diese Anwendungsdienste zusammen mit Ihrer App migriert werden können – in beide Richtungen.
Angesichts der Tatsache, dass Unternehmen durchschnittlich 16 Anwendungsdienste nutzen, um ihre Apps bereitzustellen und zu sichern, kann dieser Bereich Ihre Fähigkeit, Apps zu unterstützen, die migriert werden müssen, erheblich beeinträchtigen, ganz zu schweigen von der Unterstützung dieser Apps in einer Multi-Cloud-Welt. Beachten Sie, dass einige dieser 16 Dienste Cloud-native Dienste sein müssen. Wenn Sie Ihren Datenpfad grundsätzlich als aus unternehmensweiten, gemeinsam genutzten Anwendungsdiensten und Pro-App-Diensten bestehend betrachten, können Sie erkennen, dass die architektonische Aufteilung weitgehend der von öffentlichen Cloud-Anbietern auf Infrastrukturebene gezogenen Linie entspricht. Es handelt sich zwar nicht um eine perfekte Aufteilung, doch sie sorgt für eine logische Trennung und bietet Hinweise darauf, welche Dienste „Multi-Cloud“ sein müssen und bei welchen Sie sich auf Cloud-native oder herkömmliche Rechenzentrumsdienste verlassen können.
Je konsistenter die von Ihnen über mehrere Clouds hinweg genutzten Anwendungsservices sind, desto einfacher ist die Migration zwischen den zwei (oder drei oder vier oder mehr) Clouds, da für Sie weniger Bindungen bestehen. Dieser Ansatz hat den zusätzlichen Vorteil, dass die Automatisierungsbemühungen auf die öffentliche Cloud ausgeweitet werden und das Unternehmen zumindest von den Betriebskosten entlastet wird, die mit der Aufrechterhaltung separater Betriebsmitarbeiter und -verfahren verbunden sind.
Cloud war unvermeidlich. Das gilt auch für Multi-Cloud. Das bedeutet letztlich, dass es zu Migration zwischen ihnen kommen wird. Wenn Sie auf Abhängigkeiten achten und anwendungsübergreifende Dienste von Clouds nutzen, bevor Sie die anfängliche Entscheidung darüber treffen, wo die App bereitgestellt werden soll, kann der Prozess weniger mühsam sein.
Machen Sie zumindest die Idee einer Cloud-zu-Cloud-Migration zu einem Teil Ihrer Cloud-Strategie auf oberster Ebene. Eine gute Vorbereitung kann Ihnen später eine schmerzhafte (und kostspielige) Migration ersparen.