The Berlin storage start-up is extending its NVMe-over-TCP platform into synchronous replication, ransomware rollback and live cluster migration
Simplyblock has spent three years selling fast block storage to companies moving virtual machines from VMware onto Red Hat OpenShift. It now wants to sell the part of the VMware stack they miss most: disaster recovery that just works.
The company is adding synchronous and asynchronous replication, crash-consistent backups to S3 with ransomware rollback, and a live migration path between clusters to its software-defined storage platform. All of it ships under the existing per-node licence rather than as a separate product.
“We’re really the first hyper-converged storage product with native business continuity and DR for OpenShift in one single platform,” Rob Pankow, co-founder and CEO, said in a briefing. “What you get is storage, business continuity, and disaster recovery capabilities under one license.”
The gap on the far side of the VMware exit
The pitch rests on a specific observation about the enterprises now leaving VMware. Broadcom’s licensing changes pushed them towards OpenShift, which Pankow describes as “the most enterprise-ready Kubernetes-based virtualization platform out there.” Red Hat solves compute. What it does not fully solve, in his telling, is data management.
Michael Schmidt, co-founder and CTO, frames the product approach around comprehensive infrastructure. VMware’s historical strength lay in tightly integrated ecosystems, combining storage and failover directly into vSphere. As modern cloud-native environments evolved, bringing persistent storage, replication, and disaster recovery to Kubernetes platforms became a key focus for enterprise adoption.
“We complement the ecosystem, bringing robust storage and disaster recovery capabilities to OpenShift,” Schmidt said. “We are a storage vendor, but our focus is deeply integrated into the infrastructure stack.”
This approach allows the company to support enterprise customers alongside Red Hat’s native OpenShift Data Foundation, working hand-in-hand with Red Hat teams in the field. Pankow notes that collaboration is central to their go-to-market strategy, with Red Hat teams often bringing them into complex enterprise deals to provide specialized solutions. Rather than viewing Red Hat as a competitor, the company aligns its roadmap to enhance the broader OpenShift experience, keeping its competitive focus on specialized storage providers like Portworx.
What the new features do
The synchronous option replicates within a stretched cluster across two or three metro sites, with active-active paths configured from a single protection plan. Schmidt gives the round-trip latency ceiling as six to ten milliseconds, which confines it to metro distances. Recovery point objective is zero.
Storage efficiency is the number the company leans on. Because each site protects data with distributed erasure coding rather than three-way replication, the total overhead for a synchronously replicated pair is 2.5 times raw capacity. A customer can lose an entire site and one node on the surviving site and stay online.
Asynchronous replication runs between clusters and is aimed at anything beyond metro range. Pankow claims an RPO of about one minute against what he says is a typical fifteen for competing products. Operators can monitor the backlog and their actual RPO and RTO against the plan.
The backup layer takes crash-consistent snapshots across an application’s volumes and stores them as immutable deltas in any S3-compatible target, on-premises or in a public cloud. Schmidt, a former CIO, describes the ransomware case from experience. Restoring after an attack “can take days or even weeks,” he said, not because the backups are missing but because the applications have to come back in the right order. Simplyblock groups the volumes automatically and rolls back to a chosen point in time; the boot sequence for the application itself is defined by the customer in the protection plan.
The fourth piece, live forward replication, moves running volumes from one cluster to another without stopping I/O. Paired with KubeVirt’s VM live migration, it lets a customer drain old hardware, move a site, or shift workloads into a hosted OpenShift service while the applications keep running. “I don’t know any product out there right now in the Kubernetes ecosystem that can do that,” Schmidt said.
Rebuilds, throttles and headroom
Asked what a node failure does to the rest of the cluster, Schmidt separated three cases. A node that is down for maintenance is bridged, not rebuilt; the cluster keeps writing at the same protection level and rebalances when the node returns. A failed disk triggers a real rebuild, spread across every remaining device in parallel, which he says completes in minutes even for large drives. A site loss resyncs once connectivity returns, and the time depends on how much was written during the outage.
In every case, background work is capped at 20 percent of cluster I/O by an internal quality-of-service control. The design guidance follows from that: size the cluster so that 80 percent of its performance covers peak demand, and rebuilds never intrude on production.
Alignment to the OpenShift bill
Licensing is per worker node, deliberately mirroring how Red Hat counts OpenShift subscriptions. Pankow says the data-management layer typically lands at 20 to 30 percent of a customer’s OpenShift spend, which makes the total cost of the stack easy to forecast. Control-plane and infrastructure nodes are not charged.
Deals close three ways: a separate purchase order, a bundle through Red Hat, or via a partner. “The larger the customer, the more likely it’s separate,” Schmidt said, and proposals are out in all three forms. The software is listed on AWS Marketplace, though Pankow describes public-cloud-only deployment as a minority case. The pattern he sees more often is an on-premises primary with a hyperscaler standby, a design he acknowledges is expensive once cloud and OpenShift charges stack.
Where AI fits
Asked about AI workloads in production, Schmidt pointed to one very large deployment where each rack carries GPUs and Kubernetes orchestrates inference, though the customer has not disclosed the workloads themselves. His general view is precise about where low-latency block storage earns its place: retrieval-augmented generation, vector and graph databases, and inference checkpointing. Training, he says, wants a different kind of storage.
Customer onboarding
The company is straightforward about the edges. Simplyblock does not offer its own tooling for moving data out of VMware; that job belongs to Red Hat’s migration toolkit, which Schmidt rates as good enough, and any deduplication of incoming VM images would have to wait until the data lands on its storage. The backup features are positioned as a sound baseline rather than a replacement for Veeam or Rubrik in shops with deep investments there. And while volume grouping and consistency are automatic, the application restart sequence is still the customers to write.
None of that undercuts the core claim, which is narrower and more useful than a full VMware replacement: the storage, the replication and the recovery orchestration now live in one place, and they follow the Kubernetes operating model rather than fighting it. For the enterprises that renewed VMware for a few more years while they build the next stack alongside it, that is the kind of gap that decides whether the second stack ever becomes the first.
Leave a Reply