VMware greift wieder nach der Public Cloud

• VMware bietet mit Hilfe von AWS-Infrastruktur wieder direkt Public Cloud Services an.
• Lesen Sie die Historie der bisherigen Versuche des Virtualisierungs-Software Herstellers mit eigenen Provider Angeboten.
• Wirtschaftlich ist das Angebot nur für Kunden mit statischen Legacy Workloads interessant.

Auch wenn beim AWS Summit letzte Woche in Berlin Amazons Prominenz mit Abwesenheit glänzte und weder CTO Werner Vogels noch CEO Andy Jessy für die 5000 Besucher nach Berlin kamen, war der Event doch voll von interessanten Ankündigungen. Einen Überblick dazu bietet der Analyst View meines Kollegen Jan Mentel. Die bei weitem wichtigste Ankündigung kam aber von VMware, die verstärkt als AWS-Partner auftreten und erneut Ambitionen in der Public Cloud haben. Bevor wir beleuchten, was es mit der VMware Cloud auf AWS auf sich hat, erlauben wir uns einen kleinen historischen Rückblick zum Thema VMware in der Public Cloud darzustellen:

• Gründung von VMware 1998: Da sprach noch keiner von Cloud.
• 5 Jahre Enterprise Fokus: Auch heute noch ist der wichtigste Markt für die Virtualisierungs- und Management-Software von VMware das On-Premise Corporate Data Center.
• 2008 VMware vCloud, der erste Public Cloud Versuch: Der Dienst der später unter vCloud Air zu finden war, hat auf voller Linie gegen die Hyperscaler verloren und nie Marktanteil erreicht. Im April 2017 hat VMware das verbleibende vCloud Air Business mit allen Rechenzentren und Kunden an den französischen Hoster OVH verkauft.
• 2010 Microsoft bündelt Hyper-V mit Windows Server: Die Unternehmen liefern sich einen massiven Konkurrenzkampf in dem VMware ein erstaunlich hohes Preisniveau für den On-Premises/Enterprise Markt halten kann. Heute ist jeder dritte Hypervisor in Unternehmen von Microsoft.
• 2012 versucht VMware verstärkt die Managed Service Provider anzusprechen: Obwohl zu der Zeit das größte Infrastruktur-Service Volumen hier lag, hat die meisten Managed Service Provider das VMware Lizenzmodell von Investitionen über den direkten Kundenbedarf hinaus abgehalten. VMware gründet auch Joint Ventures, wie die Canopy mit ATOS. Inzwischen hat sich Canopy im ATOS Managed Service aufgelöst und VMware Besitzer EMC hat seine Beteiligung in ATOS Aktien gewandelt.
• 2016 kristallisieren sich die Hyperscaler heraus: AWS wird von Azure nahezu eingeholt und Google drängt besonders für Cloud-native Anwendungen in den Enterprise Markt. AWS setzt auf XEN (bzw KVM), Azure auf Microsoft Hyper-V und Google auf KVM. Alle Hyperscaler benutzen zunächst ihre eigenen Management Tools. Damit ist nicht nur der Hypervisor-Marktanteil für VMware im am schnellsten wachsenden Infrastrukturmodell NULL, sondern auch der lukrative Tooling-Umsatz massiv unter Druck.
• 2017 Pivotal verlässt die exklusive Hypervisor-Strategie: Die EMC- und VMware Tochter Pivotal und treibende Kraft hinter dem Open Source Framework Cloud Foundry hatte bis dahin versucht den Hypervisor als Ressourcenmodell bei Cloud Providern wie der SAP Cloud zu verankern. 2017 ermöglicht Pivotal mit dem Kubo-Projekt das Management von Kubernetes aus Cloud Foundry und die SAP Leonardo Cloud konzentriert sich auch auf Kubernetes-Container mit deutlich weniger VMware Footprint.
• 2018 erreicht Kubernetes Marktreife bei Hyperscalern: Das bereits 2015 erstmalig von Google veröffentlichte Container-Management-System setzt sich durch. AWS, Azure und natürlich Google bieten Kubernetes-Cluster-as-a-Service an. Damit ist der Weg frei “fast” alle neuen und nativen Cloud-Anwendungen für Container zu schreiben. Auf welchem Hypervisor die Kubernetes-Cluster laufen, wird vollkommen irrelevant. VMware hat kaum Marktanteile oder eine Strategie für native Cloud-Anwendungen.
• 2018 VMware auf AWS als neuester Versuch von VMware in der Public Cloud: Dieser Dienst wird direkt von VMware angeboten. Obwohl er auf speziellen AWS Bare Metal Instanzen basiert, hat der Kunde keine Vertragsbeziehung zu AWS.

Diese kleine Abfolge zeigt nicht nur wie schnell sich dieser Markt ändert. Es wird auch deutlich, wie schnell eine Technik wie die Virtualisierung, also die Abstraktion der Hardware, für viele Anwendungen durch Container, also der Abstraktion des Betriebssystems, ersetzt wird. In den Cloud-Anfängen konnten Unternehmen das Operations-Modell ihrer Anwendungen modernisieren indem sie die virtualisierte Infrastruktur bei einem Managed Service Provider betreiben ließen. Heute sind diese “virtuellen” Umgebung die Legacy, VMware eine Commodity und die Modernisierung findet durch ein Aufbrechen der alten Anwendungen in Microservices statt.

Aus Sicht des Anbieter-Ökosystems ist dieser Markt brutaler als jedes andere Segment im IT- und Technologiemarkt. Die ersten Managed Service Provider, die auf VMware gebaut hatten, waren durch vCloud Air verunsichert, behielten aber ihre Marktanteile, weil VMware es vollkommen unterschätzt hatte was die Operations von Rechenzentren bereutet. Als das Business zu OVH ging, fühlten sich deutsche Größen, wie ATOS, Arvato oder T-Systems dadurch nicht mehr bedroht. Sie hatten mit VMware extrem professionelle Rechenzentren für die lokalen Märkte aufgebaut, die sich mit den Anwendungen füllen, die der Kunden im Kern nicht modernisieren kann. Kaum ein Jahr später riskiert VMware erneut die Loyalität dieser Partner indem es mit Hilfe von AWS wieder selbst zum Managed Service Provider wird. Ob dieser zweite Anlauf wieder floppt, wie vCloud Air, hängt nicht nur von den technischen Features, sondern auch von der Ökosystem-Strategie von VMware ab.

Aus der Perspektive eines Enterprise Kunden ist erst einmal wichtig, was diese neue Alternative “VMware auf AWS” überhaupt ist. Es ist ein Dienst von VMware, der auf Basis eines speziell entwickelten Bare Metal Instance Types von AWS beruht. Kunden kaufen aber beides, die VMware Softwarelizenzen und die Hardware direkt von VMware oder einem VMware Reseller. Da die VMware Lizenzen in den allermeisten Fällen heute schon als Subscriptions gekauft sind, kommt hier einfach eine weitere Option für die Hardware dazu. Der Vertragspartner ist also ausschließlich VMware, der das Modell mit Discounts bis zu 25 Prozent bei bestehenden VMware Lizenzen promotet. Falls ein Unternehmen schon AWS Kunde ist, werden diese Hardware-Instanzen im AWS Console gar nicht sichtbar, da VMware ja der AWS-Kunden ist. Damit ist das Geschäftsmodell schon einmal grundsätzlich anders als das Engagement von VMware mit irgend einem anderen Managed Service Provider. VMware hat bisher noch nie IaaS-Dienste unter ihrer Software von einem anderen Dienstleister vertrieben. AWS bekommt eine exklusive Position für dieses Konzept.

Anders herum steht “VMware auf AWS” offiziell dem gesamten VMware Channel zur Verfügung. Während dies für Systemintegratoren, wie Accenture, die keine eigenen Rechenzentren haben, sehr attraktiv ist, erscheint es mehr als fragwürdig für den Großteil der VMware Partner wie ATOS, Arvato oder T-Systems, die einen Großteil ihrer Rechenzentren gerade mit VMware Instanzen ihrer Kunden füllen. Hier ist der Channel-Konflikt vorprogrammiert, wenn VMware zu aggressiv nach der direkten Kundenbeziehung angelt.

VMWare hat dieses Konzept bereits vor neun Monaten auf den US-amerikanischen Markt gebracht und erst letzte Woche auf AWS Frankfurt und damit in der EU verfügbar gemacht. Crisp Research hatte letzte Woche nicht nur die Chance mit Vertretern von VMware und AWS zu dem Thema zu sprechen, sondern konnte sich auch mit einem Beta-User aus der Otto-Group austauschen.

Das VMware auf AWS Offering arbeitet zur Zeit mit einer einzigen Host-Spezifikation von 2 CPUs, 36 Core, 512 GB Memory. Dies ist eine neue AWS Bare Metal Instanz, die unter dem Namen i3.metal instance type im Mai diesen Jahres angekündigt wurde. Um die Verfügbarkeits-Mechanismen von VMware zu erfüllen, muss man einen Cluster von mindestens 4 mieten. Die kleinste jährliche Subskription ist also € 201.970 pro Jahr (24*356*5,9097*4). Damit ist das Hardware Commitment durchaus mit einem Azure-Stack im eigenen Rechenzentrum vergleichbar (siehe Bild 1). Noch teurer ist ein On-Demand Cluster.

Bild 1: Self-Service für AWS Hosts im VMWare Offering (Quelle: cloud.vmware.com/vmc-aws/pricing)

Das Entscheidende bei dieser dedizierten Hardware ist, wie weit ein Kunde sie wirklich befüllt bekommt. Während es einem Kunden bei AWS EC2 und auch bei vielen VMware-basierten Angeboten von Managed Services Providern egal ist ob physische Hosts halb leer stehen, geht dieses Risiko beim “VMware auf AWS” Offering auf das Konto des Kunden. Er kauft immer die ganzen dedizierten Hosts auf denen keine VMs anderer Kunden laufen. Auf so einer 36 Core / 512GB Machine kann man schon einige VMs laufen lassen. Diese Dichte entscheidet aber genau ob sich so eine Hardware-Subscription lohnt.

Bild 2: Kostenvergleich “VMware auf AWS”, normale AWS Instanzen und traditionelle On-Premises Kosten (Quelle: VMWare in Briefing für Crisp Research, Juni 2018)

VMware hat uns freundlicherweise ein Beispiel zum Kostenvergleich zur Verfügung gestellt (siehe Bild 2). Während die orange Kurve eines nativen Cloud-Dienstes für den Kunden immer gleich kostet – egal wie dicht die physische Hardware tatsächlich ausgelastet wurde – werden die Kosten bei VMware rechnerisch ab ca. 1,3 VMs pro Core günstiger. Das Beispiel geht von VMs mit 2 vCPUs und 8GB RAM aus. Auf der heute angebotenen 36 Core Hardware reden wir also von mehr als 46 VMs pro Host. Mal vier Hosts.

Wenn ein Unternehmen also weiß, dass es mehr als 184 (4×46) virtuelle Maschinen dieser Größe, beispielsweise mit einer Legacy-Anwendung und relativ konstanter Last, ohne viel Elastizität benötigt, ist das neue VMware Offering sehr attraktiv. Insbesondere weil die AWS Hosts nahtlos den VMware Tools der On-Premises Umgebung erscheinen und Migrations-Tools wie vMotion nahtlos funktionen sollen.

Unternehmen dürfen allerdings nicht unterschätzen, dass diese Self-Service Hardware Subscription eben NICHT die üblichen Vorteile eines Economies of Scale eines Hyperscalers an Endkunden weitergibt. Workloads sind nicht geeignet, wenn eine Elastizität der Infrastruktur verlangt wird oder sie heute schon auf den nativen Hypervisern der Hyperscaler laufen, wie dies sogar die SAP für alle drei Hyperscaler angekündigt hat. VMware auf AWS ist also interessant für statische Legacy Anwendungen. Vielleicht ein zu kleines Marktsegment, da viele Kunden ihre statischen und dynamischen VMware Workloads bei einem Managed Service Provider deponieren wollen. VMware auf AWS ist auch hochinteressant für Multi-Cloud Topologie. Wenn Sie also schon einzelne Anwendungen auf AWS haben und die schnelle “locale” Netzwerkverbindung zu einer VMware-Instanz benötigen, ist AWS mit seinem Direct Connect Offering sicher interessant. Viele Managed Service Provider sind allerdings inzwischen auch bei den gleichen Location Providern wie die Hyperscaler, so dass Kunden die Netzwerk-Vorteile im Einzelfall hinterfragen sollten.

Zusammenfassend möchten wir Kunden die sich für das neue VMware auf AWS Angebot interessieren eher warnen. VMware tritt hier selbst als Provider auf und hat damit alles andere als eine gute Reputation am Markt. Auch wenn ihnen AWS mit der Verfügbarkeit von Netz und Hardware hilft, ist die Verfügbarkeit des VMware Clusters in der Verantwortung von VMware Operations-Personal. Da haben alle verbleibenden Managed Service Provider deutlich mehr Erfahrung.