Platform engineers, self-service and governance
Feb 13, 2026
You're building a platform on Kubernetes, but every guardrail you add feels like it takes autonomy away from your developers. How do you enforce security without slowing teams down?
Peter Kelly, VP of Engineering at Tigera (the company behind Project Calico), explains how tiered network policies let platform teams lock down what matters while giving developers a safe space to experiment — including dry-run staged policies that show what would break before anything goes live.
In this interview:
How to balance self-service and governance using tiered network policies in Calico
Why exposing the Kubernetes API to developers works when you pair it with staged policy dry runs
Emerging projects to watch: Kagent, Kgateway, and Istio Ambient Mode
What the next 10 years of Kubernetes look like — from edge deployments to AI inference with llm-d
Peter also previews Calico AI (coming early 2026) and Tigera's growing investment in L7 policy and Istio Ambient.
Transcription
Bart Farrell: First things first, who are you, what's your role, and where do you work?
Peter Kelly: My name is Peter Kelly. I'm the VP of Engineering at Tigera, the company behind Project Calico.
Bart Farrell: What are three emerging Kubernetes projects that you're keeping an eye on?
Peter Kelly: We're keeping a really close eye on what's happening in Agentic AI. There's some fantastic projects coming out of solo.io. These include Kagent for developing agents, Kgateway, and they announced today as well Agent Registry, which is really interesting. They're definitely projects we're keeping a close eye on. We're also leaning into the developments happening in Istio Ambient mode. We're super excited to be looking to contribute to some of that as well in the future.
Bart Farrell: One of our podcast guests, Ben Poland, thinks, for a platform team, you want to empower anyone to make the changes they need, rather than centralizing everything. How do you balance self-service capabilities with governance in platform engineering?
Peter Kelly: That's a great question. I don't see them as mutually exclusive competing forces. I think platform engineers and people building out platforms see the developers as their customers, as their users. I think you can provide strong guardrails and then some autonomy for the developers within those guardrails. In Project Calico, in our open source project, we give you the ability to do tiered policies. The platform team, the security team, they can define policies at an upper layer that are immutable and the application developers cannot interfere with them or change them. But then they can provide the application developers a lower tier where they can play around with their own network policy safely within those guardrails. I don't think they're mutually exclusive. I think platform engineers can provide strong layered approach and then give application developers the ability to manage and deploy their own network policy within their own policy tier.
Bart Farrell: Another guest of ours, Mac, believes we should expose the Kubernetes API to developers. The challenge is building guardrails around that exposure. How do you balance developer empowerment with operational safety?
Peter Kelly: Another great question. Similar to the last point, you can provide a tiered approach where you can lock down the important components in the cluster. Somebody like the platform engineering team or security team can apply policy at that layer. And then you can give application developers the ability to write network policy in a more isolated space, maybe specific to a namespace where they play in. Lastly, one cool thing you can do in Project Calico now in open source is staged policy. You can give the developers the ability to do a dry run so they can see what they would break before shooting themselves in the foot. They can take the policy for a dry run and see what breaks or what flows in the cluster would be affected before they actually go ahead and execute that policy. It gives a bit more safety, a bit more control, and a bit more autonomy for the developers to test that out.
Bart Farrell: Kubernetes turned 10 years old last year. What can we expect in the next 10 years?
Peter Kelly: The next 10 years in Kubernetes — Calico has actually been around for almost 10 years as well. We kind of go hand in hand with Kubernetes. I think we're going to continue to see the deployment of Kubernetes more on the edge. We're going to see the deployment of Kubernetes to support inference in AI models. There's a fantastic project called llm-d that's making that incredibly easy for Kubernetes. We're going to continue to see the user experience improve with projects like Headlamp. I think the next 10 years are going to be super exciting in Kubernetes.
Bart Farrell: What's next for you, Peter?
Peter Kelly: For me, I'm going to continue to help delight as many Calico users as I can in the community. We announced a couple of interesting things today. We have Calico AI, which is going to be available in early 2026. And we're also leaning into Istio Ambient Mode. We're going to continue to explore L7 policy and we have an interesting roadmap lined up for what's going to come next.


