Seit der Broadcom-\u00dcbernahme von VMware im Mai 2023 hat sich die Virtualisierungslandschaft fundamental ver\u00e4ndert: Preiserh\u00f6hungen von bis zu 1.200% im Education-Sektor, \u00fcber 2.800 entlassene Mitarbeiter, und f\u00fcr viele kleinere MSPs Kostensteigerungen um das Zehnfache. Die Umstellung auf subscription-only Lizenzierung und versch\u00e4rfte Partner-Anforderungen (mindestens 3.500 Cores) zwingen Unternehmen zur Neubewertung ihrer Infrastruktur-Strategie.<\/p>\n\n\n\n
Mit OpenStack<\/strong> steht eine ausgereifte, standardisierte Open-Source-Alternative zur Verf\u00fcgung, die API-kompatibel ist und kein Vendor-Lock-in verursacht. Als einer der ersten drei SCS-zertifizierten Cloud-Provider in Deutschland betreiben wir seit Jahren produktive OpenStack-Umgebungen und begleiten Kunden bei der Migration aus propriet\u00e4ren Virtualisierungsstacks.<\/p>\n\n\n\n Aktuell migrieren wir selbst eine VMware-Umgebung an unserem Standort in N\u00fcrnberg-F\u00fcrth auf unsere OpenStack-basierte ScaleUp Open Cloud. Erste Migrationen wurden bereits erfolgreich getestet, der Umzug von Kunden-Workloads wird demn\u00e4chst (alternativ: ab Q3 2026) beginnen. In diesem Artikel teilen wir unsere praktischen Erfahrungen, technischen Learnings und den Weg zu einer kosteneffizienten, zukunftssicheren Cloud-Infrastruktur.<\/p>\n\n\n\n OpenStack eliminiert propriet\u00e4re Lizenzmodelle. F\u00fcr Unternehmen mit wachsender Infrastruktur bedeutet dies planbare Kosten und langfristige Unabh\u00e4ngigkeit von einem einzelnen Anbieter. Der Einsatz von Ceph als Storage-Backend erg\u00e4nzt diesen Ansatz ideal: Es ist software-defined, hochverf\u00fcgbar und vollst\u00e4ndig horizontal skalierbar.<\/p>\n\n\n\n Die Sovereign-Cloud-Stack-(SCS)-Zertifizierung, die auf Frameworks wie OSISM basiert, definiert einen gemeinsamen Standard f\u00fcr OpenStack-Deployments. Dieser umfasst reproduzierbare Architekturen, standardisierte APIs ohne Vendor-Extensions sowie garantierte Interoperabilit\u00e4t zwischen zertifizierten Providern. So entsteht kein gebasteltes Inselsystem, sondern ein offenes \u00d6kosystem mit konsistenten Schnittstellen.<\/p>\n\n\n\n OpenStack bietet native APIs, Multi-Tenancy, Self-Service-Portale sowie ein containerfreundliches \u00d6kosystem. Anwendungen, die aktuell noch auf klassische VMs setzen, k\u00f6nnen schrittweise in Container- oder Kubernetes-Stacks \u00fcberf\u00fchrt werden, ohne dass ein Wechsel der Plattform n\u00f6tig ist.<\/p>\n\n\n\n Die modulare OpenStack-Architektur erm\u00f6glicht den Betrieb in individuellen Auspr\u00e4gungen \u2013 von kompakten Edge-Deployments bis hin zu gro\u00df skalierten Rechenzentrums-Clouds. Ein API-First-Design, Infrastructure-as-Code und offene Schnittstellen erm\u00f6glichen Automatisierung auf allen Ebenen.<\/p>\n\n\n\n An unserem Standort N\u00fcrnberg-F\u00fcrth betrieb die ODN eine historisch gewachsene VMware-Umgebung, die eine Vielzahl von Kunden-Workloads hostet. Diese Workloads werden nun schrittweise auf unsere OpenStack-basierte ScaleUp Open Cloud umgezogen. Erste virtuelle Maschinen laufen bereits stabil in der neuen Umgebung. Der vollst\u00e4ndige Umzug ist bis Ende des zweiten Quartals 2026 geplant.<\/p>\n\n\n\n Als Zielbild sehen wir erhebliche Einsparungen bei den Lizenz- und Betriebskosten, eine geringere technische Komplexit\u00e4t sowie eine st\u00e4rkere B\u00fcndelung von Wissen innerhalb der Teams. Hinzu kommen mehr Flexibilit\u00e4t und Self-Service-Funktionen f\u00fcr unsere Kunden an diesem Standort sowie eine nachhaltige Modernisierung des gesamten Infrastruktur-Stacks. <\/p>\n\n\n\n Die Migration erfolgt mit abgestimmten Wartungsfenstern und optimierten Pfaden f\u00fcr die jeweiligen Workloads.<\/p>\n\n\n\n Der Wechsel von VMware zu OpenStack ist ein strategischer Schritt, der sorgf\u00e4ltige Planung erfordert. Die Vorteile sind signifikant, doch potenzielle Herausforderungen m\u00fcssen aktiv gemanagt werden, um einen reibungslosen \u00dcbergang zu gew\u00e4hrleisten.<\/p>\n\n\n\n Der technische Aufwand liegt also weniger in der Image-Konvertierung als in der Anpassung der Workloads an cloudnative Prinzipien. Dazu geh\u00f6ren die Cloud-Init-Integration, das Neutron-Netzwerk-Mapping und die Transformation statischer VM-Konfigurationen („Pets“) in automatisiert bereitgestellte, zustandslose Instanzen („Cattle“).<\/p>\n\n\n\n Das Narrativ von der \u00fcberm\u00e4\u00dfigen Komplexit\u00e4t von OpenStack stammt noch aus den fr\u00fchen Deployment-Phasen vor 2016, als das Lifecycle-Management manuell oder mit unreifen Werkzeugen erfolgte. Die OpenStack-Community hat darauf mit einer massiven Standardisierung der Deployment- und Upgrade-Prozesse reagiert.<\/p>\n\n\n\n Fr\u00fcher war der Day-1-Deployment-Prozess der gr\u00f6\u00dfte Schmerzpunkt. Heute gibt es Tools wie kolla-ansible, OSISM oder Yaook. Containerisierte Deployment-Tools vereinfachen die Installation und Wartung: Statt komplexer Systemkonfigurationen werden die einzelnen OpenStack-Services in Containern betrieben. Das erleichtert die Behebung von Abh\u00e4ngigkeitsproblemen, verbessert die Reproduzierbarkeit von Umgebungen und erm\u00f6glicht automatisierte Upgrades, wodurch die Betriebszeit maximiert und der manuelle Wartungsaufwand sp\u00fcrbar reduziert wird.<\/p>\n\n\n\n Auch die Betriebsmodelle sind gereift. Der Betrieb von OpenStack ist heute durch den Einsatz von Ansible, Terraform und Kubernetes gepr\u00e4gt. Die Verwaltung wird transparent und skalierbar, weil alle Konfigurationen im Code dokumentiert sind.<\/p>\n\n\n\n Die Vielzahl der OpenStack-Komponenten \u2013 es gibt \u00fcber 50 Projekte \u2013 erscheint auf den ersten Blick verwirrend. Moderne Distributionen und Betreiber \u2013 wie wir selbst \u2013 konzentrieren sich jedoch auf eine stabile und schlanke Kernauswahl. Dazu geh\u00f6ren Nova, Neutron, Cinder bzw. Ceph, Keystone, Glance und Horizon. Dadurch wird die Komplexit\u00e4t reduziert und das Wissen im Team auf die kritischen Services fokussiert.<\/p>\n\n\n\n Mit Frameworks wie OSISM und dem Fokus auf moderne, standardisierte Deployment-Ans\u00e4tze ist OpenStack heute eine betriebssichere und hochgradig automatisierbare Plattform<\/strong>, deren Komplexit\u00e4t sich prim\u00e4r auf die initiale Architektur und nicht auf den laufenden Betrieb konzentriert. Die Notwendigkeit, OpenStack als Infrastructure-as-Code zu betreiben, hat zur Reifung von Tools wie Terraform und Ansible beigetragen. Diese Automatisierungsans\u00e4tze sind heute Best Practice und machen den OpenStack-Betrieb nicht komplizierter, sondern transparenter, reproduzierbarer und skalierbarer.<\/p>\n\n\n\n Der Schritt von VMware zu OpenStack ist nicht nur eine Reaktion auf steigende Lizenzkosten, sondern ein strategischer Modernisierungsschritt in Richtung offener Standards, automatisierter Betriebsmodelle und agiler Cloud-Architekturen, die mit den Anforderungen der n\u00e4chsten Jahre wachsen k\u00f6nnen. Mit strukturierter Planung, realistischen Timelines und dem Fokus auf stabile Kern-Services ist der Umstieg auf OpenStack technisch machbar und wirtschaftlich sinnvoll. <\/p>\n\n\n\n Als SCS-zertifizierter Provider betreiben wir produktive OpenStack-Umgebungen an unseren Standorten in Berlin und N\u00fcrnberg und begleiten diese Transformation von Architektur und Design \u00fcber das Deployment bis zum laufenden Betrieb.<\/p>\n\n\n\n Sie evaluieren gerade, ob OpenStack f\u00fcr Ihre Umgebung eine sinnvolle VMWare Alternative ist? Get in touch with us<\/a> f\u00fcr eine technische Erstanalyse Ihrer aktuellen VMware-Umgebung und einen konkreten Migrationsfahrplan.<\/p>\n\n\n\n Quellen zu den Broadcom\/VMware-Entwicklungen:<\/strong><\/p>\n\n\n\n <\/p>","protected":false},"excerpt":{"rendered":" Since the Broadcom acquisition, licensing costs for VMware customers have risen dramatically, and the partner program has been revised. This article outlines the migration path from VMware to OpenStack\u2014including preparation, phases, and common pitfalls. <\/p>","protected":false},"author":5,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18,66],"tags":[350,105,349],"class_list":["post-16969","post","type-post","status-publish","format-standard","hentry","category-cloud-computing","category-openstack","tag-migration","tag-openstack","tag-vmware"],"_links":{"self":[{"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/posts\/16969","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/comments?post=16969"}],"version-history":[{"count":6,"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/posts\/16969\/revisions"}],"predecessor-version":[{"id":16987,"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/posts\/16969\/revisions\/16987"}],"wp:attachment":[{"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/media?parent=16969"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/categories?post=16969"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.scaleuptech.com\/en\/wp-json\/wp\/v2\/tags?post=16969"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Warum OpenStack?<\/h2>\n\n\n\n
Kosteneffizienz und Unabh\u00e4ngigkeit<\/h4>\n\n\n\n
Standardisierung statt propriet\u00e4re Extensions<\/h4>\n\n\n\n
Moderne Cloud-Architektur<\/h4>\n\n\n\n
Flexibilit\u00e4t und Automatisierung<\/h4>\n\n\n\n
Die Migration an unserem Standort N\u00fcrnberg-F\u00fcrth: Stand und Ziele<\/h2>\n\n\n\n
Technische Herausforderungen und m\u00f6gliche Fallstricke beim Umzug von VMware zu OpenStack<\/h3>\n\n\n\n
\n
\n
\n
\n
Komplexit\u00e4t vs. Realit\u00e4t: Die Evolution des OpenStack-Managements<\/h2>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
\n\n\n\n
\n\n\n\n\n