Sie glauben, drei Entwickler und KI können VMware ersetzen? Womit jedes „nächste große” Virtualisierungs-Startup rechnen muss

Ambition ist eine Sache. Mit drei Entwicklern, einem KVM-Fork und dem Glauben, moderne Tools machten alles einfacher, in einen 25 Jahre alten Schwergewichtskampf zu steigen, ist eine andere.

Sobald jemand sagt, er baue eine VMware-Alternative, kippt die Stimmung im Raum. Optimismus ist da, und der Frust über die Lizenzierung ist echt, aber die Skepsis ist es auch, und in diesem Fall kam sie alles andere als subtil daher.

Was als Proof-of-Concept-Pitch begann, wurde schnell zum Realitätscheck über Hardware-Support, Kernel-Engineering, F&E-Umfang und die Frage, was es wirklich braucht, um mit einer Plattform zu konkurrieren, in die über Jahrzehnte Millionen von Entwicklungsstunden geflossen sind. Der Thread drehte sich zwar um den Wechsel von Hypervisoren, zeigte aber vor allem, wie schwer es ist, ein ganzes Ökosystem zu ersetzen.

Der Traum: eine schlanke, KVM-basierte Alternative mit besserer Lizenz

Der Pitch klingt vertraut. Ein Senior Tech Lead mit über einem Jahrzehnt Erfahrung in der Virtualisierung betreut eine große Umgebung mit über 10.000 VMs. Nach der Broadcom-Übernahme sind die Lizenzkosten explodiert, die Ausgaben haben sich verfünffacht. Diesen Schmerz bestreitet niemand.

Als Lösung schlägt er eine neue KVM-basierte Plattform vor, mit sauberer UI, Feature-Parität zu vCenter und DRS-ähnlichen Fähigkeiten, von Grund auf mit modernen Tools gebaut und dadurch schlanker, smarter und günstiger.

Er stellt das als Validierungsfrage und ausdrücklich nicht als Werbung: Ist im Virtualisierungsmarkt Platz für einen weiteren ernsthaften Player?

Auf dem Papier klingt das vernünftig, denn Wettbewerb ist gesund. Es gibt Proxmox, Nutanix und Red Hat Virtualization, und Kubernetes hat ganze Infrastrukturmodelle umgekrempelt. Der Widerspruch im Thread galt aber gar nicht der Frage, ob VMware Konkurrenz verdient. Er galt dem Maßstab.

Die erste Mauer: Hardware-Hersteller-Support

Eine der ersten Antworten zielte direkt auf die Realität im Enterprise-Umfeld: Wie bekommen Sie Support von den Hardware-Herstellern?

Ohne Dell, HPE, Lenovo und Supermicro, also ohne diese Logos hinter Ihrer Kompatibilitätsmatrix, verkaufen Sie an Homelabs. Dieser Unterschied wiegt schwerer, als den meisten klar ist.

Enterprise-Käufern reicht es nicht, dass Ihr Hypervisor bootet. Ihnen geht es um Firmware-Validierung, Treiberkompatibilität, Lifecycle-Management, mit BIOS-Updates abgestimmtes Patching und darum, ob eine Support-Eskalation in Schuldzuweisungen oder in einer Lösung endet.

Ein Kommentator wies darauf hin, dass die Liste unterstützter Betriebssysteme für einen modernen Dell R660 eine kurze Liste kampferprobter Plattformen ist. Mit der Zeit ist sie eher kürzer geworden.

Auf diese Liste „kommt" man nicht einfach. Man verhandelt OEM-Vereinbarungen, finanziert gemeinsame Validierungsprogramme und investiert in Zertifizierungspipelines. Das kostet viel Kapital und Jahre an Beziehungsarbeit, und dabei hat noch niemand eine Zeile Scheduler geschrieben.

Die zweite Mauer: 25 Jahre F&E sind kein Wochenendprojekt

Den Ton im Thread veränderte dann ein anderer Kommentar: Sie bauen einen 1:1-Konkurrenten zu VMware? Wie lange soll das denn dauern?

ESXi als Hypervisor ist dabei nur ein Teil. Dazu kommen DRS, vMotion, Storage-Integration, NUMA-Bewusstsein, die Entwicklung der CPU-Architekturen, Confidential Computing, das Verhalten beim Speicher-Overcommit und die clusterweite Orchestrierung.

Eine besonders pointierte Antwort legte das schmerzhaft genau dar. DRS ist nicht statisch und auch kein Problem, das 2014 abgehakt wurde. Es entwickelt sich mit den CPU-Architekturen weiter. Granite Rapids bringt mehrere Chiplets pro Sockel, AMD und Intel handhaben Confidential Compute unterschiedlich, und die NUMA-Komplexität wächst weiter. Den Feature-Namen zu kopieren und das Parität zu nennen, reicht also nicht.

Hinter jedem dieser Features stecken Milliarden an F&E, ganze Kernel-Teams und Roadmaps, die fünf Jahre im Voraus mit den Hardware-Herstellern abgestimmt werden. An dieser Stelle wurde die Skepsis vom Abwinken zur technischen Kritik.

Braucht Ihr Produkt dreimal so viele Kerne und so viel RAM für dieselbe Workload-Stabilität, ist es egal, ob es kostenlos ist. Unternehmen kaufen dann trotzdem VMware, weil Effizienz eben Kosten sind.

Das Problem mit drei Entwicklern in 18 Monaten

Dann kam die Zeitplan-Behauptung: eine zuverlässige vCenter-Alternative in 6 Monaten bis 1,5 Jahren, mit drei fest zugeteilten Entwicklern.

Das löste sofort Unglauben aus. Eine Antwort nahm kein Blatt vor den Mund: Drei Entwickler, die in drei Jahren eine tragfähige Alternative bauen? Das passiert nicht. Ein anderer verglich das Vorhaben damit, jemandem eine Brücke nach Hawaii zu verkaufen.

Das ist hart, sicher. Die Skepsis betrifft aber den Umfang des Vorhabens und nicht die Intelligenz der Beteiligten. Selbst wenn man sich auf „nur" eine vCenter-Alternative beschränkt und den Hypervisor selbst weglässt, hat man es mit Folgendem zu tun:

• Verteiltes State-Management
• HA-Orchestrierung
• Live-Migration-Koordination
• Scheduler-Intelligenz
• Policy-Durchsetzung
• RBAC-Systeme
• Audit-Logging
• Plugin-Ökosysteme
• API-Stabilitätsgarantien

Ein CRUD-Dashboard mit Cluster-Icons ist das nicht. Als jemand im Thread anmerkte, dass allein in VMwares Management-Stack Millionen Entwicklungsstunden von Tausenden Ingenieuren aus zwei Jahrzehnten stecken, klang das weniger nach Verteidigung eines Konzerns als nach schlichter Mathematik.

Warum das KI-Argument nicht ankam

Irgendwann setzte der Startup-Fürsprecher auf moderne Tools. Entwicklung sei heute einfacher, KI beschleunige den Output, und Open-Source-Komponenten verringerten den Aufwand.

Das kam schlecht an. „AKA: KI-Schrott", antwortete ein Kommentator.

Das ist verkürzt. KI steigert die Produktivität durchaus, sie reduziert Boilerplate, beschleunigt Iterationen und hilft bei Dokumentation, Tests und Scaffolding. Kernel-Expertise beim Scheduling zaubert sie aber nicht herbei. Sie löst nicht die Cache-Kohärenz bei live migrierenden Confidential-VMs auf heterogenen CPU-Architekturen, und OEM-Vereinbarungen verhandelt sie auch nicht.

Die Kommentatoren hatten also nichts gegen KI. Sie hatten etwas dagegen, den Aufwand zu unterschätzen, und das ist ein Unterschied.

Eine Eintrittsbarriere, die ungern zugegeben wird

Jemand fasste die ganze Dynamik in einem Satz zusammen: Es klinge fast so, als gäbe es in diesem Markt eine unmöglich hohe Eintrittsbarriere.

Unbequem, aber wahr. Virtualisierung besteht aus mehr als Software, nämlich aus Hardware-Partnerschaften, Kernel-Engineering, der Anziehungskraft eines Ökosystems, Zertifizierungspipelines und langfristigem Vertrauen im Betrieb. Vertrauen ist dabei am schwersten zu ersetzen.

Unternehmen bewerten neben Features vor allem das Risiko. Sie fragen, wie stabil die Roadmap ist und ob Ihr Startup in fünf Jahren noch existiert.

Ironischerweise steigert gerade der Lizenzschmerz, der das Interesse an Alternativen weckt, auch die Risikoscheu. Wer sich gerade erst an einem Anbieterwechsel verbrannt hat, setzt seinen 10.000-VM-Bestand kaum auf ein MVP von drei Leuten. Diese Frage landet beim Vorstand.

Die Skeptiker sagen trotzdem nicht „Versucht es nicht"

Bemerkenswert ist, dass selbst die härtesten Kommentare Wettbewerb nicht schlechtredeten. Ihre Botschaft war eher: Versteht, wogegen ihr antretet.

Red Hat etwa wurde als glaubwürdig genannt, gerade weil das Unternehmen viel zur Kernel-Entwicklung beiträgt. Red Hat arbeitet im Maschinenraum mit, statt nur eine UI über KVM zu legen, und daran muss sich ein Neuling messen lassen.

Wer ernsthaft konkurrieren will, muss dorthin skaten, wo der Puck hinwill. Dazu gehören:

• Kernel-Ingenieure im Team
• Enge Zusammenarbeit mit CPU-Herstellern
• Tiefe Scheduler-Expertise
• Effizienz im großen Maßstab
• Zertifizierungsprogramme
• Compliance-Bereitschaft (jemand fragte sogar nach SOC2-Zeitplänen)

Unmöglich ist das nicht, aber mit zusammengeschustertem Wochenend-Hacking kommt man nicht weit.

Würden Unternehmen also wechseln?

Unter dem Sarkasmus steckt eine Antwort, und sie lautet Ja, wenn folgende Bedingungen erfüllt sind:

• Es hat Unterstützung der Hardware-Hersteller.
• Es erreicht Parität bei der Ressourceneffizienz.
• Es wirkt glaubwürdig auf lange Sicht lebensfähig.
• Es übersteht frühe Produktions-Workloads ohne katastrophale Rückschritte.
• Es zeigt, dass es versteht, wohin sich Infrastruktur entwickelt, und nicht nur, wo sie stand.

Die Hürde ist hoch. Der Frust über die VMware-Preise ist echt, der Appetit auf Alternativen existiert, und viele haben schon mit Proxmox oder anderen Stacks experimentiert. Ein Experiment ist aber noch keine vollständige Enterprise-Migration.

Was am Ende bleibt

Wer eine Alternative baut, muss beweisen, dass er in derselben Tiefe arbeiten kann wie VMware, und dafür reicht es nicht, auf VMwares Fehler zu zeigen. Der Thread war in diesem Sinn ein Stresstest für die Ambition und kein Angriff auf sie.

Wenn man daraus etwas mitnimmt, dann dass der Virtualisierungsmarkt nicht verschlossen ist, der Eintritt aber brutal teuer. Ein Startup, das mitmischen will, gewinnt nicht, indem es Parität in 18 Monaten verspricht. Es muss sich eine enge Nische suchen, dort ein schmerzhaftes Problem besser lösen als alle anderen, über Jahre Vertrauen aufbauen und sich von da aus ausdehnen. In der Enterprise-Infrastruktur verkauft man am Ende Vertrauen, und der Hypervisor ist nur das Vehikel dafür.