CloudBolt COO defines Kubernetes automation at the speed of trust
This is a guest post for the Computer Weekly Developer Network written by Yasmin Rajabi, COO at CloudBolt.
CloudBolt is known for as the ‘cloud ROI company’ as it helps organisations be more efficient, agile and value-driven in the cloud.
Rajabi writes in full as follows…
Kubernetes automation is often framed as a technology challenge.
In reality, the fundamental obstacle is trust.
That is especially true when automation moves beyond software delivery and begins making decisions about live infrastructure. Most organisations are comfortable with automation in the CI/CD pipeline. Code ships every day through automated processes, and that has become a normal part of modern engineering.
But when the conversation turns to allowing automation to continuously right-size workloads, adjust resources, or influence production behaviour, the tone changes. People get quieter. Questions become more cautious. The pace slows.
Cautious code clinchers
It is easy to misread that hesitation as resistance to progress. I do not think that is what is happening.
In many cases, engineers are cautious because they have earned the right to be. They have lived through outages, regressions, noisy tools, and “smart” systems that created more work instead of less. They have been on the receiving end of overly confident automation that looked good in a demo but failed under real-world pressure. They have had to explain incidents to leadership, restore systems under stress, and rebuild confidence after something went wrong. Those experiences leave scars and shape judgment… and they should.
So when engineers hesitate to hand over control to automation in production, that hesitation is not irrational. It’s informed by experience.
This is why trust matters so much in Kubernetes optimisation.
On paper, the case for automation and autonomous optimisation is compelling. Kubernetes environments are dynamic by nature. Workloads shift, demand changes, and resource needs evolve constantly. At scale, manually tuning CPU and memory requests across large environments is increasingly impossible to sustain.
Unsustainable manual optimisation
Our most recent research tells the story: 54% of teams are running 100+ clusters, and nearly 70% say manual optimisation becomes unsustainable past 250 changes per day. Even the best teams can only review so many workloads with full context.
Automation promises a better path: continuous analysis, faster response, and decisions informed by live telemetry rather than occasional human review. But the promise of better outcomes is not enough on its own. Engineers aren’t simply evaluating whether the system can make a recommendation. They’re evaluating whether they can trust it when the stakes are real.
That distinction matters.
Trust isn’t built through slogans or pressure. It’s not built by telling teams they need to “get comfortable” with automation. And it certainly is not built by implying that hesitation is a sign of backward thinking. Trust is built the same way it’s built anywhere else: through evidence, consistency, transparency, and time. Most teams I talk to already know this intuitively. Engineers need to see how a system makes decisions. They need to understand the boundaries around those decisions. They need confidence that safeguards are in place, that recommendations can be validated, and that the automation behaves predictably under changing conditions. Most importantly, they need room to observe before they are expected to delegate.
That’s why successful adoption so often starts gradually. A team begins in recommendation mode. They review what the system suggests. They compare those suggestions to their own judgment. They test changes in lower-risk environments. Over time, if the automation continues to make sound decisions, confidence grows.
The speed of trust
CloudBolt COO Rajabi: The future of trust in K8S automation will be defined by how effectively organisations and providers help teams build confidence in using it.
This is the real speed of trust. It does not happen all at once. It builds incrementally, decision by decision, until one day the conversation shifts. The question is no longer, “Can we trust this?” It becomes, “Where else can this help?”
What engineers actually want is straightforward: automation that makes their environment safer and more stable, not less. That frees them from repetitive tuning so they can focus on architecture, resilience, and the work that actually requires human judgment. But they need to be able to inspect it, challenge it, and verify it before they rely on it fully.
In that sense, trust isn’t a soft issue sitting beside the technical conversation. It IS the technical conversation. Without trust, even the most sophisticated Kubernetes automation will sit at the edges of production, limited to suggestions and pilot projects. With trust, automation can begin to do what it was always meant to do: continuously improve systems in ways humans alone cannot sustain at scale.
The future of cloud operations won’t be defined simply by what automation is capable of doing. Instead, it will be defined by how effectively organisations and their providers help teams build confidence in using it. The companies that move furthest the fastest will not be the ones that dismiss caution.
They will be the ones who respect it, design for it, and give engineers what they need to trust Kubernetes automation through experience rather than expectation. Because in the end, hesitation is not the barrier. Unearned trust is.
But when it is finally earned, automation moves… at the speed of trust.