PurePerformance - 8 Factor Producers to Scale Platform Engineering in an AI-First world with Abby Bangser

Episode Date: May 25, 2026

In 2011 Heroku defined the 12 factor app to remove emerging bottlenecks as developers tried to scale their output when they moved from building monoliths to microservices. In Platform Engineer we see a repeating pattern called the "8 Factor Platform Producers".  AI allows engineering teams to speed up but they face bottlenecks as platform capabilities are not scaling with that demand as they are often depending on a central platform engineering team to be built and maintained.To learn more about 8 Factor Platform Producers we invited Abby Bangser,  Founding Principal Engineer at Syntasso and CNCF Ambassador. She gave an amazing talk at KubeCon in Amsterdam and today walks us through the need of defining both consumers and producers for platforms to eliminate any emerging bottlenecks in Platform Engineering and allow an organization to reap the benefit of speeding up with AILinks we discussed:Abby's LinkedIn: https://www.linkedin.com/in/abbybangser/Abby's Kubecon Keynote: https://www.youtube.com/watch?v=8t0-5cvvMGM&list=PLj6h78yzYM2MXCOWSN9CqqID6OOvF7wxL&index=3012 Factor Apps: https://12factor.net/CNCF Whitepaper: https://cloudnativeplatforms.com/whitepapers/platforms/

It's time for pure performance. Get your stopwatches ready. It's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson. It's great to be back and I have with me my co-host, Andy Grabner. Andy, I hope to be here for the next bunch of podcast recordings because as our listeners know, I've missed a whole bunch. You missed two or three.

This is very recently, though. You were missed. Yeah. I was listening to the shows I was missed. It was just like, oof, without me and my dumb interjections, I mean.

I tried to do my best to fake that I was really sorry, but... It's all good. Hey, obviously I did not get any more humorous while you were gone because obviously I missed

the back and forth between the two of us. But we are, what would stays? what stays the same as always is the great guests that we have. Yes. And it's repeating guests. Yes.

Guests that actually come back. Abby, Abby Bankser, is back with us for another episode. And just before I let you introduce herself, Abby, you did a phenomenal keynote at KubeConnambstam. It was called from Cloud Native Apps to Cloud Native platforms. Folks, if you're listening to this, you will definitely see the link to the YouTube recording in the podcast description. phenomenal talk, a lot of information that you packed into, I think, 12 or 15 minutes around something that I want to ask you later on, which is also something I think that Brian is interested in, and this is also what we are putting in the screenshot, bottlenecks.

It feels like we're just moving bottlenecks all the time, and now with AI, where does the bottleneck move and how can we make sure that we are not just building new bottlenecks, but actually solving the fundamental problems of really making software engineering teams more efficient. Now, this is a long introduction. Abby, welcome to the show for those people that don't know you, who are you? And then we'll just jump into your keynote. Absolutely. Thank you so much. I feel very honored to be able to come back for a second time and have a chat with you all. So I guess the whistle stop tour of who I am is, my name is Abby Bangzer. I live in London, but as you can hear from my accent, I was born and raised in the United States, moved over,

here about a decade ago. I work currently at a startup called Sintasso, where we are building enterprise-ready platforms, helping organizations build their enterprise platforms by giving them the tools to build self-service platforms. Before that, I was a platform engineer, an SRE, a DevOps engineer, but I really started my career as a QA. And so I think for my 15 or so, over 15 years of career, it's always been about how to optimize and support the software engineers around me and the software delivery around me in my organization. And I've always found that really interesting. And that is where I still am in platform engineering. Maybe that's why we also like to have you back all the time because you have the same background and Brian and myself.

We came also from the college side, performance engineering. I remember my first engineering job was for a software testing company. And I was actually, I had to start in the QA department to test a software testing product, which was really cool and taught me a lot of lessons. Ebby, in your presentation, you made some really interesting comments about the constraints that we have in our software delivery, right? And I think one of the,

and I took a lot of screenshots earlier when I watched through your presentation, you had a great analogy with the bicycles in Amsterdam. Kukon happened in Amsterdam, them and you said it's a great city of so many bicycles and you see more and more electric bikes. But the problem is if you only speed up the bikes, they still all have to wait either at the traffic light or in the city of many canals, they have to wait for the ferry to bring them to the other side. So we basically just, in the end, you don't commute faster, you're just faster at the next bottleneck. You also said agents can only move as fast as their platform.

And so I would really like to ask you, what have used to? seen or what do you recommend people in 26 where more and more people are trying to speed up with AI that they in the end don't realize that they're not at all faster than before because they have just missed some fundamentals in their delivery. To be fair, I think we're all figuring out where the bottlenecks are today. So I think there's going to be a lot of people who have theories and all of these could end up being the biggest bottleneck.

I think we're seeing a lot of really interesting work come out of the observability folks about how being able to validate your software is one of the biggest bottlenecks out there right now. And really doing that in production is where people are pushing that validation to you with the way that AI is working and things. So you're seeing a lot of the parts of software delivery go under strain right now. But at the end of the day, when we talk about things, like validation through observability. You are validating what?

You're validating that it is meeting expectations. What are those expectations? They tend to be things that your business has declared requirements, right? So they tend to be security requirements, performance requirements, usability requirements, things that are saying for software to go out under our brand, it needs to meet these expectations. And often that starts from lower down the stack. than what an end user might see.

So an end user will look at software and see a shopping cart or something on the browser end. But the software developers creating that are leaning on software packages, leaning on infrastructure, leaning on cloud providers, SaaS providers,

tools and integrations like stripe payments and other things like that. And all of those need to be customized for the business. They need to adhere to the rules and regulations of that business, whether that be cost validation, whether that be, you know, within the kind of API, the constraints of what they've paid for, so their contract with the providers, whether that be within constraints

of things like compliance for payment, PCI compliance or HIPAA, if you're in the health industry, all of these things fall under it. But they also are just really unique business things. For example, maybe your marketing team has a certain process by which a new feature gets released and gets hype and therefore benefit to the company. It doesn't have to always be security. It can be other processes in your business. They get wrapped around these tools we all use. And so I think that one of the biggest bottlenecks right now with AI is making sure that the tools that can write or that the, how do I put this?

It's not always the people. the writers of software, whether they be agents or people, the writers of software have access to the tools that meet the business requirements. And that is platforms, right? That's how you can get access to those tools. That's awesome. I think this is going to be one of the quotes

that we put out there for promoting this episode. In your personal life, how do you code? Yeah, on the code. Yeah. Yeah. Do you see productivity games? I do. To me, it is not a straight, linear. I write more lines of code with AI, therefore I am more productive. What I find is that the way my brain works and being able to explore ideas and challenge myself on what I should be building and how I should be building it faster is helping me create better solutions to the problems I have at hand, fast. So I can basically iterate through three ideas, much quicker, resulting in the fourth better idea that might have taken me in the past many months to get to. I can get there much quicker.

And obviously this is why I also liked that you mentioned. Observability is a big factor, obviously, to validate if the stuff that we are building meets our requirements, whether it's a business requirement, that's an end user requirement. And I think you also, if you can iterate faster, you can also obviously use observability to figure out, is this what I'm building? this idea one, two, three, where does it have problems? What is rejected by end users? You can do, I guess, some AP testing, some feature testing, and then quicker in the end gets to the feature that really people, that brings your business forward.

And I think some people are ready for that, right, in observability testing this in production. Other people are using observability or just their own sort of touch and feel to test before they release anything. So some people are still uncertain about what the cost value of putting something in front of users before you have gained confidence in it, what the cost value of that is. Because you can lose customer loyalty if you keep putting things in front of them that they're not happy with. But I've seen people test things like a new implementation and they want to see what the performance hit is. There you go.

Observability. Before production, you can run tests on two or three different. algorithms and see how that's going to respond. But you can also just get that look and feel feeling. You can put three different solutions in people's hands at your organization or with early testers who are friendly beta testers. Rather than asking them to think about it, watch them use it. And you can do that now with a lot quicker with AI, I believe.

In your presentation, you also bring some really good examples on, you know, how can we scale our systems in order to overcome bottlenecks? And you talked about, you know, vertical scaling. And after the slide open here, vertical scaling would mean if you're platform somewhere's the bottleneck, you just add more platform engineers. I think you made a joke. This is great for job security, but probably it won't really help. Then you talked about, well, the alternative to vertical scaling is horizontal scaling.

And you are talking about the concept of independent producers of platform capabilities. I believe later on in the presentation, you also talk about that when you think about a platform, I always talked about there's a platform engineering team and then there's only a consumer. That's the development team. But you then also brought in the concept that you actually need producers, right, as customers. They're producing new capabilities and added to the platform, like in a marketplace, then people can pick and choose. You also then had a reference to the 12-factor app.

and then I'll let you talk in a second, but you ended up with, you ended up with, I think it comes out of the platform engineering working group of the CNCF, the eight platform producer factors that define what a good producer citizen is like those white papers. For me, really cool stuff, folks, again,

links will be in the description, but in your words, can you explain this a little bit to us what does this mean the platform needs to now not only have an end user but also producers what is a good producer citizen can you give us an overview what that means

what I love is that you've proven that I made some amount of sense because you're able to summarize what I meant to say you've also proven I definitely stuffed a lot of context and information into a very short talk so thank you for the time to be able to talk a bit more about it

so yeah I think I heard kind of three key things that you laid out there was one is how do you even approach problems of scale? The second is is how is the problem of scale applying to platforms today? And then the third is what are we doing to try and support teams that are feeling that pressure? So maybe that's the three categories. And so we can break them down a little bit. So give chance for other people to have chats. So how do you even approach scale? I mean, I love it. You two are coming from performance background. I'm sitting here talking about how to approach scale. So I think I'll keep this the shortest to let you two chime in,

but we all know that there is not a right and a wrong way to deal with performance bottlenecks or to deal with scale. There are ways to add more power to the system. And the two categories of adding more power to a system is by giving power to a single unit in the system, making it more powerful, that one kind of component of the system, or making many components. components work together, thereby spreading the load. And that is vertical and horizontal scaling, which will be very familiar to people who work in Kubernetes or in other operational roles because we have vertical pod scaling and horizontal pod scaling,

where we say, give it more memory and CPU, vertically scale it, or create more pods that can share the load horizontally scale it. So that's sort of the first kind of thesis of what I'm building off of, of this idea that when you come across a problem, you need to categorize, is the problem here something that needs more horsepower in a single component or needs to have the load be spread more evenly across many components? How does that, I mean, as I say, you two are really the experts here on this, not me. So like, yeah, I mean, I couldn't have said it better.

No, it's a, I just try always to think. how does this translate to a platform? I mean, a platform in the end is also a bunch of, it's a softer product in the end, right? It has a bunch of tools that defines, that executes a process. And we're talking about an individual part of that process, whether it's your CI, your CD,

whether it's your testing. I guess if we consider this as individual components or services, some of them need to decide, well, I just give it a bigger instance and therefore I can get more stuff through or I need to horizontally scale it. So that means the way you build your platform, you also need to think about all of the individual components of your platform and also think about before, first of all, I think you need to figure out how do you measure if your component currently is the bottleneck? Because if you don't even know, then it's going to be hard to take an action. And then how do

do you deal with scaling? And I guess this is also where a content of an SLO would come in, right? Well, this is where we have to come back to what is our problem. Is our problem that our CI server doesn't have enough compute to run jobs? Or is it actually what we were talking about, like we were saying, the problem with cycling in Amsterdam is the problem that there's just too many bikes on the road. Do you need more width on the road to be able to get through? And what I was pointing at in my experiences of where AI is putting pressure on the system from a platform point of view is not that the AI needs more servers than we can provide, because actually we have access to elastic compute by using cloud providers.

Most organizations have pretty unlimited access to infrastructure at this stage. What they don't have access to is the automation and the support of providing that, those pieces of infrastructure in a compliant way without putting load on unscailable parts of the business. So human interaction or adding more automated solutions into their organization. So I believe that the biggest issue right now with scaling platforms isn't any one component being able to manage the load. It's actually access to the components that you need. So the limiter right now is the platform getting enough capabilities, we call them in the CNCF group, capabilities available to people that people can get test environments on demand. They can get CICD services on demand.

They can get new microservices on demand. They can get databases of all the types that they need on demand. Each of those capabilities is something that people need access to. I think, Brian, we were talking a bit about microservices. services there, weren't we? As a comparison. Brian, you're mute. I can't hear you.

Let's see. All right. My freaking, what time is it? My freaking sound card decided to stop. Sound card. How old do I sound? Okay, hold on. I was actually going to be saying there's two old man analogies I wanted to put to that, right?

So the first idea of scaling vertical or horizontal, right, thinking about it in terms of, is it a database or is it a service, right? Database you can't really scale vertically, I mean horizontally, right? got to be vertical and you're always limited by those connections and whatever, right? But you can't just be like, oh, we have a lot more activity. Let's throw three more databases at it, at least traditional databases

aren't going to work that way. Whereas if it's a service, chances are you can go the horizontal way, that might make more sense. But just obviously you're using, the only reason I'm bringing this up is you're using a lot more of these much more advanced models, right? But if you think about just a classic model

just brings it to simplest form. And then the other fun analogy I thought of the idea of the scaling, how the systems do that scaling, right? And the mechanism for that is if you go back to the old server rooms, right, oh, we need a new environment. I got to rack new servers, right? Like literally physically rack new servers,

and what's the time frame on that? And yeah, once we got VMs, a little bit faster, now we have Kubernetes and pods, but there's still that time piece there that this thing has to be done. And you have to have the mechanisms built in. if you don't have scaling groups, if you're not measuring for when we need to scale, right,

you're not going to be able to make a phone call to tell somebody to throw new servers in a rack and wire them all at jeep. Oh, man, that was painful times. But, you know, it's very, yeah, I go back and you mentioned the services thing, right? Your description of this stuff just, you know, brings these in a new light.

saying before we started the show how in your talk you mentioned we created microservices and the bottleneck that it was solving for, you know, from Andy and My's point of view, a lot more, which is still true, is you're able to scale your services so that when you need, you have more demand, you can bring them up and down, you can, since they're microservices, as you write new code, you don't have to wait for a much more complex, but you just need need a smaller test radius and if something goes down, sorry, blast radius. But the part that you mentioned in your keynote was you had all these new developers, right? Because as people hired more developers to get more productivity,

before microservices, they still got all bottlenecked into getting this all until like the monolith or semi-monolithic servers or applications, which still slowed the process down. So one of the, at least for me, and I don't know about for you, Andy, the unthought about goals or benefits of that whole microservice structure was getting it so that the human developer could get their stuff out because it scales in that way. And they work together, right? There's nothing about the fact that a human developer had more autonomy around a microservice

meant that when there was a performance concern from a infrastructure point of view, from a pure kind of RAM CPU, etc., you had more autonomy and ownership to be able to scale that as in when you needed to. They sort of go hand in hand with these things, and that's where, like, if we walk through the journey of, hey, there's some things that are being bottlenecked. Where are we feeling pain right now?

Like, how are we going, and then once we identify it, how are we going to tackle it with vertical or horizontal? If we look at the pain in the platform space, it's, I need access to this type of resource, this type of component and I can't get it unless I go and put a request into a ticketing system and wait until, you know, Jane is off holiday and is back and can sign off, you know, creating this thing or running that script or whatever, right? And so how are we going to solve that? Well, historically when, you know, Andy, you were describing how you're familiar with platforms.

It's how I'm familiar with platforms. It's how I built platforms for many years. You have consumers of resources and the platform is the resources. And you have one kind of team or maybe a small group of teams who are in charge of creating those resources. This would be similar to saying that Etsy can only grow as a marketplace for custom goods

by increasing the number of people they hire because Etsy employees have to create all the things Etsy's going to sell. Or Uber needs to hire all of the people who are going to drive cars around the world. That's just not a model that can scale past a certain point. And so instead, both of those platforms, and hopefully we're growing more and more internal developer platforms that do this, create a marketplace system where the platform engineers are not inherently the people

creating the services. Now, in smaller organizations, you tend to wear both hats, to be clear, but in a larger organization, the platform engineers are building the ecosystem that a experts to offer things as a service independently from them. So there's no more the database expert getting asked for something by a software dev, walking over to the platform team, saying, hey, platform team, I've been asked to be able to provide a key value store, and we don't have that right now. Can you create one? I can give you the specifications that are required.

And the platform team saying, sure, throw it on the backlog. I'll see you in six months when I have time. Instead, it's the platform team saying, sure, here's how you can contribute that. And the database person saying, I don't know how to write things in Goling. What are you saying, you crazy? And the platform team going, oh, good point. I should probably invest in making it possible for these experts to produce things in their own way and have ownership over their delivery mechanism, but do it still in an architecturally sound way.

So I know they're maybe not Kubernetes operators, writers themselves, but they should still care about some of the things that we care about, like item potency, so it can be repeatedly run and drift detection and fleet management, so we're not needing to scale the number of database experts as more databases are requested and all these kinds of things. And so that becomes then my job as a platform engineer to say, my end users, the software developers, want resources. So I need to figure out how to get them resources

that are compliant with the business as fast as possible. Maybe the answer isn't that I have to write them, though. The outcome is get them new resources that are compliant as fast as possible. Maybe if I empower others in my organization to do that, I get the outcome I want with a heck of a lot less gray hair and stress, right? Yeah, you know, it always comes, I haven't brought this topic up in a while, Andy, right?

But the, so many times when people talk about this stuff, I go back to the early days of Cloud Foundry. And they really just, at least conceptually, nailed it so much. I remember, I'm going to get it wrong, I know, but there was some sort of haiku around it. I was like, here's my code, run it, I don't care how. Right. But that's still the goal with this. And, you know, it's that scalability. you have everything in place, and who cares

if it's Cloud Foundry, what, but if you have everything in place and you have a really well-billed platform, you don't worry, this is what I need. Here, we need this new index, we need whatever it is, right? And it can just happen. I know Cloud Foundry, well, that's what my founders all come from that background. Yeah, and it shows, you know. Andy mentioned what made it possible, right?

Andy mentioned before when summarizing the talk, the 12-factor app. That's 12-factor apps, exactly. So, Abby, if I listen to all of the, this, the producer concept for me and listening to what you said earlier about the 12 Factor apps. So 12 Factor Apps for me really enabled and solved the problem when engineers were breaking down monoliths into microservices by having the kind of best practices or contract, whatever you want to call it, of the 12 Factor apps, if I'm an engineer and I was following those

rules, I was then able to build, deploy and scale my service. By following these rules, I made sure that I didn't have any bad impacts to other services, that my service could get scaled. So basically, I really was able to move that bottleneck, as we said, right, and really become independent, following a particular best practice. And now you mentioned with platforms, with your producer concept, something similar. kind of say that you have a core platform and you cannot have every expert in your platform engineering team. You cannot have a security expert, database expert, a testing expert. But what you

can do, you can provide a certain guideline. You call them the eight factors for platform engineering producers. And that means if those producers are following your guidelines, then they can basically produce a skill, a capability to your platform that will then, then, you know, be able to be consumed again by the end users, by the developers. But this is really the way you also make sure that your platform can scale and that all of these capabilities really, for whatever reason, the second time it didn't work. Sorry. No, I love it.

So what I think I hear you saying is that the 12-factor app created this kind of contract between the people who wanted to run things on a platform and the people who were running the platform. People in the platform, the history behind the 12-factor app is that Heroku was like, I am sick of having random things thrown over the wall at me and being told, run it. So instead, what I'd like is for those things

to be thrown at me in a way that I can support them. Hey, if you all write your software in a way that I can support it, I is the platform, I is Heroku, Cloud Foundry, etc. If you write it in a way that I can run it, what you get is you get fast time to production, you get stable services in production, you get value. And you know what? I'm not going to meddle with anything other than the contract that we have. You can write it in whatever language you want.

You can write it in as big or small of the software. You can write it as a nonprofit organization or a for-profit organization, a front end app, a back end app, I don't care. It could be absolute trash. As long as it has, follows my contract, I know I can run it for you. And that's what allowed for autonomy of the application developers, but also stability and speed and scale by the platform that was running it. And so if what we're saying is we want these producers to be able to join in on this,

to be autonomous, to be able to move fast, to be able to move stable, we need to figure out what is the contract that says, I don't care what you're offering on my platform. You could be offering AI skills, you could be offering virtual machines, you could be offering mainframes minutes for all I care, right? Whatever you want to offer you can offer. You can write it in bash, Python, Go,

Pallumi, Terraform, CloudForm. Don't care. What I care about is that you meet the contract of what it means to have an autonomous service that I know I can support at scale within the organization. And that's where those factors come from. They don't talk about the platform. They talk about the capability providers

who want to put things through the platform onto the platform. And just to read out a couple of these eight factors produced by an API, consumed by an API, self-managed, value stream, reconcile state, implementation, agnostic, and so on and so forth. So folks, the link to that white paper that explains all of this will be part of the podcast description. And we have Brian Beck who unfortunately, the first time power outage during a podcast recording. Yeah, it was the whole neighborhood.

Like I went outside to try to like, and I like, all my neighbors are coming out and they're like, happy hour time? We have more platform engineering to talk about, Brian. Yes. And I heard about this eight factor a bit. So yeah, I'll have to go back. Fortunately, Andy, thank you for recording it in the meantime. And I heard Cloud Foundry still being talked about. So yeah, it keeps coming back.

Anyway, glad to be back. And now we're running low on time. So let's stop focusing on me and let's get back to some of the more fun stuff. Yeah, I think the factors are getting interesting. We're actually, it was such a popular idea. We had over 30 people jump on and share their experiences as these were starting to be thought about in public. And so we've had so many people already want to share their experiences. It's actually become an official initiative within the platform technical community group,

platform engineering technical community group within the CNCF. And so that work is kicking off in a week. We've already selected a group of people that have all applied to spend time crafting this into a more powerful, more readable, more consumable document. We've got some people on there that are really excited about adding some. diagrams and pictures to make things more visual and I think it's going to come out great. So we're hoping to have this as a version, a pre-release version available sometime late August-ish, or in August maybe for community review and hopefully a version one for wider dispersal in sort of the early kind of September timelines-ish.

So well in time for KubeCon North America is the goal, basically. Perfect. And that's going to be in Salt Lake City in November. And I think, so I know for the listeners, it's probably going to be a little bit of a shorter episode because while there was a little bit of a power outage, we didn't record through, we waited, but we had a lot of interesting discussions

while we were not recording. And so, Abby, I know you will have a lot of, we have a lot of interesting talks around also the future, looking even further ahead. I brought up some crazy ideas about do we need to rethink platform engineering in total. Now with AI, do we need to build an AI native platform? Do we need to rethink the way we write and build and deploy software? Talked about Asian skills. But I think, Abby, if you're okay with it, we'll have you back for an encore. And we talk about this

in the following episode. Absolutely fine. Anytime I get to spend with you two, I'm enjoying. So I'm grateful for the time and I'd appreciate the chat. Awesome. A three-time guest. We used to keep track of that a lot. In the early days, we used to have several repeat guests. Not that we don't want repeat guests, but we just have so many people we want on. But I think we had like five or six returns. Mark Tomlinson, we mentioned him earlier in the break.

Yeah. But, you know, Abby, you can start becoming one of those high-volume repeat guests. Maybe I'll suggest someone else from the working group. or I think I'm hoping to have some end user stories up on stage with me in Salt Lake City. So maybe one of them could be a good guess. So similar topics, but maybe a different voice would be a good way to not bore all your listeners away. All right, Brian. I think it's time to close.

All right. Let's close. Any final thoughts from anybody? Watch that recording from YouTube, from Abby's keynote. That I can highly recommend. Yes, and if you watch it at 0.75 speed, it will slow it down for all the information, and it'll make Abby sound like she's drunk,

because that's always still a fun thing to do with YouTube videos, or you do the 0.75 speed. Thank you everyone for listening. Sorry about my power outage, and I can't wait to have you back on, Abby, and thank you for everyone listening, and see I'm all fluster now. Thanks, everybody.

I guess that's it. See your next episode. Bye-bye. Thanks, all, bye.