VAST kauft Red Stapler: ein Cloud-Schwenk mit einem riesigen Fragezeichen dran

Es gibt diesen Moment im Enterprise-Storage-Markt, in dem ein Unternehmen aufhört, wie ein Storage-Unternehmen zu klingen, und stattdessen klingt, als wolle es eine Plattform für alles werden. Das ist aufregend, wenn man glaubt, dass die Strategie schlüssig ist, und nervig, wenn man denkt, der Anbieter jage gerade dem Markt hinterher, der aktuell das höchste Bewertungsmultiple abwirft. Dass VAST Data Red Stapler gekauft hat, landete genau in dieser unbequemen Grauzone. Die erste Reaktion war schlicht: Worum geht es hier eigentlich? Ein Cloud-Kontrollpanel, angeheftet an ein Unternehmen, das für Hochleistungs-Storage bekannt ist und nicht gerade für einen ausgereiften öffentlichen Cloud-Storage-Dienst, fühlt sich entweder wie ein cleveres fehlendes Puzzleteil an oder wie ein weiterer glänzender Umweg.

Deshalb wurde die Diskussion schärfer als bei einer normalen Übernahme. Die Leute fragten, ob Red Stapler nützliche Technologie hat, und gleich danach, ob VAST noch immer auf eine klare Storage-Zukunft hinarbeitet oder ob es versucht, wolkiger zu wirken, weil dort das Geld, die Aufmerksamkeit der Hyperscaler und die Investoren-Fantasie zu Hause sind. Eine Kontrollebene kann mächtig sein, sie kann aber genauso gut Theater sein. Und im Storage-Markt haben die Leute gelernt, genau hinzuschauen, sobald „Cloud“, „KI“ und „Hyperscaler“ im selben Satz auftauchen.

Die Übernahme ergibt nur Sinn, wenn VAST es mit Cloud-Betrieb ernst meint

Bei der wohlwollenden Lesart ist der Kauf von Red Stapler überhaupt nicht seltsam. Wenn VAST an Hyperscaler, Cloud-Anbieter, KI-Serviceanbieter oder Unternehmen mit cloud-artigen internen Plattformen verkaufen will, dann reicht Storage allein nicht aus. Große Kunden wollen mehr als Kapazität und Performance. Sie wollen Provisioning, Mandantenfähigkeit, Billing-Hooks, Observability, API-getriebene Workflows, Identity-Integration, Lifecycle-Steuerung und einen sauberen Weg, damit sich Storage wie ein Service anfühlt und nicht wie ein Stapel Appliances, um die sich jemand kümmern muss.

Genau da fängt ein Cloud-Kontrollpanel an, Sinn zu ergeben. Es wird zur Schicht, die Infrastruktur in etwas Konsumierbares verwandelt. Ein Hyperscaler oder Managed Service Provider will nicht bei jedem Bucket, jedem Namespace, jeder Policy, jedem Kontingent oder jeder Performance-Klasse, die ein Mandant braucht, Tickets bearbeiten. Er will eine Plattform, die langweilig automatisiert wirkt, Kunden, die sich selbst bedienen, Metering, Leitplanken und möglichst wenige Menschen im Prozess.

Eine Stimme widersprach der Vorstellung, dass Hyperscaler automatisch ihre eigene Version von allem bauen würden. Das Argument war unverblümt: Wenn es immer der offensichtliche Schritt wäre, Storage-Protokolle selbst zu bauen, würden Cloud-Anbieter nicht weiterhin mit Unternehmen wie NetApp für File-Services zusammenarbeiten. NFS, SMB, Block, Objekt und die umgebenden Enterprise-Steuerungen zu bauen ist wirklich schwer, und zwar nicht in der Kategorie „ein GitHub-Repo herunterladen und fertig“.

Das ist die stärkste Verteidigung des Deals. Was nach zufälligem Cloud-Schnickschnack aussieht, wäre dann operative Verpackung für eine Welt, in der Storage als mandantenfähiger, API-first, hyperscaler-freundlicher Service verkauft werden muss.

Die skeptische Sichtweise: das sieht nach noch einem Schwenk aus

Die skeptische Sichtweise ist weniger nachsichtig. VAST versucht bereits, seine Story über Storage hinaus in Richtung KI-Infrastruktur, Datenplattformen, Analytics, Agenten und jetzt Cloud-Kontrollebenen zu dehnen. Irgendwann kann jede Erweiterung weniger nach Strategie und mehr nach Nervosität aussehen. Die ursprüngliche Beschwerde war klar genug: Ein Cloud-Kontrollpanel für ein Unternehmen ohne richtiges Cloud-Storage-Angebot fühlt sich nach noch einem Schwenk an.

Dieser Verdacht hat Substanz, weil Storage-Anbieter Reinventionszyklen lieben. Als On-Prem-Flash gefragt war, wurde jeder All-Flash. Als Hybrid-Cloud gefragt war, wurde jeder Hybrid-Cloud, und bei Kubernetes wurde jeder Cloud-Native. Als KI jedes Investoren-Deck übernahm, wurde jeder KI-Infrastruktur. Wenn jetzt Cloud-Service-Provider und Hyperscaler der Preis sind, braucht plötzlich jeder eine Kontrollebenen-Story, und die Leute merken das.

Ein Kommentator wurde sogar noch zynischer und deutete an, Übernahmen könnten genutzt werden, um Umsatz oder Dynamik besser aussehen zu lassen. Ein anderer witzelte über VC-finanzierte Blasen, in denen ein „.ai“ an irgendetwas dranzuhängen bei Sonnenaufgang Investoren herbeirufen kann. Diese Art von Sarkasmus mag im Detail unfair sein, aber sie spiegelt eine echte Ermüdung wider. Enterprise-Käufer und Betreiber haben zugesehen, wie sich Anbieter Trend um Trend anhefteten, oft bevor die Produktrealität nachzog.

Die eigentliche Sorge ist eine Markt-Story, die schneller wächst als der Produkt-Fußabdruck. Wenn der Kunde VAST aber immer noch überwiegend als Hochleistungs-Storage sieht, der Anbieter jedoch wie eine Cloud-Betriebsplattform für KI-Datendienste spricht, wird die Lücke schwer zu ignorieren. Genau in dieser Lücke lebt der Skeptizismus.

„Einfach nur S3“ zu bauen ist der Ort, an dem naive Pläne sterben

Einer der nützlicheren Teile der Diskussion war die Debatte rund um S3. Die einfache Sichtweise lautet: Hyperscaler sollten einfach ihren eigenen Objektspeicher bauen oder Open-Source-S3-kompatible Systeme nutzen. Auf dem Papier klingt das naheliegend. Es gibt Open-Source-Optionen, S3-APIs sind überall, Objektspeicher sind ausgereift. Warum also einem Storage-Anbieter für etwas bezahlen, das ein großes Engineering-Team selbst bauen könnte? An dieser Stelle fangen die Leute an zu lachen, die schon echte Systeme angefasst haben.

Einen S3-artigen Dienst zu bauen, der wirklich den Enterprise-Erwartungen entspricht, ist knüppelhart. Die API ist nur die Oberfläche. Darunter liegen IAM-Verhalten, Lifecycle-Policies, Replikation, Versionierung, Object Locking, Auditing, Multi-Site-Verhalten, Metadaten-Konsistenz, Performance-Isolation, Billing, Kontingente, Support-Tooling und eine Parade merkwürdiger Randfälle, auf die sich Kunden unbedingt verlassen werden, sobald sie sie finden. Ein Kommentator sagte, der durchschnittliche Kunde, der glaubt, er könne sich einfach etwas von GitHub schnappen und fertig sein, werde die ganzen seltsamen Protokollerweiterungen und fehlenden Teile auf die harte Tour entdecken. Das ist der Teil, den Anbieter tief verstehen. Das Produkt ist alles, was um das Basisprotokoll herum liegt.

Es gab auch Widerspruch gegen die Idee, dass MinIO oder Ceph das automatisch lösen. Eine Person argumentierte, MinIOs Enterprise-Version könne im Verhältnis zur Reife ziemlich teuer werden, während Ceph RADOS oder RGW zwar funktionieren können, aber oft ernsthaftes Babysitting oder kostenpflichtigen Support brauchen. Eine andere Person beschrieb, dass Ceph erst nach erheblichem Engineering-Aufwand funktioniere, wobei Leute weiterhin Bereitschaftsdienst leisten müssten, nur um sich um Rebalance-Jobs zu kümmern. Open Source ist deswegen nicht schlecht. „Kostenlos“ kann nur eben teuer werden, sobald Personalstand, Uptime, Feature-Parität und operativer Schmerz ins Spiel kommen.

Hyperscaler wollen nicht immer alles selbst bauen

Das Wort „Hyperscaler“ kann Erwartungen verzerren. Die Leute nehmen an, dass Hyperscaler jede Schicht selbst bauen, weil sie riesige Engineering-Teams haben. Manchmal stimmt das. Aber selbst sehr große Cloud-Anbieter kaufen, lizenzieren, partnern oder integrieren, wenn es sie schneller an den Markt bringt oder ihnen hilft, Enterprise-Workloads zu gewinnen, die bereits an vertraute Plattformen gebunden sind.

Deshalb taucht NetApp als First-Party- oder tief integrierter Dienst in großen Clouds auf. Hyperscaler könnten File-Storage durchaus selbst bauen. Enterprise-File-Storage steckt aber voller Kundenerwartungen, Protokoll-Eigenheiten, Migrationsreibung, operativer Historie und Admin-Vertrautheit. Ein Kommentator brachte es unverblümt auf den Punkt: Clouds wollen Unternehmen anlocken, die bereits Leute mit „NetApp-Administrator“ im Titel beschäftigen. Außerdem ist File-Storage zu bauen wirklich, wirklich schwer.

Dieselbe Logik könnte auch für VAST gelten. Wenn VAST Kunden mit riesigen KI- oder Analytics-Workloads hat und diese Kunden Cloud-artigen Konsum wollen, ohne auf Performance oder Datendienste zu verzichten, wird eine Kontrollebene wichtig. Wenn Service-Provider VAST-gestützten Storage als Managed Service anbieten wollen, brauchen sie mehr als rohe Storage-Nodes. Sie brauchen Mandanten-Abstraktion, Automatisierung, Nutzungsansichten, Provisioning-Workflows und wahrscheinlich genug Politur, um nicht die gesamte kundenseitige Schicht selbst bauen zu müssen.

Das Argument „ein Hyperscaler würde einfach sein eigenes S3 nutzen“ ist also zu einfach. Manche werden das tun, manche nicht. Manche werden eine Schicht selbst bauen und eine andere kaufen. Manche nutzen internen Storage für einen Workload und Anbieter-gestützten Storage für einen anderen. Cloud-Architektur ist selten so rein wie die Slogans, und die Frage ist, ob VAST sich in dieser unordentlichen Mitte nützlich genug machen kann.

S3 wird nicht alles ersetzen, egal wie sehr sich Leute ein einziges Protokoll wünschen

Ein weiterer nützlicher Diskussionsstrang widersprach der Idee, dass Objektspeicher das Ziel für jeden Workload sei. S3 ist wunderbar für viele Entwickler-Workflows, Data Lakes, Content-Storage, Backup-Ziele, Analytics-Pipelines und Cloud-native Anwendungen. Als universeller Ersatz für Block und File taugt es trotzdem nicht. Ein Kommentator sagte, S3 sei nicht dafür gedacht, VMs davon laufen zu lassen; es sei für Entwickler konzipiert, die Buckets wollen. Er erwarte, dass NFSv3 und VMFS in irgendeiner Form fast ewig bestehen bleiben.

Das ist wichtig, weil Cloud-Kontrollebenen-Gerede Workload-Grenzen verwischen kann. Storage-Anbieter deuten manchmal Konvergenz an: eine Plattform, viele Protokolle, jeder Workload, überall. Käufer sollten vorsichtig sein. Eine gute Objekt-Story löscht keine File-Anforderungen aus, eine gute File-Story löscht kein Block aus, und eine gute Kontrollebene lässt Anwendungen nicht magisch anders funktionieren.

Genau hier muss VASTs breiterer Pitch geerdet bleiben. Wenn Red Stapler dabei hilft, Cloud-Dienste zu verpacken, großartig. Aber Kunden brauchen weiterhin Klarheit darüber, welche Workloads VAST bedienen will. KI-Training? Inferenz? Data-Lake-Analytics? Enterprise-NAS-Ersatz? Objektspeicher? Service-Provider-Infrastruktur? Hyperscaler-Software-Schicht? Alles davon? „Alles davon“ kann nur stimmen, wenn Architektur und Betriebsmodell schmerzhaft klar sind, sonst klingt es einfach nach Ambition, die über den Rand schwappt.

Das Pendel schwingt vielleicht zurück, aber nicht auf die alte Art

Ein kurzer Kommentar meinte, der Schritt könnte gerade rechtzeitig kommen, um das Pendel beim Zurückschwingen Richtung On-Prem zu erwischen. Diese Zeile lässt sich leicht abtun, aber sie fängt etwas Reales ein. Das Cloud-Gespräch hat sich verändert. Unternehmen nutzen Cloud immer noch stark, doch die alte Gewissheit „alles geht für immer in die öffentliche Cloud“ hat sich abgeschwächt. Kostenüberraschungen, Datengravitation, KI-Infrastrukturbedarf, Souveränitätsbedenken, Latenz und GPU-Ökonomie haben Hybrid- und On-Prem-Architekturen weniger wie Altlasten und mehr wie bewusstes Design wirken lassen.

Das könnte VAST in die Hände spielen. Ein Cloud-Kontrollpanel ist nicht nur für die öffentliche Cloud da, es kann auch On-Prem-Infrastruktur cloud-artig wirken lassen: Self-Service, APIs, Mandantenfähigkeit, Automatisierung, Kontingente und besseres Lifecycle-Management. Das ist die Welt, die sich viele Unternehmen wünschen, also Cloud-Betriebsmodelle, ohne die Daten immer in die Region eines anderen zu verschieben.

Wenn das die Strategie ist, könnte Red Stapler eine praktische Übernahme sein: ein Weg, VAST leichter konsumierbar zu machen für Kunden, die überall Cloud-artiges Management erwarten, ohne dass VAST das Storage-Geschäft verlässt.

Aber es gibt einen Haken. Inzwischen sagt jeder Anbieter irgendeine Version davon. „Cloud-artig on-prem“ ist zu einer dieser Phrasen geworden, die alles oder nichts bedeuten können. Der Unterschied liegt in der Umsetzung. Reduziert die Kontrollebene tatsächlich operative Arbeit? Integriert sie sich mit Identity und Billing? Können Service-Provider sie sauber anbieten? Unterstützt sie echte Mandantenfähigkeit? Gibt sie Kunden Observability, der sie vertrauen? Macht sie VAST leichter zu kaufen, zu deployen und zu betreiben? Wenn nicht, ist es nur eine weitere Konsole, und die Welt hat genug Konsolen.

Der finanzielle Lärm macht die technische Story schwerer zu hören

Die Diskussion driftete auch in Bewertung, Profitabilität, Venture-Finanzierung ab, und ob der Storage-Markt gerade jeden mit Puls und einer KI-nahen Story belohnt. Das mag nach Klatsch klingen, aber es beeinflusst, wie technische Käufer Schritte wie diesen interpretieren. Wenn ein privates Unternehmen ein anderes kauft und dabei über Hyperscaler, KI und Cloud spricht, fragen sich die Leute natürlich, ob es bei der Übernahme um Produktlücken oder um Investoren-Optik geht.

Das ist manchmal unfair. Unternehmen können kluge Übernahmen tätigen und sich trotzdem um die Bewertung kümmern. Aber der Verdacht ist unvermeidlich, weil Enterprise-Storage ein langes Gedächtnis hat. Käufer haben zugesehen, wie Anbieter zu viel versprachen, aufgekauft wurden, die Richtung wechselten, Produkte einstellten, Features seltsam bündelten und Kunden mit Migrationsplänen zurückließen, die niemand wollte. Wenn sich die Story eines Unternehmens schnell ausdehnt, fragen sich Kunden, ob die Roadmap stabil genug ist, um ihr zu vertrauen.

Die stärksten Pro-VAST-Stimmen in der Diskussion leugneten die Ambition nicht. Sie argumentierten, die Ambition könnte gerechtfertigt sein, weil Storage schwer ist, Cloud-Storage-Dienste schwer sind und eine Feature-Parität nahe an AWS teuer zu bauen ist. Die stärksten skeptischen Stimmen sahen dieselbe Ambition und nannten sie einen Schwenk, eine Blase oder einen Griff nach Hyperscaler-Relevanz. Beide Seiten schauen auf denselben Schritt, die eine sieht Plattform-Reifung, die andere Narrativ-Inflation.

Der eigentliche Test ist, ob Red Stapler unsichtbar wird

Die besten Infrastruktur-Übernahmen verschwinden meist im Produkt. Die gekaufte Technologie wird zu einem Teil davon, wie die Plattform funktioniert. Kunden hören auf, nach dem Deal zu fragen, und fangen an zu bemerken, dass Provisioning einfacher wird, Service-Provider Mandanten schneller onboarden können, das Nutzungsreporting sauberer ist, APIs besser sind, Workflows sicherer sind und die Deployment-Reibung sinkt. Das ist es, was VAST beweisen muss.

Wenn Red Stapler zu einem angeschraubten Dashboard wird, gewinnen die Skeptiker. Wenn es zur operativen Schicht wird, die VAST-gestützte Infrastruktur wie einen echten Cloud-Dienst funktionieren lässt, wird die Übernahme im Rückblick offensichtlich aussehen. Das ist das Lustige an guter Infrastruktur-Strategie. Sie wirkt oft langweilig, nachdem sie funktioniert.

Im Moment ist die Unsicherheit fair. VAST versucht, mehr als ein Storage-Array-Unternehmen zu sein. Es will mitten in KI-Daten, Cloud-Betrieb, Hyperscaler-Infrastruktur und Hochleistungs-Storage sitzen. Das ist entweder eine mächtige Konvergenz-Story oder ein sehr teurer Jonglierakt.

Die Storage-Community hat allen Grund, harte Fragen zu stellen. Was genau ist das Produkt? Wer genau ist der Käufer? Welches Problem löst Red Stapler, das VAST vorher nicht lösen konnte? Wie viel davon ist Cloud-Kontrolle, und wie viel ist Cloud-Theater? Solche Fragen stellen Infrastruktur-Leute, die schon zu oft von großen Roadmaps verbrannt wurden, und daran ist nichts negativ.

VAST baut hier vielleicht etwas Echtes. Aber im Storage-Markt zählt Ankündigungsenergie wenig. Was zählt, ist, ob der Pager leiser wird.