Für eine erfolgreiche Lift-and-Shift-Migration in die Cloud ist die Architektur entscheidend

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Es haben sich zwei unterschiedliche Modelle für den „Gang in die Cloud“ herausgebildet. Das erste und naheliegendste ist der Cloud-native-Ansatz. „Native“ bedeutet dabei neu – entweder von Grund auf neu entwickelt oder neu geschrieben. Der Cloud-native-Ansatz fördert eine enge Fokussierung auf die Anwendung. Dabei wird davon ausgegangen, dass Leistung und Sicherheit bei einer auf die Cloud zugeschnittenen Anwendung lediglich davon abhängen, die richtigen Cloud-Dienste bereitzustellen. Das stimmt zwar nicht ganz, kommt der Wahrheit aber nahe genug, sodass wir es vorerst dabei belassen.

Der zweite Ansatz ist „Lift and Shift“ und konzentriert sich genau auf das, wonach es klingt: Eine bestehende Anwendung wird aus ihrer Rechenzentrumsumgebung herausgelöst und in die Cloud verlagert, wo sie auf einer Cloud-Infrastruktur aufsetzt. Bei diesem Modell darf der Fokus jedoch nicht allein auf der Anwendung liegen, da auch deren Abhängigkeiten berücksichtigt werden müssen. Dazu gehören weitere Architekturkomponenten, die sich über Anwendungs- und Infrastrukturdienste erstrecken.

Dies wurde kürzlich in einem Bericht von Cloud Velox hervorgehoben, der sich auf die Nutzung der Cloud als sekundäres Rechenzentrum konzentriert. Interessanterweise kam er zu folgendem Ergebnis:

Cloud Velox konzentrierte sich zwar auf die Notfallwiederherstellung, doch das grundsätzliche Problem scheint auch in anderen Bereichen relevant zu sein. Die Verlagerung von Anwendungen in die Cloud ist deutlich attraktiver, wenn sich zugleich auch Netzwerk- und Sicherheitskontrollen beziehungsweise entsprechende Dienste dorthin verlagern lassen.

Wenn Sie eine Anwendung, die im Laufe der Jahre mithilfe von im Netzwerk gehosteten Anwendungsdiensten optimiert wurde, ohne diese Dienste verlagern, gehen diese Optimierungen im Grunde verloren. Es gibt die irrige Annahme, dass allein die Verlagerung in die Cloud die Leistung steigert, weil sich die Anwendung dadurch physisch näher am Internet-Backbone und an den Nutzern befindet, die mit ihr interagieren. Das stimmt zwar teilweise, aber nicht uneingeschränkt. Denn die Leistung einer Anwendung wird zu einem großen Teil nicht von der Netzwerklatenz bestimmt. Tatsächlich hängen viele Ineffizienzen einer Anwendung, die zu einer schlechten Leistung führen, mit der Größe und Zusammensetzung der Inhalte, einem unzureichenden Verbindungsmanagement und der fehlenden Möglichkeit zusammen, den Netzwerk-Stack optimal auf die spezifischen Anforderungen der Anwendung abzustimmen.

Auch Sicherheitsbedenken verschwinden nicht plötzlich, wenn eine Anwendung per Lift-and-Shift in die Cloud verlagert wird. War die Anwendung im Rechenzentrum anfällig für XSS oder SQLi, ist sie mit Sicherheit auch nach der Verlagerung in die Cloud* noch anfällig. Wurden diese Risiken im Rechenzentrum durch eine Web Application Firewall oder auf einem programmierbaren Proxy bereitgestellte Sicherheitskomponenten behoben, sollten die Web Application Firewall und der Proxy zusammen mit der Anwendung per Lift-and-Shift verlagert werden.

Die Möglichkeit, eine Architektur – und nicht nur die Anwendung – per „Lift and Shift“ zu verlagern, ist einer der Gründe für die wachsende Beliebtheit von Colocation-Cloud-Angeboten. Weitere Argumente sind Kosteneinsparungen gegenüber einer lokalen Infrastruktur und eine bessere Kontrolle als in der Cloud. Eine der attraktivsten Eigenschaften eines Colocation-Cloud-Angebots ist jedoch zweifellos die Möglichkeit, eine gesamte Architektur per Lift and Shift zu verlagern und die Vorteile der „Cloud nebenan“ zu nutzen. Manchmal möchten Unternehmen die Datenquelle näher an die in der Cloud bereitgestellten Anwendungen verlagern, um leistungsmindernde Latenzen zu vermeiden, die durch den langen Weg zurück zum unternehmenseigenen Rechenzentrum entstehen. Manchmal möchte das Unternehmen das Frontend skalieren können, ohne das Backend zu beeinträchtigen (und auch hier Latenzen vermeiden). Der Wechsel zu einem Colocation-Cloud-Anbieter macht dies möglich, da sich die Cloud direkt vor Ort befindet und über eine sehr schnelle Verbindung auf Rechenzentrumsniveau erreichbar ist.

Unabhängig vom gewählten Cloud-Ansatz (Colocation oder Public Cloud) liegt der Schlüssel zu einer erfolgreichen Lift-and-Shift-Migration in die Cloud darin, möglichst große Teile der Architektur unverändert zu übernehmen. Ungeachtet der verfügbaren Cloud-Service-Optionen ist es wichtig, kritische Anwendungsdienste während der Migration zusammen mit der zugehörigen Anwendung zu verlagern, damit Leistung und Sicherheit durch den Standortwechsel nicht beeinträchtigt werden.

*Auch bezeichnet als Hoffs Gesetz – zwar kein echtes Gesetz, aber eine Beobachtung, die heute noch genauso zutreffend ist wie bei ihrer ersten Formulierung im Jahr 2009

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie