Building Composable Platforms

Building Composable Platforms

Mar 2, 2026

Guest:

  • Abby Bangser

Building an internal platform that works for one team is straightforward. Building one that scales across an entire organization — where every team has slightly different needs — is where most efforts stall.

Abby Bangser, Principal Engineer at Syntasso and KubeCon co-chair, shares her approach to platform engineering at scale.

In this interview:

  • Why composability and progressive discovery are the keys to platforms that serve multiple teams

  • How GitOps should be the default building block — but why platforms also need imperative processes

  • What the next 10 years of Kubernetes look like as it becomes core infrastructure

The best platforms aren't one-size-fits-all — they're composable systems that balance standardization with the freedom teams need.

Relevant links
Transcription

Bart Farrell: Who are you, what's your role, and where do you work?

Abby Bangser: Hey, my name is Abby Bangser. I am a principal engineer at Syntasso, and I build platforms.

Bart Farrell: And what are you doing at KubeCon?

Abby Bangser: What am I doing at KubeCon? A few different hats. I'm a speaker, I'm a sponsor, and I'm one of the co-chairs. Help to build this awesome schedule that we have here today.

Bart Farrell: Which three Kubernetes emerging tools are you keeping an eye on?

Abby Bangser: I think one of the ones I'm keeping an eye on that's emerging is OpenFeature, and it's because I also keep an eye on OTEL. I get maybe a two for one there. I think what OpenTelemetry has done for the industry is amazing. And what OpenFeature is doing for the feature flagging can be just as amazing if it continues to grow as it is. Keeping an eye on that. And then kind of from the smaller side, the emerging side, I saw something at Maintainer Summit around CRDify. And there's actually two tools there where they're looking at how to create better APIs in CRDs without having to know everything about Kubernetes, CRDs from all of time and all the patterns you're supposed to follow. Keeping an eye on that as well now.

Bart Farrell: Our podcast guest, Ángel, stressed that standardizing everything makes cluster management easier. What's your advice for building platforms several teams can use in an organization?

Abby Bangser: That's a great question because that is the value of a platform, right? The goal of an internal platform to an internal organization is to build an economy of scale for your company. You're not building a platform for one person or one team, you're building it for many teams and you're trying to build it from pieces you can take from the market that's commodities at this point. But the challenge there is that standardizing across teams isn't always obvious and a lot of teams need subtle differences from each other. The big thing here is to build like any other software and to build it composable. How can you build things that are really low level and provide as much freedom as your organization is willing to provide, but then build higher levels of abstraction to get started? I learned from the team over at Spotify about progressive discovery of things, and you can start people off on a journey of really abstracted, high-level components that they can use very quickly off the shelf, as long as when they need to break glass to something a bit more specific or a bit more unique to them, you have the composed up parts that allow them to do that. I think composability is the key there to making sure that you have something that can be unique to specific teams in your organization while making sure it's still an economy of scale for your organization.

Bart Farrell: Another guest of ours, Hans, argues that GitOps is an excellent building block for platforms with great developer experience. He mentioned the ability to merge, review, and discuss code changes and PRs and the additional benefit of not granting permissions. Should all platforms use GitOps? What's your experience?

Abby Bangser: GitOps is a fantastic building tool. I think beyond the code review side of things and that sort of process, what it does is it makes things declarative, which helps you with disaster recovery. It helps you with scalability of deployments. It is a really powerful building block. I absolutely believe that platforms should and will use declarative GitOps as a big part of it. The one thing I'll call out, though, is that it's really exciting to say everything should go to GitOps, but everything can't because at the end of the day, we're still a people process. And there are things that need to be done that are imperative in nature, that are an API call, they are a manual approval. That's a part of building the process of your organization and codifying into a platform. In my experience, what you need is a platform which enables GitOps as the default solution, as the default behavior for a platform capability, but can incorporate those imperatives, those API calls and manual processes as well. Yes, as a building block, but yes and, really.

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

Abby Bangser: I think we're going to finally get to the point where Kubernetes is that operating system that piece of infrastructure that we know that we can build on top of and build amazing things on top of, but we are starting to see some of its core kind of solidify in and become less interesting to the masses, right? We still have some amazing sysadmins in Linux making magic in that kernel, but it's not where the masses are talking. And I think we're starting to get there with the abstractions we're building on top of Kubernetes. And I think AI is going to accelerate us there. Some amazing projects are coming out about how AI is being built on the backbone of Kubernetes, and that's going to accelerate that move to kind of core infrastructure and higher level use cases.

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

Abby Bangser: What's next for me? Some sleep. But aside from that, I'm really excited to dive into some of the projects I've seen here at this event. As I mentioned, that one from Maintainer Summit around building CRD best practices into workflows. I want to get hands-on all the things that I've now got on my to-do list. Once I get a little bit of a nap, I'll be trying to hit that to-do list of all the projects I've seen.

Bart Farrell: How can people get in touch with you?

Abby Bangser: Best way is the CNCF Slack. If you're not in there already, please do get in there. If that isn't your vibe, I'm usually on LinkedIn as a really easy way to find me.

Bart Farrell: Bonus question. Biggest learnings from being a KubeCon chair?

Abby Bangser: Biggest learnings from being a KubeCon chair. First of all, that there's just so much amazing content and stories and people out in the community. We're at something like a 9% acceptance rate, 10% acceptance rate. It's just such a hard job to sift through these amazing stories and figure out what to share. I think the other learning is that my parents like to say that they did something right because both my brother and I think that the other is their favorite. Therefore they must've done something right. I think whenever I'm asking for opinions at KubeCon about have we done it right? Have you got the right schedule? I can have two people in the same conversation with me saying it was too much AI, not enough AI or too much of this and not enough of this. And that's really what we're trying to do is hit the middle as best we can so we can cover what people want to see. But it's a really hard job. I think those are schedule building is difficult, but really awesome to see it to come to life.

Podcast episodes mentioned in this interview

Subscribe to KubeFM Weekly

Get the latest Kubernetes videos delivered to your inbox every week.

or subscribe via