Für den Erfolg von Lift and Shift in die Cloud konzentrieren Sie sich auf die Architektur
Für die Umstellung auf die Cloud haben sich zwei unterschiedliche Modelle herausgebildet. Der erste und offensichtlichste ist der native Ansatz. „Native“ bedeutet „neu“, entweder „Greenfield“ oder umgeschrieben. Der native Ansatz fördert eine enge Fokussierung auf die Anwendung und geht davon aus, dass bei einer Anpassung an die Cloud Leistung und Sicherheit davon abhängen, ob die richtigen Dienste in der Cloud bereitgestellt werden. Das ist zwar nicht ganz richtig, kommt der Wahrheit aber nahe genug, sodass wir es vorerst so belassen.
Der zweite Ansatz heißt „Lift and Shift“ und ist genau auf das ausgerichtet, was der Name vermuten lässt: eine vorhandene Anwendung aus ihrem Rechenzentrumsfundament zu heben und in die Cloud zu verschieben, wo sie auf einem Cloud-Grundlage platziert wird. Allerdings kann der Fokus bei diesem Modell nicht allein auf der Anwendung liegen, da die Anwendung Abhängigkeiten aufweist, die ebenfalls berücksichtigt werden müssen. Dazu gehören andere Architekturkomponenten, die Anwendungs- und Infrastrukturdienste umfassen.
Dies wurde kürzlich in einem Bericht von Cloud Velox hervorgehoben, wobei der Schwerpunkt auf der Nutzung der Cloud als sekundäres Rechenzentrum lag. Interessanterweise wurde folgendes Ergebnis festgestellt:
Es besteht weiterhin das Stereotyp, dass die IT aufgrund vermeintlicher Sicherheits- und Netzwerkbedenken überwiegend gegen die Cloud ist. Allerdings gaben 55 Prozent der Befragten an, dass sie Cloud-DR nutzen würden, solange sie ihre lokalen Netzwerk- und Sicherheitskontrollen auf die Cloud ausweiten könnten. Dies lässt darauf schließen, dass IT-Experten nicht gegen die Cloud sind, sondern sich nur gleichwertige Kontrollen in der Cloud wünschen.
Nun hat sich Cloud Velox auf die Notfallwiederherstellung konzentriert, aber es scheint, dass das allgemeine Problem breiter anwendbar ist. Das Verschieben von Apps in die Cloud ist wesentlich angenehmer, wenn Sie gleichzeitig auch die Netzwerk- und Sicherheitskontrollen (Dienste) verschieben können.
Wenn Sie eine App, die im Laufe der Jahre mithilfe von im Netzwerk gehosteten App-Diensten optimiert wurde, ohne diese App-Dienste verschieben, gehen diese Optimierungen grundsätzlich verloren. Es besteht dieser Irrglaube, dass allein die Anwesenheit dort draußen, in der Cloud, eine Leistungssteigerung bringt, weil sie physisch näher am Internet-Backbone und den Benutzern ist, die mit ihm interagieren. Das stimmt zum Teil, aber nicht ganz. Das liegt daran, dass die Leistung einer Anwendung nicht zu einem großen Teil von der Netzwerklatenz abhängt. Tatsächlich hängen viele der Ineffizienzen einer Anwendung, die zu einer schlechten Leistung führen, mit der Größe und Zusammensetzung des Inhalts, einem schlechten Verbindungsmanagement und der Unfähigkeit zusammen, den Netzwerkstapel richtig auf die speziellen Anforderungen der Anwendung abzustimmen.
Auch Sicherheitsbedenken verschwinden nicht plötzlich, wenn Sie eine App in die Cloud verschieben. Wenn die App im Rechenzentrum anfällig für XSS oder SQLi war, können Sie darauf wetten, dass sie auch dann noch anfällig ist, wenn Sie sie in die Cloud verschieben*. Wenn diese Bedenken im Rechenzentrum mit einer Web-App-Firewall oder auf einem programmierbaren Proxy bereitgestellten Sicherheitsartefakten ausgeräumt wurden, sollten die App-Firewall und der Proxy am besten zusammen mit der App verschoben werden.
Die Möglichkeit, eine Architektur (im Gegensatz zur bloßen Anwendung) zu „liften und zu verschieben“, ist einer der Gründe für die wachsende Beliebtheit einer Co-Location-Cloud-Option. Argumente sind auch die Kosteneinsparungen gegenüber der Vor-Ort-Lösung und die bessere Kontrolle als in der Cloud. Zu den attraktiveren Eigenschaften einer Co-Location-Cloud-Option gehört jedoch sicherlich die Möglichkeit, eine gesamte Architektur zu verschieben und die Vorteile der „Cloud von nebenan“ zu nutzen. Manchmal möchten Unternehmen die Datenquelle näher an die in der Cloud bereitgestellten Apps verschieben, um die leistungsmindernde Latenz zu vermeiden, die für den gesamten Weg zurück zum Rechenzentrum des Unternehmens erforderlich ist. Manchmal möchte das Unternehmen das Front-End skalieren können, ohne das Back-End zu stören (und auch hier gilt es, Latenzen zu vermeiden). Der Wechsel zu einem Co-Location-Cloud-Anbieter macht dies möglich, da die Cloud über eine sehr schnelle Verbindung auf Rechenzentrumsniveau direkt vor Ort ist.
Unabhängig vom Cloud-Ansatz (Co-Lo oder öffentlich) liegt der Schlüssel zu einem erfolgreichen Lift and Shift in die Cloud darin, möglichst viel von der Architektur zu übernehmen und zu verschieben. Ungeachtet der Optionen für Clouddienste ist es wichtig, kritische App-Dienste während der Umstellung bei der Anwendung zu belassen, um sicherzustellen, dass Leistung und Sicherheit durch die Verlagerung nicht beeinträchtigt werden.
*Auch als Hoffsches Gesetz bezeichnet, das zwar kein wirkliches Gesetz ist, aber heute noch genauso genau ist wie bei seiner ersten Beobachtung im Jahr 2009.