Cloud-Lift mit Plan: Wie wir mit Public OpenStack echte Migrationserfolge erzielt haben

Cloud-Migrationen scheitern selten an der Technik – sondern an der Umsetzung. Fehlende Automatisierung, komplexe Abhängigkeiten und ein starres Infrastrukturverständnis sorgen oft dafür, dass der „Lift“ nicht gelingt und der „Shift“ ausbleibt. Doch was, wenn man auf eine offene Plattform wie OpenStack setzt – bereitgestellt als Managed Public Cloud, mit vollem Fokus auf Kontrolle, Flexibilität und Datenhoheit?

In unserem vorherigen Beitrag haben wir die Grundlagen von OpenStack und die Möglichkeiten von Managed OpenStack als Public-Cloud-Angebot beleuchtet. Nun möchten wir einen Schritt weitergehen – und aus der Praxis berichten: Wie lassen sich bestehende Anwendungen zuverlässig und effizient in die OpenStack-Cloud überführen. Wir zeigen, wie wir mit Public OpenStack über die letzten Jahre hinweg eine Vielzahl erfolgreicher Cloud-Lift-Projekte umgesetzt haben – von der automatisierten Migration klassischer Workloads mit Terraform bis hin zu stabilen Netzwerk-, Compute- und Storage-Setups.

Lift & Shift leicht gemacht: Terraform als Schlüsselwerkzeug

Ein zentrales Element für den erfolgreichen Übergang traditioneller Workloads in die Public-OpenStack-Umgebung war für uns der exzellente Terraform-Provider für OpenStack. Wie bereits in Teil 1 unserer Reihe beschrieben, eignet sich OpenStack ideal für das sogenannte Lift & Shift – also die Migration von bestehenden Anwendungen, die auf klassischen virtuellen Maschinen basieren.

Mit Terraform konnten wir die zugrunde liegende Infrastruktur – von VMs über Netzwerke bis hin zu Storage – vollständig als Code definieren und automatisiert bereitstellen. Das brachte gleich mehrere Vorteile mit sich:

Reproduzierbarkeit: Die Infrastrukturkonfiguration ist versionierbar und lässt sich jederzeit konsistent nachbilden – egal ob für Test-, Staging- oder Produktionsumgebungen.
Automatisierung: Manuelle Eingriffe werden minimiert, was sowohl Zeit spart als auch die Fehleranfälligkeit reduziert.
Infrastruktur als Code: Durch die deklarative Beschreibung des Zielzustands kümmert sich Terraform selbstständig um die Umsetzung – effizient und nachvollziehbar.

Der OpenStack-Provider fügte sich dabei nahtlos in unsere bestehenden Workflows ein und ermöglichte die einfache Provisionierung von Instanzen (Nova) mit unterschiedlichen Betriebssystemen und Größen.

Vendor Lock-in mit Einschränkungen: Migrationen zwischen OpenStack-Anbietern

Ein häufig genanntes Argument für OpenStack ist der reduzierte Vendor Lock-in. In der Theorie stimmt das auch – in der Praxis haben wir jedoch gelernt, dass Anbieterwechsel gewisse Hürden mit sich bringen. Denn obwohl die OpenStack-API und die Kernprinzipien gleich bleiben, setzen viele Anbieter individuelle Konfigurationen um. Das äußert sich zum Beispiel in:

Unterschiedliche Regionsnamen: Die Bezeichnungen für die geografischen Regionen können von Anbieter zu Anbieter variieren.
Abweichende Instanz Flavours: Die Namen und Spezifikationen für die verschiedenen VM-Größen (Instanz Flavours) sind selten identisch.
Inkonsistente OS Image Namen: Die Bezeichnungen für die verfügbaren Betriebssystem-Images können sich unterscheiden. Oder auch die verfügbarkeit von Oses.
Andere Namen für Public Networks: Die Kennzeichnungen der öffentlichen Netzwerke sind nicht immer standardisiert.
Variierende Block-Storage Klassen: Die Namen und möglicherweise auch die zugrundeliegende Technologie der Block-Storage Klassen können sich unterscheiden.
Feinheiten in der Rechtegewährung: Die Mechanismen zur Rechteverwaltung für Kunden können leicht abweichen.

Das Gute daran: Eine Migration bedeutet selten eine komplette Neuentwicklung des Terraform-Codes. In der Regel reichen gezielte Anpassungen – vor allem an Variablen und Provider-Konfigurationen – aus, um die Anwendung in der neuen Umgebung zum Laufen zu bringen. Im Vergleich zu proprietären Plattformen bleibt der Aufwand also überschaubar – ein klarer Vorteil in Sachen langfristiger Flexibilität.

Starke Grundlagen: Netzwerk- und Compute-Dienste auf Augenhöhe

In unseren Projekten haben sich insbesondere die Kernfunktionen von OpenStack als stabil, performant und zuverlässig erwiesen – allen voran:

Neutron für flexible, virtuelle Netzwerkkonfigurationen mit Subnetzen, Routern und Load Balancern
Nova für robuste Compute-Ressourcen mit anpassbaren Instanzen

Die Performance der bereitgestellten virtuellen Maschinen erfüllte dabei durchweg unsere Anforderungen – sowohl in puncto Verfügbarkeit als auch hinsichtlich der Skalierbarkeit.

Block Storage mit Spielraum: Cinder und seine Klassen

Auch im Bereich Block Storage (Cinder) konnten wir gute Erfahrungen sammeln. Je nach Anbieter standen verschiedene Klassen mit unterschiedlichen Leistungs- und Preismodellen zur Verfügung – etwa schneller SSD-Speicher für performante Anwendungen oder kostengünstiger HDD-Speicher für weniger anspruchsvolle Workloads. Diese Vielfalt half uns, Workloads optimal auf die Anforderungen und Budgets unserer Kunden abzustimmen.

Public OpenStack in der Projektrealität

Unsere bisherigen Erfahrungen zeigen klar: Public OpenStack ist eine ausgereifte, flexible und praxisnahe Plattform für Cloud-Migrationen. Besonders bei klassischen Lift-and-Shift-Szenarien, bei denen virtuelle Maschinen im Zentrum stehen, spielt OpenStack seine Stärken voll aus. Die Integration mit Terraform sorgt für schnelle, reproduzierbare und wartbare Infrastruktur – während der überschaubare Migrationsaufwand zwischen Anbietern einen echten Vorteil gegenüber geschlossenen Plattformen darstellt.

Zwar bietet OpenStack (noch) nicht die gleiche Vielfalt an spezialisierten Managed Services wie die großen Hyperscaler – dafür punktet es mit Offenheit, Kontrolle und datenschutzkonformer Architektur. Für viele Unternehmen ist das die richtige Grundlage, um souverän und zukunftsfähig in die Cloud zu starten.