Bart Farrell: First things first, who are you, what's your role, and where do you work?
Nic Vermande: Hi, my name is Nic. I work at ScaleOps as a Senior Developer Advocate. My role there is to be the face of ScaleOps and educate people on everything around Kubernetes Resource Management. Nowadays, resources involve things like traditional memory, CPU, but more GPU, and there's a lot of confusion about how GPU works and how AI workloads work. A lot of work around that and how to automate things, using ScaleOps, but also educating people around the foundation of Kubernetes and how to do it with native Kubernetes primitives. My role is to show people how with ScaleOps, we can close all the gaps in this ecosystem.
Bart Farrell: In a regulated Kubernetes environment, which production resource changes are safe to automate completely, and which should still require human approval? What determines that boundary?
Nic Vermande: That boundary, the line, is less about which resource you're touching. It's more about the evidence and the blast radius. A change with a proven track record against real production traffic, scoped to one workload and reversible in seconds, like trimming a memory request that's idle for weeks, is safe to fully automate. But at the same time, a human stays in the loop for anything that is novel, things like first-time decisions on a critical workload, anything that may be cluster-wide or anything like mid-incident. Proven and narrow earns autonomy. Novel and wide really doesn't.
Bart Farrell: Now, before an automated system is allowed to change CPU, memory, replicas, or scaling behavior in production, what guardrails and evidence should a platform team require?
Nic Vermande: There are three non-negotiables. First, a read-only proving period where the system shows its recommendation against real production load before touching anything. It is not a synthetic test. Second, an undo that fires automatically on SLO or error rate regression instead of an alert waiting for a human to notice. Third, coordination. Whatever is deciding CPU, memory, and replica counts has to know about your existing systems, like HPA, VPA, and Karpenter setup, because two systems independently fighting over the same pod is worse than either alone.
Bart Farrell: Nic, how do you prevent efficiency automation from undermining resilience? For example, removing headroom that turns out to be important during traffic spikes, failovers, or incidents.
Nic Vermande: Stop treating headroom as slack. It is not something you just shave once. It should be a floor that you recalculate continuously against demand, going lower when a workload is generally idle and higher ahead of a predictable spike. It should not be a static number based on last month's average. Only remove reserved capacity that is proven idle across real load and concurrency, never capacity that's just rarely used. Automation near an active incident or failover should pause itself. It should be intelligent enough to learn about the consequences because that's exactly when its historical pattern stops applying.
Bart Farrell: Nic, if people want to get in touch with you, what's the best way to do that?
Nic Vermande: I'm a runner, so Strava is the best way. That's a joke. More seriously, I'm active on Twitter and LinkedIn, or nic@scaleops.com if you want to talk to me.
