Cloud-Computing

Zwischen „Lift and Shift“ und Cloud-native

26. April 2022, 16:00 Uhr | Autor: Björn Pritzel / Redaktion: Sabine Narloch | Kommentar(e)
Mann, Vorschlaghammer, Loch in der Wand, Sergey Nivens
© Sergey Nivens / Fotolia

Bei der Cloud existieren nicht nur Schwarz und Weiß, sondern auch Grautöne. Daher muss ein System oder eine Applikation nicht zu 100 Prozent an alle Möglichkeiten einer Cloud-Lösung angepasst werden, um dort lauffähig zu sein. Über die verschiedenen Ansätze einer Migration in die Cloud.

In zahlreichen Einsatzszenarios lassen sich mit einer 1-zu-1-Migration im so genannten „Lift-and-Shift“-Ansatz bestehende Umgebungen in die Cloud migrieren, um beispielsweise Compliance-Anforderungen zu erfüllen. Lift-and-Shift ist die einfachste Art einer Cloud-Transition, nutzt jedoch die Vorteile der Cloud nicht in vollem Umfang. Davon ausgehend können jedoch schrittweise Optimierungen vorgenommen werden, um das Kosten-Nutzen-Verhältnis zu verbessern: die Verschiebung lokal gespeicherter Daten zu einem flexibel skalierbaren Shared- oder Object Storage mit besserer Performance und höherer Verfügbarkeit.

Für eine optimale Nutzung des Cloud-Potentials müssen über die Verlagerung der Systeme und Applikationen hinaus neue Technologien und Prozesse eingeführt werden. Die Hürden auf diesem Weg sind für jedes Unternehmen unterschiedlich. Während es bei langjährig betriebenen Legacy-Applikationen vor allem darum geht, sie durch möglichst geringe Modifikationen „Cloud ready“ zu machen, können neue Applikationen von Grund auf für den Betrieb auf Cloud-Plattformen konzeptioniert und entwickelt werden und sind dann „Cloud born“ beziehungsweise „Cloud native“.

Der Cloud-Native-Ansatz

Beim Cloud-Native-Ansatz geht es darum, Applikationen primär für den Einsatz in einer Cloud zu entwickeln. Technologie ist dabei nur eine Facette, mindestens ebenso wichtig ist der Wechsel zu agilen Denkweisen und Methoden innerhalb des Unternehmens. Basis dafür ist eine flexible und modulare Anwendungsarchitektur mit Microservices, von denen jeder für sich einen Prozess oder eine Funktion der Applikation implementiert und selbst lauffähig ist. Damit die Microservices in unterschiedlichen Umgebungen und Cloud-Plattformen lauffähig sind, werden sie in der Regel als Container ausgeliefert, die alle für die Ausführung des Microservices notwendigen Komponenten beinhalten, darunter auch eine Runtime-Umgebung. Für die Orchestrierung containerisierter Applikationen wird auf entsprechende Systeme zurückgegriffen, darüber hinaus finden sich weitere für die Gesamtarchitektur notwendige Services (Datenbanken, Loadbalancer, Monitoring usw.) im Servicekatalog von Cloud- oder Hosting-Anbietern.

Vendor-Lock-in vermeiden

Mit der intensiven Nutzung von Cloud-Services kann mitunter eine Abhängigkeit zum gewählten Cloud-Anbieter einhergehen (Vendor-Lock-in-Effekt). Auch wenn die Services unterschiedlicher Anbieter auf denselben Technologien beruhen, unterscheiden sich die technischen Implementierungen oft in Details voneinander, etwa in der API oder beispielsweise bei unterschiedlichen Feature-Sets bei Datenbanken. Ein potenzieller Anbieterwechsel zieht in dieser Konstellation Anpassungen des Applikationscodes oder der Gesamtarchitektur nach sich.

Wenn ein möglicher Vendor-Lock-In vermieden werden soll, sollte dies bereits in der Konzeption berücksichtigt werden, man spricht dann von einem „Cloud-Agnostic-Ansatz“, bei dem die Gesamtarchitektur auf Basis von Cloud-Services designt wird. Wie so oft gibt es auch bei dieser Medaille eine Kehrseite: Das kann beispielsweise der Verzicht auf spezifische Features und Vorzüge bestimmter Implementierungen sein. Alternativ dazu lassen sich Cloud-Services selbst als Container bereitstellen. Dies erhöht durch die Abstraktion mittels eines Orchestrierungstools zwar die Portabilität, allerdings ist es dann wieder Sache des Kunden, sich um die Implementierung und den Betrieb innerhalb des Orchestrierungstools zu kümmern. Es gilt also abzuwägen, welche Vor- und Nachteile in Bezug auf die künftige IT-Strategie überwiegen.

Anbieterkompass Anbieter zum Thema

zum Anbieterkompass

  1. Zwischen „Lift and Shift“ und Cloud-native
  2. Cloud-Native-Maturity-Modell

Verwandte Artikel

ADACOR Hosting GmbH

Cloud

Anbieterkompass