There is an old ritual in enterprise storage, and anyone who has ever evaluated a product knows every step of it.
You request a demo.
You wait for a call.
You get a license.
And then, days or weeks after the moment that first sparked your curiosity, you finally get to touch the thing you wanted to try.
For some buyers, that ritual is perfectly reasonable. For the engineer or builder or architect who is used to standing up whatever they need without asking anyone's permission, it is a gate in front of a door they could have opened themselves. By the time the call gets scheduled, the afternoon they had free for this is long gone.
Today we are announcing CNQ Spark, a real, fully working Qumulo deployment that lands in your own subscription in less than 10 minutes. Scan a code or follow a link while logged into your own Azure account, and build a fast, nimble data platform that works natively with any SMB, NFS, or object workload from a single virtual machineNo license request. No call with sales. No waiting. Spark sweeps all the old gates aside.
The real thing, not a trial SKU
Anyone who has evaluated software for long enough has learned to distrust the free version, the one that turns out to be a stripped-down copy of the real product: either the useful features have been disabled from the get-go, or they work great for 7/30/90 days and then shut off. The free version is built to look good in a demo and fall apart under real use, right? We’ve all been there.
Spark isn't that. It runs the same Qumulo Core file engine, and exposes the same REST API, that a paying customer's cluster does. Nothing about it is a simulation. Here is what that means in practice:
One namespace, three protocols. NFS, SMB and S3, all against the same data at the same time. Drop a file in through one protocol and pick it up through another.
Your own Active Directory. Join your own domain and test against your actual identity infrastructure, not a synthetic one built for the occasion.
Snapshots, the same as on any Qumulo cluster.
Live analytics. Throughput, IOPS, latency and capacity, charted in Grafana as the workload runs.
Three ways to manage it. A web UI, a terminal UI, and the full REST API. Use whichever you like, or all three. Whatever you do in one is just a call to the same API underneath (with one note: S3/object is included but disabled by default. Use the API to enable and configure object support)
Scratch space for whatever you're building
A great deal of modern work needs fast, disposable storage and doesn't justify a procurement cycle to get it: a place to stage data for a training run or a render job, a place to put the files a pipeline passes from one stage to the next. Spark is built to be that place, spun up the same way you'd spin up any other dependency for the workload.
It is also a natural fit for agents. Humans got better at working together when they stopped keeping everything on their own machines and started sharing a file share. Agents need the same thing: a common space to keep context and collaborate. Spark gives them one.
And because it sits in your own Azure subscription, the services you already use can reach it. Microsoft Foundry and Microsoft Fabric can work with Spark through its native object storage connections.
What it costs
There is no Qumulo license and no subscription fee, and there never will be. You pay Azure for the virtual machine and storage that Spark uses, exactly as you would for any other workload, and nothing more. Every Spark VM comes with 1 TB of capacity.
What Spark is not
Spark is for scratch data, development and evaluation. We want to be plain about that.
It runs on a single node, and its resilience comes from the Azure managed disk beneath it, not from Qumulo's multi-node erasure coding. It has no built-in data protection. If the virtual machine fails or restarts, you should expect to lose what was on it. So don’t put anything in Spark that you can't afford to lose. When a workload starts to matter, that is exactly what a protected, multi-node Azure Native Qumulo deployment is for.
One more thing…
When you start up your Spark VM for the first time, it’ll ask for an email address. It’s optional; we use it to track the number of Spark launches, but we can’t access either the VM itself or the data that sits on it. It’s fully secure in your Azure environment: no external IP address, no back-channel link to Qumulo, and (again, for those of us who want more than anything to just deploy and build and run new stuff) no follow-up call from a sales rep. If you like it, and you want to expand to a full multi-node Qumulo deployment, you know where to find us.
Try it now
Most storage evaluations ask you to prove you're serious before you can touch anything. This one asks only for an Azure account and a few minutes. Scan the QR code, or follow the link: qumulo.com/product/cnq-spark.