Virtualisierung und VMware, das waren eine ganze Weile fast Synonyme. Zu einer Zeit, als etwa der KVM-basierte Virtualisierungsstack unter Linux noch gar nicht zur Verfügung stand – und schon gar nicht in seiner heutigen Qualität – ging VMware bereits auf Kundenfang und pries Firmen die Vorteile der umfassenden Virtualisierung an. Davon hat der Anbieter mehr als 20 Jahre lang gut und komfortabel gelebt, zumal er sein Produktportfolio sukzessive erweitert hat und Technologien wie Software-defined Networking (SDN) nach und nach in das eigene Produkt integrierte. Seit dem Aufkommen der Hyperscaler, also vor allem Microsoft Azure, Amazon Web Services (AWS) und Google Cloud Platform (GCP), herrscht allerdings so etwas wie Götterdämmerung in der Virtualisierungswelt. Kein Wunder, denn wer in AWS und Co. virtualisieren möchte, benötigt nur einen Account sowie das passende Kleingeld und kann in kürzester Zeit loslegen.

Die teils horrenden Kosten für die Lizenzierung der Software – also VMwares Haupteinnahmequelle – sind hier schlicht nicht vorhanden. Dass Cloud Computing letztlich kaum billiger ist als die Workloads, die virtualisiert vor Ort laufen, sei für diese Betrachtung dahingestellt. Fest steht: Seit es die großen Clouds gibt, orientieren sich immer mehr Unternehmen in deren Richtung, auch weil sie den teuren und aufwendigen Betrieb eigener Infrastruktur aufgeben oder zumindest stark reduzieren wollen. Für VMware ist das eine Horrorvision, denn wer lokal nicht virtualisiert, benötigt dafür auch keine Software. Die Public Clouds sind für den Anbieter mithin eine viel größere Konkurrenz, als es KVM und Co. unter Linux jemals waren.

VMware selbst zeigt sich indes wenig beeindruckt. Unternehmen würden auch künftig eigene Infrastruktur auf eigener Hardware betreiben und bräuchten dafür weiterhin die hauseigenen Virtualisierungsprodukte. Dafür sei das Unternehmen auch nach dem kürzlichen Verkauf an Broadcom bestens aufgestellt. Vorsorglich bringt sich VMware aber auch in Stellung für jene Kunden, die mit der Cloud liebäugeln – und bietet Möglichkeiten, hybride Setups besonders leicht zu betreiben. Dafür haben sowohl Amazon als auch Microsoft eng mit VMware kooperiert und eine Art gehostetes VMware in der Cloud auf den Markt gebracht. Worum es sich dabei handelt, welche Vorteile Administratoren aus der Nutzung ziehen und wo man als Systemverwalter aufpassen muss, verrät dieser Artikel.

Wenn von hybriden Setups zwischen VMware sowie Azure oder AWS die Rede ist, liegen die Tücken tatsächlich im Detail. Denn "hybrid" ist heute so wenig kanonisch definiert wie der Begriff des "Cloud Computing" selbst, und es ist nicht so unwahrscheinlich, dass VMware unter dem Begriff etwas anderes versteht als viele Softwareunternehmen, die im Cloud Computing aktiv sind.

Viele Firmen begreifen Hybrid Computing zunächst völlig zurecht als ein Konzept, das die eigene Abhängigkeit von selbst betriebener Infrastruktur reduziert, indem der Betrieb einzelner Komponenten des eigenen Setups zu einem Hyperscaler ausgelagert wird. Befragen wir die gängigen Beratungsfirmen, geht mit der Einführung von Hybrid Computing in Unternehmen aber fast immer auch eine Erneuerung der Softwarearchitektur einher.

Konkret bedeutet dies, dass Unternehmen viel Zeit und Geld investieren, um einzelne Teile ihres Software-Stacks fit für die Cloud zu machen: Mikroarchitektur statt großer Monolithen, persistente Daten in Datenbanken oder S3 statt im lokalen Dateisystem, Zusatzdienste wie DBaaS (Database-as-a-Service). Oft ist heute implizit auch der Umstieg auf Container-basierte Workloads inbegriffen. Diesem Umstand tragen Azure und AWS Rechnung, indem sie selbst ein gehostetes Kubernetes-Produkt "as a Service" im Portfolio haben, das binnen weniger Sekunden ein komplettes Kubernetes ausrollt.

Dieses Verständnis von hybridem Computing erzwingt viele technische Umstellungen und oft auch eine Änderung des Konzepts, wie Anwendungen grundsätzlich funktionieren. Das geht damit los, dass im Kubernetes-Beispiel gar keine (vom Nutzer verwaltete) virtuelle Instanz mehr nötig ist, also zumindest keine voll- oder paravirtualisierte. Die Formate für Abbilder von Betriebssystemen ändern sich, weil Kubernetes andere Formate braucht als VMware. Netzwerk und Storage sind anders zu provisionieren und so weiter – die Liste ließe sich beinahe beliebig fortsetzen.

Nun ist die Sache aus VMware-Sicht, dass das Unternehmen mittlerweile auch eigene Angebote für Kubernetes im Portfolio hat – sogar eine eigene Kubernetes-Distribution und bis vor ein paar Wochen auch ein Open-Source-Ökosystem rund um diese Distribution. Wenn vormalige VMware-Kunden allerdings aus VMware zu AWS und Azure umziehen und deren dortige Lösungen für Kubernetes und Co. nutzen, selbst wenn es nur für hybride Setups der Fall ist, kostet das VMware Umsatz, und zwar nicht zu knapp. Die Hybridstrategie von VMware ist heute deshalb anders, als im ersten Moment zu vermuten wäre. Der Anbieter ködert seine bestehenden Kunden mittlerweile nämlich mit dem Versprechen, dass sich Teile von On-Premises-Workloads aus VMware mit so wenig Aufwand wie möglich hybridisieren lassen.

Damit das funktioniert, hat VMware einiges an Vorarbeit geleistet und den eigenen Virtualisierungsstack quasi fit für Azure und AWS gemacht. Sie dürfen sich das durchaus als eine Art "private" Cloud innerhalb der Public Cloud auf Basis von VMware vorstellen, die die Nutzer erhalten. Und eben so vermarktet der Hersteller selbst dieses Angebot auch. Für Kunden soll sich das vor allem deshalb lohnen, weil sie ihre bestehenden Setups nur minimal verändern müssen, aber in den Genuss der meisten Vorteile hybrider Installationen kommen.

Allerdings ergeben sich zwischen der Art und Weise, wie VMware die Integration auf Azure gelöst hat, und jener für AWS, technisch einige Unterschiede. Die wiederum strahlen auch auf die Werkzeuge aus, die Administratoren hüben wie drüben zur Verfügung stehen. Und das hat letztlich Auswirkungen auf die Art und Weise, wie sich hybride Setups bauen lassen oder eben nicht. Es ist insofern sinnvoll, sich die technischen Lösungen einzeln genauer zu betrachten.

Microsoft und VMware kooperieren seit Jahren auf vielen Gebieten. Da verwundert es nicht sonderlich, dass beide relativ schnell zusammenfanden, als es um die gemeinsame Versorgung bisheriger VMware-Kunden mit Clouddiensten in Azure ging. Davon profitieren letztlich beide Anbieter: VMware schleppt für Azure Kunden an, die andernfalls vielleicht bei AWS oder GCP gelandet wären, und generiert damit Umsatz für Microsoft. VMware wiederum behält einen Teil des Kuchens für sich, weil der Kunde nicht komplett zum Hyperscaler geht, sondern Teile seines Setups on-premises betreibt.

Technisch ist das allerdings alles andere als trivial umzusetzen. Das macht ein Blick auf die einzelnen Komponenten eines klassischen vCenter schnell deutlich (Bild 1). Dieses kommt notgedrungen ab Werk mit etlichen Diensten für Infrastrukturaufgaben daher. Natürlich benötigen auch virtuelle Instanzen in VMware persistenten Speicher, ein sinnvoll konfiguriertes virtuelles Netz, Betriebssystemabbilder und ähnliche Vorrichtungen. Doch gibt es all das in einer typischen Cloud wie Azure auch, nur nicht für VMware optimiert.

Im Kern bestand die Aufgabe für VMware und Microsoft also darin, ein VMware in Azure so lauffähig zu bekommen, dass es im Hintergrund auf die vorhandenen Azure-Dienste zugreift, zur Außenwelt jedoch wie ein normales vCenter aussieht. Dabei kam VMware ein Produkt zu pass, das Azure bereits seit einigen Jahren im Angebot hat: die "Bare Metal"-Dienste. Die zeichnen sich dadurch aus, dass ein Kunde bei der Buchung eines entsprechenden Tarifs nicht – wie sonst – Zugriff nur auf virtuelle Instanzen bekommt. Stattdessen teilt der Cloudanbieter ihm die gewünschten Ressourcen in Form physischer Server unmittelbar zu. Das alles geht cloudtypischer mittels der gängigen Azure-APIs und lässt sich mithin gut automatisieren und orchestrieren.

Im Kern besteht die "Azure VMware Solution" mithin aus einem tatsächlichen vCenter, das Microsoft vollständig automatisiert für den Kunden betreibt und überwacht. VMware nennt das selbst "Software-defined Data Center" und legt die Latte damit ziemlich hoch. Nicht zu unrecht, denn weil in vCenter etliche Funktionen für die Migration von Diensten zwischen vCenter-Instanzen ohnehin vorgesehen sind, ist der Rest der hybriden Idee schnell erklärt. Hat der Administrator sein vCenter in den VMware-Werkzeugen erst einmal eingerichtet, fungiert es als Target für Deployments so wie lokale Installationen auch (Bild 2). Die gesamte technische Abwicklung auf der Azure-Seite übernimmt praktischerweise Microsoft. Aus Sicht des Administrators ist es also egal, wie unterhalb der VMware-Schicht in Azure Themen wie Netzwerk und Storage gebaut und realisiert sind – in VMware sehen die Ressourcen so aus, als liefen sie lokal.

Auf die Verfügbarkeit sämtlicher vertrauter VMware-Komponenten darf sich der Administrator dabei verlassen. Denn Azure in VMware inkludiert die VMware-Dienste vSphere, NSX-T, vSAN und tatsächlich auch HCX Advanced. Diesem kommt im Cloudkontext eine besondere Funktion zu, denn HCX ist quasi VMwares hausinternes Werkzeug für das Verwalten und Ausbalancieren hybrider Workloads. HCX kommt also dann zum Einsatz, wenn ein Administrator beispielsweise Teile des Set-ups erklärtermaßen lokal und andere Teile in der Cloud laufen lassen möchte; in diesem Fall konfiguriert der Admin per HCX, welche Teile wo laufen sollen und welche Regeln dafür gelten.

Der technische Ansatz, VMware vCenter vollständig als Anwendung auf Bare-Metal-Systemen abzubilden und mit dem Rest von Azure zu verbinden, ist technisch so simpel wie ansprechend. Den VMware ohnehin für hybride Set-ups beiliegenden Werkzeugen ist zu verdanken, dass der Admin sich über Themen wie die Netzwerkverbindung zwischen dem privaten Teil eines Setups und jenem Teil in der Cloud erst gar keine Gedanken zu machen braucht. Das erledigt VMware im Gespann mit den Azure-APIs nämlich weitgehend alleine. Wofür übrigens in den meisten Fällen keine speziellen Features in Azure zum Einsatz kommen – stattdessen haben Microsoft und VMware dafür gesorgt, dass die VMware-Bare-Metal-Instanzen zum größten Teil auf ohnehin schon existierende Azure-Funktionalität zurückgreifen.

Das liefert dem Administrator ausgesprochen praktische Vorteile, denn durch diesen Ansatz ist es möglich, ein vCenter in Azure (und damit indirekt auch jenes im Rechenzentrum vor Ort) mit dem größten Teil der anderen Azure-Dienste zu verbinden. Bekanntlich bietet Azure etwa einen Strauß voller Datenbanken "as-a-Service" an. Diese zeichnen sich dadurch aus, dass die komplette Virtualisierungsschicht für die Augen des Administrators wegabstrahiert ist. Nach dem Erstellen einer DB-Instanz gibt der Admin nur noch die Credentials sowie die Adresse der Datenbank in seiner App an. Um den Betrieb der Datenbank, deren Verfügbarkeit und Themen wie Backup und Restore kümmert sich die Plattform im Hintergrund autark. Von Features wie diesem profitieren hybride Setups möglicherweise stark: Wer etwa den Betrieb seiner Datenbank nicht länger selbst erledigen möchte, aber Teile seines Work-loads lokal behalten muss, kann VMware on Azure sowie die DBaaS-Angebote von Azure koppeln und so Features aus beiden Welten sinnvoll kombinieren.

Unternehmen muss allerdings klar sein, dass so ein virtuelles VMware-Rechenzentrum in der Azure-Cloud ein eher erhabenes Preisschild im Schlepptau hat. Für den Betrieb von vCenter in Azure sind mindestens drei Instanzen notwendig, und Azure hat für VMware gleich eigene Instanztypen definiert: AV36, AV36P sowie AV52. Diese kommen mit 576 GByte, 768 GByte oder 1,5 TByte RAM, 36, 36 oder 52 vCPUs und 15, 19 oder 38 TByte an Speicher daher, der bei den letzten beiden Instanztypen ausschließlich durch NVMe-Laufwerke bereitgestellt wird. Die AV52-Instanzen sind allerdings nicht in allen Azure-Standorten verfügbar, und generell lässt sich VMware on Azure auch nicht an jedem Azure-Standort betreiben.

Wer seine Daten im deutschen Azure-RZ wissen will, kann lediglich die AV36-Variante in Frankfurt nutzen. Die fällt bei On-Demand-Nutzung mit 9,26 Euro pro Stunde ins Gewicht. Gute Kopfrechner merken schnell: Ein minimales Azure-on-VMware-Setup mit drei AV36-Instanzen kostet in einem deutschen Rechenzentum monatlich 19.800 Euro, und dabei sind Kosten etwa für benötigte öffentliche IP-Adressen noch gar nicht enthalten. Einmal mehr zeigt sich an dieser Stelle, dass der Betrieb in dieser Form im Vorfeld gut durchzurechnen ist. Denn nur so können Unternehmen sicher sein, dass die durch den hybriden Betrieb von Ressourcen gesparten Beträge wirklich in einer sinnvollen Relation zu den anfallenden Kosten stehen.

Und noch ein Kritikpunkt fällt bei VMware on Azure zurecht an: Wer sein Setup nicht nach den Prinzipien des "Cloud Ready"-Computings umsetzt und hybride Workloads entsprechend betreibt, sondern lieber den vermeintlich einfacheren Weg geht, verbindet sich mit gleich zwei Unternehmen nahezu untrennbar. Einerseits bleibt die schon zuvor bestehende Bindung an VMware, deren Lösung das Produkt VMware on Azure ja gerade im Sinne beider Firmen verhindern soll. Und andererseits wäre da natürlich Microsoft, denn ein mit VMware auf Azure vergleichbares Angebot findet sich so weder bei AWS noch GCP. Technisch ist die Lösung mithin elegant, doch ob sie kommerziell Sinn ergibt, ist ein anderes Thema und stark vom Einzelfall abhängig.

Vergleichen wir das AWS-Angebot für VMware mit jenem von Azure, stellt sich im ersten Moment das Gefühl eines Déjà-vu merklich ein. Denn auf den ersten Blick wirken die beiden Angebote vergleichbar bis identisch: Auch bei AWS bekommt der Administrator eigene Bare-Metal-Server, auf denen AWS dann ein gesamtes vCenter mit allen Schikanen ausrollt (Bild 3). Dieses hinterlegt der Admin wieder in seinen Managementwerkzeugen und greift hinterher auf das AWS-vCenter zu wie auf ein lokales.

Bei der technischen Implementierung unter der Haube ergeben sich ebenfalls eher kleine Unterschiede. Denn auch bei AWS muss sich der Administrator nicht darum kümmern, wie einzelne Funktionen im Hintergrund implementiert sind. Der vCenter-Teil der Umgebung ist mit jener in AWS natürlich weitgehend deckungsgleich, und so lässt sich auch aus einem vCenter in AWS problemlos per NSX eine Quasi-VPN-Verbindung zu einem On-Premises-Setup aufbauen, um eine direkte Verbindung zu simulieren und "lokalen" Traffic zu erzeugen. Unterschiede ergeben sich allerdings im Detail. So hat AWS VMware vollständig in seinen Cloud-Formation-Dienst integriert. Es ist also möglich, ganze VMware-Cluster mittels Template in Sekundenschnelle zu starten. Wie relevant das in der Praxis ist, muss allerdings jeder für sich entscheiden. Dass Unternehmen reihenweise riesige vCenter-Cluster automatisiert und orchestriert in AWS aus dem Boden stampfen, scheint jedenfalls kein ganz alltägliches Szenario.

Insgesamt ist die Integration von vCenter mit den AWS-Diensten gelungen. Diese sehen aus vCenter-Sicht aus wie ganz normale AWS-Dienste in Setups ohne vCenter. Admins kommen mithin in den Genuss etlicher AWS-Funktionen, etwa DBaaS, Amazon S3 oder das elastische Dateisystem EFS. Sollen solche Dienste unmittelbar an laufende Instanzen in vCenter durchgeschleift werden, kommt es in einzelnen Fällen jedoch möglicherweise zu Kompatibilitätsproblemen, wenn Dienste in den vCenter-Instanzen mit den AWS-Diensten nicht kommunizieren können.

Wie in Azure ist auch bei AWS damit aber klar, dass der größte Teil der hybriden Fähigkeiten aus vCenter und seinen dafür ohnehin vorgesehenen Werkzeugen stammt. Wie bei Azure auch ist ein VMware in AWS stark vCenter-lastig; mit den nativen AWS-Werkzeugen für hybride Setups ist hier eher wenig auszurichten. Dafür funktioniert die Konfiguration von Diensten ebenso gut wie in einem reinen vCenter: Wer Instanzen in AWS/VMware etwa als Disaster-Recovery-Szenario für das On-Premises-Setup konfigurieren möchte, findet alle nötigen Hebel und Knöpfe dafür in der Managementoberfläche seines vCenters. Ähnliches gilt für die Migration von Workloads aus einer in eine andere Plattform. Dieser Arbeitsschritt ist in vCenter ohnehin vorgesehen, und weil das vCenter in der Cloud eben doch ein "echtes" vCenter ist, kommt es als Partner für eine solche Transaktion in Frage.

Wer gehofft hatte, er könne durch die Nutzung von AWS anstelle von Azure beim Anlegen hybrider Setups möglicherweise ein paar Euro sparen, wird enttäuscht. Auch Amazon lässt sich den Betrieb eines kompletten vCenters mit sämtlichen zugrundeliegenden Lizenzen, die dafür nötig sind, nämlich fürstlich entlohnen. Die Konditionen ähneln jenen von Azure, und auch vergleichbare Einschränkungen hinsichtlich des Angebotes müssen Kunden in Kauf nehmen.

Denn auch in AWS werden für ein komplettes vCenter vergleichsweise potente Instanzen benötigt, die schlicht nicht an jedem AWS-Standort zur Verfügung stehen. Einen Unterschied gibt es zwischen den konkurrierenden Unternehmen dann aber doch: AWS bietet potenziellen vCenter-Kunden nämlich eine Art Probepaket an in Form einer einzelnen Testinstanz. Diese ist für den produktiven Betrieb aber nicht geeignet und läuft nur 14 Tage lang.

Es ist übrigens nicht so, als sei VMware nicht durchaus bewusst, dass die Hyperscaler eine reale Bedrohung für die eigenen Umsatzziele darstellen. Zwischenzeitlich hat das Unternehmen sogar versucht, selbst eine Cloudlösung in der Breite zu etablieren, den VMware Cloud Director. Der erweitert eine klassische vCenter-Umgebung um die Komponenten, die eine Cloud in der Regel ausmachen, also programmierbar ansteuerbare APIs und die Möglichkeit, über Zonen und Regionen in die Breite zu skalieren. Den erhofften Widerhall fand der Cloud Director gegenüber AWS und Azure in der Industrie allerdings nicht, was auch an den mit ihm verbundenen und für VMware typischen Preisen zu tun gehabt haben dürfte. Wie üblich spricht VMware auch mit dem Cloud Director eher Großkunden mit dickem Geldbeutel an, doch die haben ihre Reise hin zu AWS und Co. oft schon lange begonnen oder gar abgeschlossen.

Fernab von eigener Infrastruktur hat VMware (auch) deshalb bereits vor Jahren damit angefangen, das eigene Produktportfolio im Hinblick auf cloudtypische Anwendungen und Dienste zu erweitern. Eine eigene VMware-Distribution von Kubernetes (Tanzu) etwa soll Kunden die Lust nehmen, sich bei anderen Anbietern umzuschauen, zumal VMware diese Distribution mit perfekter Integration in bestehende VMware-Produkte ausstattet.

Zur Distribution gehört zudem ein eigenes Deployment- und Managementwerkzeug namens VMware Aria (Bild 4), das dem Administrator einen Überblick über sämtliche Vitalwerte seiner Kubernetes-Umgebungen liefern soll und auch mit CI/CD-Optionen für das Ausrollen von Kubernetes-Clustern samt Anwendungen daherkommt. Daneben hat die VMware-Toolchain für das Ausrollen von Anwendungen per Kubernetes etliche Funktionen an Bord, um hybride Setups zu erstellen. Dabei nutzt Aria durchaus die nativen Funktionen der jeweiligen Anbieter, etwa AWS oder Azure statt VMware-spezifische Features, die es aber natürlich beherrscht und mit denen es gut integriert ist.

Freilich, so die Hoffnung bei VMware, nutzen Kunden Tanzu und die damit assoziierte Toolchain vor allem, um Kubernetes auf vCenter-Setups zu betreiben. Eine Hintertür hat der Anbieter sich aber eben offen gelassen, denn Tanzu läuft auch auf anderer Infrastruktur problemlos. Dafür braucht es dann auch keine vCenter-Implementierung, denn Tanzu funktioniert in den normalen Cloudinstanzen der Anbieter.

Obwohl die VMware-Integration sowohl in Azure als auch in AWS gut funktioniert und Firmen in der Tat die Möglichkeit bietet, hybride Setups ohne riesige Anfangsinvestitionen zu tätigen, hinterlässt das Konzept doch einen faden Beigeschmack. Wer nur die Vorteile nutzen möchte, Workloads nicht auf eigener Infrastruktur zu betreiben, der ist sowohl auf Azure als auch auf AWS mit dem VMware-Angebot fein raus. Zum Teil lassen sich ja sogar die "As-a-Service"-Dienste der Anbieter nutzen, was – wiederum bei relativ wenig Aufwand – zu deutlich weniger komplexen Setups führt. Doch eigentlich ist die Cloud nicht als Fortführung der Virtualisierung mit anderen Mitteln konzipiert.

Wer seine Workloads unverändert in die Cloud verschiebt, kann von vielen Vorteilen des Konzepts nicht profitieren. Dazu gehören Faktoren wie Continuous Integration und Continuous Development, die ihrerseits wieder erheblich verbesserte und viel effizientere Neuerungen beim Betriebskonzept erlauben. Modulare Softwarearchitektur, wie die Cloudapologeten sie vorschlagen, ermöglicht zudem eine schnellere und für Verzögerungen weniger anfällige Art der Entwicklung. Klassische VMware-Virtualisierung und AWS oder Azure im hybriden Tandem – das geht, und technisch durchaus zufriedenstellend. Mit einer Cloud hat so ein Ansatz allerdings nur bedingt etwas zu tun.