Cloud Migration – Was man vorher bedenken sollte!

Die Cloud ist hip und angesagt. Egal ob Private, Public oder Hybrid-Cloud, jeder wird geradezu aufgefordert seine Systeme in die Cloud zu heben oder Cloud-Services zu nutzen, egal ob Business- oder Privatkunden. Aber lohnt sich die Cloud Migration oder kann diese unter Umständen eine Kostenfalle werden?

In diesem Artikel klären wir, welche Gedanken man sich vor einer Cloud Migration machen sollte und warum alle Beteiligten bei einer Cloud Migration das gleiche Grundverständnis haben sollten.

Was ist die Cloud?

Den Begriff Cloud hat man im IT Umfeld und auch in der TV-Werbung immer wieder gehört. Aber was steckt eigentlich hinter diesem Begriff? Ist die Cloud einfach eine erweiterte Dropbox oder verbirgt sich doch mehr dahinter?

Die Cloud bezieht sich auf Software und Dienste, die nicht lokal auf Ihrem Computer, sondern im Internet laufen. Auf die meisten Cloud-Dienste kann über einen Webbrowser wie Firefox oder Google Chrome zugegriffen werden, und einige Unternehmen bieten spezielle mobile Apps an.

Für Privatanwender verbergen sich hier komplette Office Suiten mit Speicherplatz für die Daten, welche komplett im Internet laufen und von jedem Endgerät erreichbar sind. Der Vorteil ist hier ganz klar die Flexibilität und Ausfallsicherheit. Selbst Gaming findet heute schon in der Cloud statt. Nvidia und Google bieten eigene Cloud-Gaming Plattformen an, bei denen die komplette Rechenleistung für die Spiele beim Cloudanbieter liegt und nur Eingabe- und Ausgabedaten übertragen werden.

Wenn es um Unternehmensanforderungen geht, spricht man aber von ganz anderen Cloud-Diensten. Einige Unternehmen entscheiden sich für die Implementierung von Software-as-a-Service (SaaS), bei der das Unternehmen eine Anwendung abonniert, auf die es über das Internet zugreift. Es handelt sich im Wesentlichen um eine Miete. Salesforce oder Microsoft 356 sind typische SaaS Dienste.

Es gibt auch Platform-as-a-Service (PaaS), bei dem ein Unternehmen seine eigenen benutzerdefinierten Anwendungen beim Cloudanbieter betreibt. Der Vorteil hierbei ist, dass alles unterhalb der Applikation, also Infrastruktur, Storage, Serversysteme, Betriebssysteme etc. vom Cloudanbieter verwaltet und aktualisiert wird.

Und nicht zu vergessen, Infrastructure-as-a-Service (IaaS).
Bei einem IaaS-Servicemodell hostet ein Cloud-Anbieter die Infrastrukturkomponenten, die traditionell in einem Rechenzentrum vor Ort vorhanden sind. Dazu gehören Server, Speicher- und Netzwerkhardware sowie die Virtualisierungs- oder Hypervisor-Schicht. Die Installation und Wartung des Betriebssystems, so wie der installierten Tools obliegt hier ihnen.

Als bestes Beispiel kann man hier eine virtuelle Maschine sehen, die VM wird von Ihnen erstellt und auch befüllt, aber der darunterliegende Hypervisor sowie dessen Hardware usw. wird vom Cloud-Anbieter verwaltet.

Warum Lift and Shift der falsche Ansatz ist!

Geschäftsführung, Management oder Leitungspersonen, die keine aktive Erfahrung mit Cloud-Systemen haben, wollen meist die bestehenden Systeme aus den Rechenzentren direkt in die Cloud heben. VMs (Virtuelle Maschinen) sollen direkt von A nach B migriert werden und im besten Fall ohne Unterbrechung weiterlaufen.

Direkt nach der Migration werden die Systeme in den eigenen Rechenzentren am besten noch von heute auf morgen abgeschaltet, um laufende Kosten zu sparen.

Dies hat aber mit Cloud nicht wirklich etwas zu tun. Vor allem treibt es im schlimmsten Fall die Kosten unnötig in die Höhe, wenn man weiter auf überdimensionierte Systeme setzt, die unter Umständen durch smarte Cloud-Services oder Containisierungsysteme abgelöst werden können.

Im ersten Step empfiehlt sich immer eine Einzelanalyse der Services und Server, die im Rechenzentrum betrieben werden. Nicht jedes System muss zwangsläufig in die Cloud migriert werden. Active Directory Controller (oder RODC’s), Printserver und Filesync Server haben weiterhin eine lokale Daseinsberechtigung.

Es mag Standorte im Unternehmen geben, die nicht über eine duale Internetanbindung verfügen. Solche Standorte wären bei einem Ausfall des Internetproviders nicht mehr arbeitsfähig.

Bei noch vorhandenen lokalen Systemen wäre der Ausfall zwar spürbar, würde aber nicht zum kompletten Stillstand des Standortes führen.

HUAWEI MateBook D 16 2024, 12th Gen Intel Core i5, 16GB RAM, 512GB SSD, 16 Zoll FullView Display, 1,68 kg leichten Gehäuse, Windows 11 Home, Space Gray, Deutsche Version

(45)

599,00 € (von 21. November 2024 06:39 GMT +01:00 - Mehr InformationenProduct prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on [relevant Amazon Site(s), as applicable] at the time of purchase will apply to the purchase of this product.)

Ein weiterer Nachteil bei einfachen Lift and Shift Migrationen in die Cloud sind die ganzen Altlasten, die man übernimmt. Systeme sind teils über Jahre zugemüllt oder die Services auf den Systemen werden im Alltag überhaupt nicht mehr benötigt und wurden einfach nie zurückgebaut. Solche Dienste verursachen in der Cloud unnötige Kosten durch zu groß skalierte Systeme.

Es gilt also, jedes einzelne System zu kontrollieren und abzuwägen. Stellen Sie sich die Frage, ob der Dienst noch benötigt wird und ob er wirklich auf einem vollwertigen Betriebssystem in einer VM laufen muss oder ob dieser nicht auf ein PaaS Cloud-Service ausgelagert werden kann. Auch sollte überprüft werden, ob der Service 24×7 erreichbar sein muss oder nur während den Kernarbeitszeiten. Im Cloudumfeld lassen sich durch zeitlich getriggerte Start und Stops der Cloudservices wiederum Kosten einsparen.

Single- oder Multicloud?

Azure, GCP oder AWS? Oder vielleicht doch was ganz anderes?

Die Wahl des Cloudanbieters fällt für Einsteiger nicht immer leicht. Bei den Basisdiensten wie Storage oder Virtualisierungsumgebungen unterscheiden sich die Anbieter nur marginal, jedoch kann das Preismodell sehr unterschiedlich ausfallen.

Komplizierter kann es in Spezialthemen wie z.b. Internet of Things (IoT) sein. Hier bieten die Cloudanbieter unterschiedliche Services an, die intern auch andere Technologien verwenden. Und genau hier kommt der große Knackpunkt, wenn es um das Thema Multicloud geht.

Dies ist aber nicht nur bei spezialisierten Themen so, sondern kann auch bei Standarddiensten wie Datenbanksystemen oder Kubernetes Clustern vorkommen.

Bei den Kubernetes Clustern nutzen Cloudanbieter meist eigene Node Images und unterschiedliche Default Pods. Ein besseres Vorgehen wäre hier die Wahl eines Vanilla Images bei allen Cloudanbietern, aktuell ist dies aber nicht der Fall.

Nutzt ihr Pod z.b. das Logging des Cloudanbieters, so ist ein einfacher Umzug zu einem Kubernetes Cluster eines anderen Anbieters nicht ohne Anpassungen möglich.

Überprüfen Sie also vorher, welcher Cloudanbieter für ihren Zweck der richtige ist. Sollten es doch mehrere Cloudanbieter werden, müssen Sie sich Gedanken über Multicloud-Tools in den Bereichen Monitoring, Security und Deployment machen. Ebenso müssen Sie ihr Netzwerkkonstrukt anders aufbauen.

Aktuell läuft vielleicht eine Anwendung und die dazugehörige Datenbank zusammen in der Azure Cloud, aber was ist, wenn ihr SAP System aus der SAP-Cloud nun Zugriff auf diese Datenbank benötigt? Müssen weitere VPN-Tunnel erstellt werden oder multiple Firewalls zentral gemanagt werden? Wie konzipieren Sie die Authentifizierung und Autorisierung?

Diese und viele weitere Fragen müssen Sie sich vor der Cloud Migration stellen, unabhängig vom Cloudanbieter und den Folgekosten. Ein einfacher Schwenk vom Cloudanbieter A nach B mittels eines Klicks wird nicht einfach realisierbar sein.

Webportal, CLI oder Terraform?

Egal ob Single- oder Multicloud, es gibt unterschiedliche Wege, die Ressourcen in der Cloud zu steuern. Am einfachsten lassen sich Ressourcen natürlich über das Webinterface des Cloudanbieters erstellten und verwalten, aber ist dies auch für größere Umgebung geeignet oder gibt es hier vielleicht alternativen, die ihnen helfen ihr Konstrukt Agiler und Automatisierbar machen?

Natürlich kann man seine Ressourcen manuell über das Portal zusammenstellen, aber wie sieht es da mit der Nachvollziehbarkeit und Revision aus? Die manuellen Ressourcen werden einwandfrei funktionierten und auch schnell verfügbar sein, aber wenn man diese vervielfältigen muss, weil unterschiedliche Projektteams in der Cloud eine Umgebung benötigen, kommt man hier schnell an seine Grenzen.

Die meisten Cloudanbieter bieten neben dem Webportal auch eigene CLI Tools an. Über diese Commandline-Tools lassen sich über API Calls alle Ressourcen des Cloudanbieters skripten und deployen. Solche CLI Scripts lassen sich auch in CI/CD Pipelines für automatisierte Tasks einbauen und vervielfältigen. Über ein GIT Repository hat man hier auch die komplette Änderungshistorie eines solchen Scripts verfügbar, allerdings erkennt das Script nicht, ob die Ressourcen in der Cloud bereits bestehen und nur eine Änderung notwendig wäre.

Bei den CLI Tools ist auch immer die herstellerspezifische Syntax zu beachten. Möchte man hier also Multicloud Scripte erstellen, muss man sich mit unterschiedlichen CLI Befehlszeilen auseinandersetzen.

Ein weitaus besserer Ansatz fährt hier HashiCorp mit ihrem Tool Terraform. Terraform ist ein beliebtes Tool bei DevOps-Admins, da es Konfigurationen auf verschiedenen Cloud-Plattformen wie Azure, AWS und Google Cloud Plattform umsetzen kann.

Terraform ist ein Multi-Cloud-Produkt. Administratoren, die wissen, wie man eine Infrastruktur bei einem bestimmten Anbieter erstellt, können auch direkt Ressourcen auf einen anderen Cloud-Anbieter adaptieren. Terraform arbeitet hier mit sogenannten Providern, welche die HCL (HashiCorp Language) Syntax in die jeweiligen API-Calls umwandelt und durchführt.

Terraform erstellt nach dem Aufbau der Cloudressourcen auch immer eine State Datei, welche die letzte Konfiguration der Cloud Ressourcen beinhaltet. Die State-Datei ist eine sehr wichtige Komponente. Ist diese Datei nicht da, geht Terraform davon aus, dass die Ressourcen noch gar nicht existieren und will diese komplett neu anlegen. Es ist also zwingend notwendig, die State Datei nicht lokal zu erstellen, sondern als Remote State vorzuhalten. Hier empfiehlt sich die Ablage in einem Storage Account oder S3 Bucket oder in der Terraform Cloud.

Ebenso lassen sich über Terraform auch Module erstellen, die z.B. Governance und Security Vorgaben enthalten, welche wiederum in unterschiedlichen Projekt innerhalb des Unternehmens verwendet werden können.

Wer mehr über Terraform erfahren möchte und erste Schritte unternehmen will, sollte sich diesen Artikel einmal ansehen: https://geekflare.com/de/terraform-for-beginners/

Terraform sollte für größere Cloud Projekte die erste Wahl sein.

Fazit zur Cloud Migration

Eine Migration in die Cloud ist nicht so einfach, wie es vielleicht erscheinen mag. Einfach Altsysteme von A nach B zu verschieben, kann sich schnell als Kostenfalle herausstellen und bringt auch keinen technologischen Mehrwert.

Alle Beteiligten sollten ein gewisses Grundverständnis für Cloudsysteme haben. Ist dieses nicht gegeben, muss mit Schulungen und internen Trainings nachgeholfen werden, um gemeinsam eine ordentliche Strategie zu erarbeiten.

Nicht jedes System ist für die Cloud geeignet.
Dies muss im Einzelnen geprüft und entschieden werden.

Auch ist es sinnvoll, gleich die ersten Schritte in der Cloud zu modularisieren und zu automatisieren. Es mag sein, dass man zu Beginn den späteren Umfang der Cloudumgebung noch nicht vollumfänglich abschätzen kann. Ein späterer Wechsel zu einer automatisierten Lösung kann wiederum aufwendig und kostspielig sein.

Überprüfen Sie also ihre Cloud-Strategie und holen sie alle beteiligten Personen ab.