groundcover today announced the beta of groundcover Autonomous Infrastructure. groundcover is the world’s leading bring-your-own-cloud (BYOC), eBPF and OpenTelemetry (OTel)-native observability platform. The new Autonomous Infrastructure feature continuously adjusts CPU and memory requests for Kubernetes workloads. It bases every change on how those workloads behave in production. Wand, the Kubernetes resource optimization platform that groundcover acquired in September, supplies the underlying technology. The feature runs on the groundcover eBPF sensor, and customers receive the beta at no additional cost.
All groundcover customers running the sensor on Kubernetes can access the beta now. Additionally, groundcover invites design partners to work directly with its product team during the beta. The sensor already collects the production telemetry that Autonomous Infrastructure needs. Therefore, teams on a supported sensor version install nothing new and wait for no data to build up. On first launch, they see how much CPU and memory each workload requests versus what it uses. They also see potential savings and the workloads running short on resources. Nothing changes until an engineer turns the feature on and picks the workloads, namespaces or clusters it manages.
“Last month we said you need to see what’s happening before you can understand it, and understand it before you can safely act,” said Shahar Azulay, CEO and co-founder of groundcover. “Autonomous Infrastructure is where those steps come together for our customers. They can open it today and see what their clusters could save, using production data that already lives in their own cloud, before they let it change anything.”
The Cost of Setting Resources Once
Kubernetes requires teams to set CPU and memory requests before a workload faces real load. Teams rarely revisit those settings afterward. As a result, they usually learn about a wrong request in one of two ways. A service may hit out-of-memory errors and slow down. Alternatively, the monthly cloud bill may arrive higher than expected.
Cutting requests saves money until the next traffic spike. Then the same cut can cause a production incident. Because few teams tune requests continuously, these problems often surface a week or a month after they start.
Autonomous Infrastructure tackles this gap with telemetry that the groundcover eBPF sensor already collects. It adjusts resource requests in real time, within bounds the customer sets. Moreover, it balances two goals that pull in opposite directions:
- Cost: Lowering requests for over-provisioned workloads to remove headroom that goes unused.
- Stability: Raising requests for workloads running short, before throttling or out-of-memory errors.
The Autonomous Infrastructure view shows estimated monthly savings next to the number of under-provisioned workloads. It also charts potential savings against achieved savings over time. During the beta, customers set their own price per CPU and memory unit to calculate dollar figures.
Meanwhile, groundcover plans to add billing integration in stages. First, it will use publicly available cloud pricing. Later, it will connect to billing data such as the AWS Cost and Usage Report (CUR). Coverage also appears in views engineers already use in groundcover. Those views show how many workloads each cluster and namespace manages autonomously.
Engineers Decide What Autonomous Infrastructure Manages
Most resource optimization tools size each workload on its own. However, a request that looks right for one service can still starve its neighbors on a crowded node. Autonomous Infrastructure makes stability its first constraint. It sizes workloads with the full environment in view. Before raising a request, it considers how workloads pack onto the node and how much headroom remains. Consequently, an increase for one workload does not push the node out of resources.
The feature draws on the full-fidelity data that the groundcover eBPF sensor collects across applications and infrastructure. It therefore sees how a workload behaves alongside everything else running on the node and in the cluster. It does not rely on a narrow set of resource metrics.
Control stays with engineers at every level. The feature is opt-in:
- It stays off by default. An administrator turns it on for individual deployments or for every deployment in a namespace or cluster.
- Policies set minimum and maximum bounds for CPU and memory requests, and any setting can stay as-is.
- During the beta, it changes resource requests only. Limits stay as they are, and raising one requires user confirmation.
- Every policy change is versioned, and an audit log records who assigned each workload to a policy and when.
- Teams can start with lower-risk workloads, such as development namespaces. They can leave others untouched, such as a production database that needs room to grow.
“Most teams find out their resources were wrong a week or a month late, from an out-of-memory error or from the cloud bill,” said Shon Lev-Ran, co-founder of Wand and architect at groundcover. “Autonomous means the system keeps up with those changes for you. It doesn’t mean you give up control. You choose which workloads it touches and the bounds it works within, and you can see every change it made.”
Explore IT Tech News for the latest advancements in Information Technology & insightful updates from industry experts!
News Source: Businesswire.com
