Building Platforms as Products

Building Platforms as Products

Jan 23, 2026

Guest:

  • Daniel Bryant

Every platform team hits the same wall: give developers too much freedom, and things break. Lock everything down, and they'll route around you.

Daniel Bryant's solution? Build a golden path. Some building blocks are required (security, compliance). Others are optional (CI templates, monitoring). Developers get self-service, and the platform stays safe.

In this interview: • How to balance self-service with governance • Why raw Kubernetes API access is a footgun (and what to do instead) • What the next 10 years of Kubernetes will look like

The common thread: treat your platform as a product, not infrastructure.

Relevant links
Transcription

Daniel Bryant: My name is Daniel Bryant. I work at Syntasso, and I'm head of product marketing here and also giving advice on platform engineering too.

Bart Farrell: And what are three emerging Kubernetes tools that you're keeping an eye on?

Daniel Bryant: Yeah. Emerging tools are definitely Kratix, it's a shameless plug, a tool I'm working on the moment as well. I'm interested with kagent on the AI kind of side, and also k0rdent I think is super interesting. Keeping it in the K family there, right? Uh, really keen to play with these more when I get back home.

Bart Farrell: Now, 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 and platform engineering?

Daniel Bryant: Yeah. Something totally we've really baked into Kratix as an example. I think the key thing is listen to your customers, listen to your engineers, what do they need, and then really think about building a platform as a product and building in the building blocks, if you like, to be able to customize the experience of things they want, but things are, that are necessary for the platform. You might be doing, for example, OPA policy, to ensure that folks can only do a certain deployment, for example. Make them all building blocks, make some of them optional, make some of them compulsory, and then you get that platform as a product, that golden path some folks call it. That is my best advice. Think about the platform as a product.

Bart Farrell: Great. So our guest, 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?

Daniel Bryant: Yeah. Giving the Kubernetes API, I think, is interesting. I might put it, like, behind something in terms of, like, breaking glass, because it is easy once you've got the full power to do all the things. And I think either you can have a high-trust environment, clear documentation, clear guidelines. Personally, I would put another abstraction on top, perhaps calling through a portal, calling through some kind of high-level API, these things. Make it easy to do the right thing. When I was a developer, I just wanted to ship value, right, ship code that solved business problems, but make it easy for me to do the right thing. You hear some folks talk about shift left, shift down, but, like, make it easy to, like, for me to do the good things, like security scans, think about architecture, think about reliability, but give me high-level APIs rather than a bunch of tools I got plugged together.

Bart Farrell: Kubernetes turned 10 years old last year. What can we expect in the next 10 years to come?

Daniel Bryant: Oh, this is super exciting seeing what's coming in, in 10 years' time. I definitely think AI is gonna get pushed down to be sort of more normalized. I think the UI, the API in particular that we interact with when building platforms is gonna be a lot more, well defined and a lot more sort of platform specific. We've got a lot of building blocks at the moment, and I think for AI to succeed, those building blocks are gonna be, need to be more high level and more structured. And I think even for humans to succeed, right, in working with AI, we're gonna need to see more of that thing. So I think the community is gonna continue to grow. I'm hoping there's a sort of a collation of some of the tools, 'cause at the moment, like, more tools, some of those means more cognitive load, more headaches just figuring out how to plug these things together. So I'm hoping that a lot of innovation still happens, but I'd like to see some standardization around certain areas just to make it, folks new to the space when they come onboard not to have their mind blown. I'd like folks to be able to pick up stuff, get started easy, do the right thing easy. I hope the community comes together and rallies around that.

Bart Farrell: What's next for you, Daniel?

Daniel Bryant: So I'm super excited to, like, push forward platform as a product, so at actually at KubeCon we've released a little, O'Reilly report around platform as a product. If I can get people thinking about building platforms as a product, regardless of what tools they choose, I think magic will happen. So my personal quest over the next year is to really spread the word with the team, we're all gonna fully built into platform as a product, and help folks think about actually delivering platforms that really help folks deliver business value, not just a collection of tools kind of coming together. So that's my main thing you'll hear me on the conference circuit over the next year. I shall be banging that drum continually, platform as a product.

Bart Farrell: Last but not least, if people want to get in touch with you, what's the best way to do that?

Daniel Bryant: Best way to get in touch with me at danielbryantuk on most of the interwebs, on LinkedIn, Twitter, Bluesky, you'll find me there. Love to chat with folks. You can find me in the CNCF Slack as well. You can find me in a bunch of other Slacks, usually with that moniker, danielbryantuk. Reach out. Happy to help with any problems you've got.

Podcast episodes mentioned in this interview