Product1 publisher3 min readPublished
groundcover buys Wand so software can change CPU requests on live Kubernetes clusters
Groundcover bought Kubernetes optimizer Wand Cloud for an undisclosed sum, adding software that changes CPU and memory requests on live clusters itself. The company did not say when customers get to run it on their own clusters.
The Product Desk · Product desk
What happened
- Groundcover disclosed its first acquisition, buying Kubernetes resource optimization startup Wand Cloud for an undisclosed sum, with Wand's founders and employees moving across to the observability company.
- Wand's software sits inside the cluster and makes vertical, horizontal and cluster-level scaling decisions at once, changing CPU and memory allocations on live infrastructure as demand moves.
- The technology goes first into groundcover's own platform and later to customers as an optimizer they run on their own clusters.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- decision Buyers who approved groundcover as a telemetry tool now face a separate decision about whether the same software may rewrite resource requests on running workloads, and who signs each change.
- exposure When a request comes out too low, the throttling or outage happens in the customer's production, and the on-call engineer has to defend a change the software made on its own.
- cost Because the platform runs in the customer's own cloud account, the vendor's efficiency work shows up as a line on the buyer's cloud invoice instead of the vendor's.
- precedent Once the company holding the production history also acts on it, safety controls around those actions become the terms platform teams negotiate at renewal.
An engineer types a CPU number into a YAML field before the service has served a single request. Kubernetes asks for that figure in advance, usually before the workload has run under real load, and it is the field Wand Cloud's software aims at [4]. Guess high and the waste repeats on every replica and every node [5]. Guess low and the workload gets throttled, or falls over when traffic shifts [5]. A right answer ages anyway, because services change [6].
Kubernetes already ships autoscalers for this. Groundcover's argument is that the vertical, horizontal and cluster-level ones typically run independently of one another [7]. Tighten a request, measured utilization goes up, and the horizontal autoscaler may add replicas nobody needed; packing on the nodes changes, and the cluster autoscaler reacts to that [8]. Wand's software runs inside the cluster and makes all three kinds of decision at once [9].
The payoff groundcover claims is the end of the recommendation queue: CPU and memory allocations change on live infrastructure as demand moves, so engineers are not left with a list of right-sizings to work through later [10]. Recommendation-only tooling saves nothing until somebody applies it.
Wand said it tunes a cluster for performance and availability first, with cost savings following once unneeded headroom is stripped out [11]. Shon Lev-Ran, Wand's co-founder and chief executive, said right-sizing "assumes we know the future." [12]
The reason to attach that to an observability platform is history. A workload can look overprovisioned when judged on the past hour and still be sized correctly for the traffic that arrives every Monday morning, groundcover said [13]. Its platform keeps production data at high fidelity, so teams do not have to decide ahead of time what to sample or throw away [14].
Groundcover co-founder and chief executive Shahar Azulay said production data is increasingly the context AI agents rely on to build, fix and run software [22]. "For infrastructure to become autonomous, systems also need to act safely on what they know," Azulay said [15]. Of Wand he said: "Wand has spent years building exactly that capability for Kubernetes." [23]
Two places get the technology. One is groundcover's own platform, which runs inside customer cloud accounts under a bring-your-own-cloud model [16], so whatever it consumes lands on the customer's bill and a leaner footprint should make keeping telemetry at full fidelity cheaper [17]. The other is the optimizer handed to customers for their own clusters [18]. The company did not disclose what it paid for Wand or say when that second product arrives [1][18].
Groundcover has raised $160 million to date, including a $100 million Series C led by One Peak in July [19], which puts about $60 million before that round [20].
For a platform team this is a change-management question. The data was already feeding engineers and AI agents working out what changed [21]. The software now acts on that data itself. So draw up two lists: workloads you would let it resize unattended, and workloads where a human signs the change. The first starts with stateless services that have a real replica count and a rollback someone has used recently. Everything holding state belongs on the second, and either way it is your on-call engineer who answers for a throttled service.
What to watch
- Whether groundcover ships a dry-run or approval mode for Wand's changes when the optimizer reaches customers, and what it excludes by default.
- Whether the promised leaner platform footprint turns up as a measurably smaller line on customer cloud bills.
- Any published limits on what Wand will change in a cluster, by namespace, workload type or scope of a single action.