Sieben Faktoren für eine erfolgreiche Cloud-Migration

Sorgfältige Vorausplanung der Cloud-Migration ist Pflicht

Wenn Sie einen Plan für die Cloud-Migration erstellen, berücksichtigen Sie folgende Punkte:

1. Workflow. Sie müssen den Workflow der Anwendung verstehen. Wenn Ein- oder Ausgaben mit einer anderen Anwendung oder einem Geschäftsprozess in der gleichen Cloud verknüpft sind, ist der Wechsel zu einem anderen Provider problematisch und nicht angeraten.
2. Workload. Optimiert oder gestaltet der Cloud-Provider seine Plattform entsprechend den Anforderungen des Workloads? So kann beispielsweise eine Regierungsanwendung einfacher auf einer Cloud-Basis ausgeführt werden, die speziell auf die Sicherheits- und Zugangsanforderungen der Behörde zugeschnitten ist.
3. Anwendung und Sprache. In einigen Fällen, etwa bei Infrastructure as a Service (IaaS), hat man eventuell die Kontrolle über das Betriebssystem, die Middleware und Laufzeitbibliotheken. Bei Platform as a Service (PaaS) geht diese Kontrolle verloren, und der Cloud-Provider diktiert viele dieser Bereiche. Ein solcher Ansatz kann die Anwendung und die Sprachunterstützung einschränken.
4. Tools. Bei diesem Punkt zeichnen sich die Amazon Web Services (AWS) aus. Deren Tools und APIs übertreffen den Wettbewerb in vielerlei Hinsicht und machen dadurch das Leben eines Entwicklers einfacher. Dieser Vorteil hat allerdings seinen Preis. Ein Plan für die Cloud-Migration, der den Umstieg von AWS zu einem anderen Cloud-Provider vorsieht, bedeutet möglicherweise, dass Sie Ihre Anwendungen neu schreiben müssen oder Third-Party-Funktionen hinzufügen müssen, die in das AWS-Angebot integriert waren. Tools sind der Dreh- und Angelpunkt. Je besser die Werkzeuge sind, die ein Cloud-Provider zur Verfügung stellt, desto unwahrscheinlicher ist es, dass Kunden abwandern.
5. Networking. Oft übersehen, aber Networking ist ein wichtiger Teil einer Cloud-Anwendung, besonders wenn sie mit On-Premises-Anwendungen kommunizieren muss oder einer App, die eines Tages vielleicht wieder zurück ins unternehmenseigene Data Center wandert. Firmen, die Anwendungen in die Cloud verschieben, müssen zwei Networking Stacks pflegen: einen für ihre On-Premises- und einen anderen für ihre Cloud-basierten Bereitstellungen. Ein Anbieter, Big Switch Networks, hat sich dieses Problems mit seiner Big Cloud Fabric angenommen, die Unternehmen eine einzige Basis liefert, die immer gleich aussieht und sich gleich verhält, unabhängig davon, wo sich die Anwendung befindet. Ein Unternehmen kann die Fabric entweder vor Ort oder in der AWS-Cloud bereitstellen und sich auf einen Standardsatz von Regeln und Einstellungen für das Netzwerk-Management verlassen.
6. Datenstruktur. Dies dürfte eine der weniger kontroversen Fragen sein, da die Datenstruktur sehr stark anwendungsgetrieben ist. Die Datenstruktur wird aber dann zum Problem, wenn es um die Komplexität eines tatsächlichen Wechsels geht. An diesem Punkt bemessen sich die Kosten nach den Stunden für das Debuggen von Anwendungen, die sich nicht so verhalten wie sie sollten. Der Fehler kann durch etwas verursacht werden, was in der Datenstruktur selbst fehlt, so dass die Anwendung anders als erwartet funktioniert.
7. Storage. Ein entscheidendes Kriterium in einem Plan für die Cloud-Migration betrifft Storage-Lösungen. Sie müssen die Kosten berücksichtigen und wie die Daten gespeichert werden. Bedenken Sie auch, wie die Daten von der alten Anwendung zur neuen, von einem anderen Provider gehosteten Anwendung migriert werden. Die meisten Cloud-Provider machen es einfach und kostengünstig, Daten in die Cloud zu bekommen. Aber wenn es darum geht, die Daten wieder zurückzuholen – oder auf sie Einfluss zu nehmen –, summieren sich die Kosten.

Portabilität ist der Schlüssel bei der Migration von Anwendungen

Alle angeführten Punkte sind kein Argument gegen das Verschieben einer Anwendung zwischen zwei Cloud-Anbietern. Es handelt sich einfach um primäre Indikatoren, die es beim Entwerfen einer Cloud-Strategie zu berücksichtigen gilt.

Damit der Plan für die Cloud-Migration reibungslos funktioniert, sollten Sie bei Cloud-Breitstellungen immer die Portabilität im Hinterkopf behalten. Das heißt nicht, dass alles vollständig glatt laufen wird. Außerdem müssen Sie geschäftliche und technische Kompromisse einkalkulieren.

Wenn eine Anwendung auf AWS gehostet ist, aber so flexibel sein muss, dass sie sich woanders hin verschieben lässt, bedeutet dies womöglich, auf den Einsatz von einigen AWS-Tools und -Funktionen zu verzichten. Für einige Organisationen mag dieser Kompromiss praktikabel sein. Aber in vielen Fällen kann der langfristige Nutzen der Anwendung erst dann so richtig zur Geltung kommen, wenn man diese Tools verwendet und die Anwendung dort belässt, wo sie ist – ungeachtet der Betriebskosten.

Der Kompromiss zwischen Nutzen und Kosten wird für jede Anwendung unterschiedlich ausfallen, besonders mit Blick auf verschiedene Cloud-Provider. Das sollte jedoch nicht anders sein als bei der alten Build-versus-Buy-Kontroverse, mit der die IT jahrelang konfrontiert gewesen ist.

Heute allerdings ist das nicht mehr der Fall. Stattdessen sieht sich die IT inmitten mehrerer Debatten, die unter Schlagworten wie Build here versus Build there, Stay versus Build there und Move versus Buy geführt werden.

Der entscheidende Punkt ist, die richtige Forderung zu Beginn eines Projekts zu stellen und nicht Monate oder Jahre nach der Bereitstellung.

Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!