PurePerformance - Platform Democracy NOW! How to keep your Platform Promise with Daniel Bryant

Episode Date: July 14, 2025

More than 50% of platform engineering leads don't know how to measure the impact of their platform! Many platform projects fall into common anti-pattern traps that make the platform look great on Day 1 but fail to scale and excite on Day 2!Daniel Bryant - who's profile tagline is "Helping you build better platforms" - is sharing his thoughts on how to measure the value of your platform, how to avoid common anti-patterns and why he believes that the future of platform engineering is in Platform Democracy!And of course, we wrap everything up with a discussion around the impact of Agentic AI towards platform engineering. So - tune in! Here the links we discussedDaniel's LinkedIn Profile: https://www.linkedin.com/in/danielbryantuk/Platform Engineering Book for Technical Product Leaders: https://www.amazon.de/Platform-Engineering-Technical-Product-Leaders/dp/1098153642/ref=asc_df_1098153642Platform Engineering Day Talk: https://www.syntasso.io/post/syntasso-at-platengday-london-presentation-recapKratix Website: https://www.kratix.io/Ai-Driven Platform Engineering Blog: https://www.syntasso.io/post/what-we-learned-building-a-prototype-ai-driven-dev-interface-for-kratixPlatform Democracy: https://www.syntasso.io/post/platform-democracy-rethinking-who-builds-and-consumes-your-internal-platformPlatform Anti Patterns: https://www.syntasso.io/post/platform-building-antipatterns-slow-low-and-just-for-showSlide Deck on Platform Engineering for Devs and Architects: https://speakerdeck.com/danielbryantuk/platform-engineering-for-software-developers-and-architects-redux 

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 and as always I have with me my co-host Andy Grabner. He said we're going to try to be funny so I'm going to try to not be. Yeah, and you nailed it. You nailed it. Thank you. Thank you. Yeah. Thank you so much. That was the most unenthusiastic intro. You know, short Thank you. Thank you. Yeah.

Thank you so much. That was the most unenthusiastic intro. I know, but... Short side note, when I was going through files and organizing the peer performance directories, and I turned on episode one to hear what it sounded like. Oh, shit. It was me interviewing you, I think, probably about... I forget exactly what about, because I didn't listen to the whole thing,

but you were on your headset, you didn't have the mic yet, and it was, yeah, I was like, oh, we should probably re-air episode one sometime. So this is episode 238 now. So yeah, it's been a long time, I'm just letting our guests know that, and our listeners, but yeah. It's been a long time. never gets boring, and it is platform engineering. I know we had plenty of discussions recently,

also just the previous episode, which we have actually recorded yesterday from the day of the recording, was around platform engineering and how we can measure successful platform engineering teams. We talked about the DX Core for Metrics. So, Daniel, just for you to know, and now this is your cue for joining us on our little podcast here. Daniel, Brian, thank you so much for joining us. If I read out from your LinkedIn page, helping you build better platforms, you are a speaker at various conferences.

You are co-author of CD in Java and Mastering API Architecture. Pretty cool. Daniel, thank you so much for being here. What else do people need to know about you? Thanks, Andy. Yeah, thanks, Brian. in Java and mastering API architecture. Daniel, thank you so much for being here. What else do people need to know about you? Daniel Thanks, Andy. Yeah, thanks, Brian. It's great to write a book. Every stage of my career, I need to write a book.

So that's coming next. But thank you for the invite. And 238 episodes, that is incredible. So I'm super happy to be included as one of those guests. I had full hair when we started. I was no less gray. I've been less gray. I've been gray forever.

But it was 10 years ago, wasn't it? That was fun. We enjoy the podcast because we learn a lot from our guests. Daniel, when we met at KubeCon in London, we also had your colleague in our joint friend, Abby Bankser, on a recent podcast last year. I'm in the office as we're recording in London, just shy of London Bridge and the Shard as well. And we did like a big meeting today, like a company meeting with Sintasso when working.

And Abby and I were hanging out, we had lunch together kind of thing. So Abby's awesome. Abby's a force of nature, like she's been doing so much good in the platform engineering world, as I'm sure you learned last time, contributing to the platform maturity model, like helping the app delivery group and platforms group. Like Abby is just one of those folks that you learned last time, on the podcast. 10x efficiency of your organization. in getting your perspective, that it's shocking the amount of folks don't measure their platform. And if you don't measure, how do you ever know you're actually providing value? How do you know you're making a difference? So I always like caveat those kinds of conversations

because yeah, we can all measure stuff, but you got to tie that measurement back to your goal. What are you actually trying to do with your platform? Is it go faster, reduce risk, increase scalability, all these kinds of good things? And with that in mind, what I would also say is an amazing book that really shaped my thinking. I only read it about six months ago. all these kind of good things. people. up amazing. If you're a manager looking to understand platforms, it's a real good jump off. But as an IC, as a person that's doing the code, it's just a really good framing

for the kind of language you're probably going to have to use when talking to your peers, managers, these kinds of things. Camille and Ian really made me think about, a lot of us, we know the impact metrics and the guardrail metrics, particularly for things like DORA. Do you know what I mean? An impact metric is lead time to delivery, lead time to impact. And then change fail percentage and the guardrail metrics, So I really like that framing. And then Camille and Ian also said about product health metrics. And I think this is kind of a lot of folks instantly jump through when they're talking about platforms. You're thinking product health is like the adoption rate of the platform,

or the time to 10th pull request of an engineer onto the platform, those kind of good things. But I think that that book really helped me build a sort of mental model that when I'm building a platform, what kind of metrics do I want to capture and how does that move me forward? Super interesting, thank you so much. I looked up the book and folks we will add the link to that book also it's called Platform Engineering a Guide for Technical Product and People Leaders. Now talking about books I don't and you have product in people leaders. Now, talking about books, we also did a little bit of a book signing

of our book, Platform Engineering for Architects. I hope on one of those long haul flights to the next KubeCon maybe, you will have also time to read through our book. Yes, it's been awesome, Andy. Max tipped me off to it because you mentioned Kratix in the book and I was trying to max it a bunch and that was fantastic. There's so much to learn about platform engineering, right? If you're starting out, getting that book is a great jumping off point. I think people get a bit overwhelmed when they're coming on to building platforms for the first time. So that book is a great jumping off point. Do you know what I mean? Because I think people get a bit overwhelmed when they're coming on to building platforms for the first time.

So that book is a great starting point in terms of understanding all your options. So plus one to the book for me. For me, coming back to the earlier thing you said, and that's the shocking reality, right? Less than half of the people that you are shocking reality, right? tell me what you see. are technical folks, are engineers. successful with it. product owners, product managers. And definitely my first time I was building platforms probably 10 years ago, I wasn't working with a team like that. And to your point, the infrastructure engineers were incredible people.

I learned so much from them, from my puppet and chef back in the day. But to your point, they did get interaction with the customers, but the folks who've been historically racking and stacking or then doing infrastructure as code had no product experience. They taught me a whole bunch about infrastructure as code and how performance, in terms of the metal, performs, things that I learned a ton. and product thinking. Is this actually addressing other people's needs? Is this solution going to be scalable? What's the day two story like, right?

In terms of how do we upgrade this thing? How do we maintain it going forward? If I leave the company, who's going to maintain it? All those kind of good things. So I think that product experience, even as an app dev, is really useful. And I've got to share with my colleague Kat Morris. Kat did a great talk with Stefan from DKB

at Platte Eng Day, same event we caught up. And they literally did a product management or product ownership, I think it was called, for engineers, for platform engineers in particular. So folks go to the Platte Eng Day website, they can find that talk, and Kat and Stefan, both product people, both technical people, talked about exactly what you said, Andy,

the benefits of investing a bit of time in learning about product stuff. I always advise folks I mentor, more junior folks, and more folks from the infrastructure background, learn about product stuff. And Kat and Stefan's video is a really good jumping off point. So you said from Platform Engineering Con last year? Platform Engineering Day, yeah. It was like a colo day on the Tuesday,

and I think we met on the Wednesday and Thursday. I'll ping the link afterwards, that product thing ties directly into something I saw, What do they need? Are they going to be adopting it? All these kind of things, right? But you have to find out from them what do they need? What's going to be useful? Because you can build any platform, but as you said, if no one's using it, it could be the best platform in the world, but you just spent a bunch of time. But that also goes back into, you mentioned the idea of how to measure these things. And I think, especially for an engineer, it's very tempting to go back to standard types of metrics

of like, is it up? Are we having failures? Is it responding? It's like, well, those matter, but you can infer that that's working if you're looking at is it being adopted? Are people pushing stuff through it? Taking a look at the age-old battle between, I want to look at my low-level metrics as opposed to

the product view of are customers using it? between I want to look at my low-level metrics but that's where all those things come in. talking about DOR and the guardrail that, Brian, to your point. Definitely think of your company goals. Why are we building a platform as a company? What are our goals as a dev team, as a platform team? Yeah, thinking about some of the space frameworks like satisfaction, performance, and I'm going to mangle the rest of the acronyms, I guess, but it's a really good framework. If anything, it can be hard to get your head around because it is so much more flexible

than say Dora, where you've literally given four or five metrics depending on what version of the framework you're used to. But the space framework is a really nice way to your point once you sort of pop the hood, once you're looking under the hood so to speak of the car, you really can get to the nitty gritty if you want. And I think Dr. Nicole Forsgren, Abby Noda, amazing people in that space have really done a lot of good thinking and I'm happy to stand on their shoulders as we say, right? And learn from them. The second thing you shared with us was around anti-patterns. I really liked also the title of the blog post you wrote in March this year.

It was called Platform Building Anti-Patterns, Slow, Low, and just for show. That's right. And if I go through it, there are a couple of things that stick out, but one of them I want to start with, and you call it template as a service. Yeah, yeah, yeah. Unable to scale past day one,

and the reason why this is interesting, when I do my demos around platform engineering, it is actually often Yeah, sure thing I do. I don't know if I put it in the blog, but we often talk about this path, Antipanton, as a puppy for Christmas. So like a template as a service. When I was a developer, it made sense. I want to get started and I'm given a bundle of like code, maybe a Java dev, right? I'm given a Maven home and some Java directories structure, and maybe I'll give them some Terraform code or something to get me started. And that's great on day one, just as like when you get a puppy, right? Day one,

everyone loves a puppy. Day two, when that puppy's made a mess in the corner, not so good. Day three, you've got to go and walk the puppy, and you've got to walk the puppy every day. It's the same with templates as a service. Day one, super happy, get me started, amazing. that dependency. You've got to make sure everyone, these 100 teams now, are upgraded. And the snag is, like in a big org, you sometimes just lose visibility of who's got that template. Who is even using that template? And if you can find them, how do you convince them to upgrade? Often you think, oh, I'll just do automated pull requests, like GitHub bot, right? But people have customized that template, and then you can't do an exact pull request.

And this is why we say the puppy for Christmas, great on the day one. On the day two, templates can cause more trouble than they're ultimately worth. And I think we talk a lot at, you know, Syntaxa and Critics, is you really want to have these templates being dynamic, being able to, one click of a button, be able to upgrade all your Postgreses or fix all the libraries, these things. And we see so many times that people get really excited, particularly around, say, a portal and a pipeline. They go, I've got some backstage,

I've got some GitHub actions or something, and you can get very far on that on day one, but then they get really disheartened when they get vulnerabilities, issues, they want to upgrade on masks. Day two story we talk about, and that's where we see this anti-battery, anti-intensive, like the templates.

Unless you've got some way to dynamically update them, they become stale very quickly. And I know, obviously, you work for Kratix, or for Syntasso, and Kratix is your platform. Can you quickly fill us in how you solve this problem with Kratix? Yeah, sure thing Andy. So with Kratix, the core concept is promises. Promises are really just an API onto your platform. So the Kubernetes world, they're effectively CRDs, customer resources.

And you can, as a platform engineer, expose an API to your platform users and you can say, hey database, I simply want a name, a size, a region, these kind of things. Very simple API for developers to get started. You can deploy that via CLI, via backstage, via some other mechanism. But the critical thing that's been built into Kratix is this notion of workflows. So it's kind of a little bit like GitOps, if you're familiar with GitOps, but kind of at the platform layer. And it's sort of one level of abstraction over Kubernetes.

You can actually, with Kratix, consistently reconcile the platform components. We might get on in a minute to talk about golden bricks and golden paths, because that's where it kind of makes a bit more sense as well. But fundamentally, Kratix, the promises of the APIs, they're APIs onto your platform services, databases, maybe like a Java build pack or Africa service, that kind of thing. And as platform engineers, you define a series of workflows, might be say provisioning the actual infrastructure, generating S-bombs, running a series of security tests, these kind of things. And because it's kind of like a live system

that's continually reconciled, when you are fixing a zero-day vulnerability, all the things will get updated. That makes sense. Because we have this notion of promises, but where the sort of bricks analogy, a Lego bricks analogy comes in, you can build platform components

on sort of promises on promises. We call this compound promises. So like, you know, you have a database, a Java service, and some other things, well that might become in the banking world a know your customer service. And then that service itself becomes part of a dependency on another thing.

So it's kind of like, it can get quite complicated, the stacks that you have in your platform, but Kratix always has links to all of the different promises, the different components of your platform. So at any moment, you can say, upgrade all the promises that are Postgres, and it will happen. Rather than these templates that are kind of,

de-connected, or not connected. Soon as you put a template out into the wild, it's gone. Unless the team is reporting back into you, hey, I'm using your template, that kind of thing. You know what I mean? Those are not connected. As soon as you put a template out into the wild, it's gone. Unless the team is reporting back into you, hey, I'm using your template, that kind of thing. Crattics tries to sort of balance the centralization versus the decentralization, but it maintains a link to all the things being deployed. And it makes that day two story so much better.

Can you quickly help me understand, if it sounds what you've explained with those promises, the example that you walked through, there's some analogies to cross-plane and compositions. I get this question all the time. You are ahead of that. resource definitions, there's QGEN stack in this space as well. We all operate at different parts of the stack, is the way I define it. For me, Crossplane is an amazing infrastructure as code tool. Love it.

If you're using Kubernetes and you're not in the hashigor world or a particular hyperscaler world, Crossplane is a fantastic way to define your infrastructure in things you know and love, custom resources. Crossplane is a fantastic way to define your infrastructure work together, we have a lot of customers that do use Crossplane with Kratics. So effectively, Kratics, they define their platform components in Kratics, and then it calls out to Crossplane to provision those things. But with the work they're doing on Crossplane 2 and the compositions, the gap between, say, Kratics and Crossplane is narrowing a little bit. You can now put arbitrary logic into Cross-plane compositions. What I've heard from folks,

I was chatting to a bunch of very interesting people at KubeCon, I think the testability story of Kratix is a bit nicer in terms of the way we define the workflows, the inputs, outputs, very testable, and the sort of the day two stories around having these composable promises is a bit nicer. But just to be clear, like happy to debate, I'm biased, right, because I work for Sentaso having these composable promises is a bit nicer. Cloud native community that obviously people can, into any battle.

websites, building better platforms. the templates that you wish more people would be aware of when they start down their journey of building platforms? I do think baking in compliance and workflows early on, Andy, is a key thing. We see a lot of our customers come to us for this as well. It's very easy to provision the infrastructure and deploy an application, but how do you make it compliant to your company's rules and regulations? So we work with a whole lot of financial service companies, whole lot of insurance companies,

medtech, highly regulated industries. And what we find is a lot of folks sort of might jump on a traditional pass to spin up things very fast, but then IT gets wind of it and they're like, hey, is that deployment over there compliant with the org? And they've sort of traded off the speed and the safety, things very fast, but then IT gets wind of it. And they're like, hey, is that deployment over there compliant with the org? And they've sort of traded off the speed and the safety, which is a bit of an anti-pattern, right?

So I think you have to make sure your platform offers that balance of speed, safety, and scalability and makes it easy to do the right thing as a developer. So I think what I hear a lot now is like shifting down is better. So shifting some of that responsibility into the platform. So developers, by default, if you spin up a new service, you get that compliance baked in. You get that DRBC, the disaster recovery, baked in. You get observability baked in. These are critical things, right? But I think make it easy to do the right thing and have that on your thinking point from day one. I see far too many platforms that go super fast,

we're just doing the templates, just getting the day one story good. And then when the rest of the organization catches up and says, I've got to now retrofit all that stuff instead of shifting left, is expanding to the left? Like your example with security and observability, these are typically good practices that you do in production. If you do it in production, the question is if you can expand to the left, how can the people that are taking care of observability and security and compliance in production, expand their tools and best practices left where it's mandatory, right? Cool. good blog post. You've got to be careful with politics these days. It's a nice analogy.

What we see a lot in Centasso, and we've already talked about one thing, is fleet management. Fleet management is the ability to manage all your services on the day two. We talked about that just a moment ago. like Cratic really focuses on making that ability to manage your platform as a fleet. No matter how small it is, no matter how big it is, you're managing as a fleet. I think that's not controversial. A lot of folks are like, no, totally makes sense. I mean, I have quite a large IT estate, this is a fleet.

But the sort of second part to that, when your company gets to a certain size, you have to make it democratic in that you have to enable other teams to contribute to the platform. So almost like Dov telling what we just said previously, that you have to make it democratic and the platform team's like, well, we don't support that, no. Do you know what I mean? But if you can imagine that a database team in like,

we work with these big banks, they have like literally database teams, networking teams, security teams. If you can enable them, those teams, to contribute to the platform, to democratize the contribution, and critically have them owning their components going forward,

everything just scales so much better. So, I mean, rather than one department, platform engineering team, being overloaded with requests or having to, like, think about all the things every day, if you can push out some of that responsibility, like we do in democracy, right? It's not a perfect system, democracy, but in general, we sort of push around various parts of responsibility. And that's what Colin, like, my boss, talks about a lot in terms of once you get to a certain scale, like if you're like a 10 person dev team, you're probably up to like 50, maybe

even 100, it's not super important. Fleet management is really important for you. You want to be able to like manage your estate as a fleet, but it's when you get past that sort of Dunbar's number, 150, like is a famous number we talk about a lot, then the complexity of your team, of your system just goes up. Then you need to think about how do I enable contributions? And this is fundamentally,

there was a few others we bumped into, who else was chatting about it? And we're like, hey, we like this term platform democracy. And if I can relate to that and that I enable other folks to contribute to the platform, I enable producers and consumers to meet contribute to the platform. I enable producers and consumers to meet.

The platform almost becomes a marketplace. Do you know what I mean? In terms of you have these producers, a bit like an eBay or an Etsy or that kind of thing. If you get that, a certain size org, that's so much more sustainable than just one platform team doing everything. Were you clapping out loud? consumer engineer can actually contribute. Because if you have to then expand or contribute to the platform by having to write complex Go code or whatever,

I'm just making something up. Is it any best practices there? Yeah, I mean, shameless plug, Andy. the Promise API, and we typically do a lot of workshops what's our best practices, these kind of things. So as with all things, there's a technical side and there's a social side. So we say platforms are inherently kind of socio-technical things. So I think if you can agree as a company, this is technically how you contribute.

And if you're not using Cratic, you can do a pull request or request for comments, that kind of approach from the technical side. But then you need some kind of contract, at pull requests or requests for comments, but then you need some kind of contract, some kind of API, which enables those socio-conversations. Like, I am wanting this, or I am building this to expose to others. The API has to be documented, for example. If you as a developer want to spin up that know your customer service early on,

you've got to have some way for other people to discover that service. Like, oh, Andy's written a know your customer service. I was going to do the same thing. I'll just use his. Do you know what I mean? And then you've got to expose in the API all the parameters, all the properties that you'll need to actually instantiate

the thing. There is a bunch of dynamics, but you need to have something that cues the conversation. If you've got the API defined, you can then put that in a service catalog. People can discover it. They can understand self-serve. They can understand how they're going to use that. And that is a real key enabler for scaling out these contributions.

Now, it is mid of 2025, and obviously there is no way around bringing up the next topic for me, because what you just explained to me sounds very much like I could do this with agentic AI and basically these extensions to the platform, this marketplace could be MCP servers that are providing an API to certain tasks and then I, as an engineer, could just talk with my AI agent, client or whatever it is and say, hey, I need to do XYZ, you go figure out how this works

I mean, I'm sure this topic must have come up in your conversations. chatting saying, hey, I need a Redis. And it was like, what kind of Redis do you like? And going through. And then one of my other colleagues, Jake, has been using Gemini Vertex to automatically generate promises, generate terraform code and do these things. So I'll be very candid though, it's early days from our side, but we're getting feedback from the community that people want to take advantage of AI in particular for migration projects. As Stephanie said to me and Shane, especially building out various platform components. From our experiments, like Jake has definitely said to me, and Shane, you still need to be doing a heck of a lot of checking.

There was hallucinations. I think Shane even put that in his blog post. It showed promise, excuse the pun, and we were really excited. We put it out to a few customers and said, Hey, what are you thinking? It's an interesting mix in that some customers are like, for AI, I'm not sure how to spend it. Come on, Bob, with some ideas. A platform seems like a very logical choice where many different types of people are interacting with the thing.

You have platform engineers, you have QA folks, developers, you have managers. If you can all converse in that human-like language and have agents in the backend doing stuff, I think it's a good idea. There will be so many links on this one. And I think that this came up actually A lot of great stuff though. In our previous podcast, a little bit with the AI, because Andy's a machine. Everyone from his country is a machine.

Now he's Austrian, so he's Arnold Schwarzenegger, Terminator. I used to play Arnold sound bites in between. I'm not a massive fan. One of the things about adoption and usage, which is what we were talking about with building these platforms, is if I have to go out now and besides staying on top of all the things I need to stay on top of to do my job, learning the latest and greatest on my job, and learn the ins and outs on how to use this platform, that becomes a roadblock.

And I really do see an exciting future. There's all this talk, AI this, it's going to take away, it's going to do all these things, but I think one of the really attractive ones is like, I don't need to learn the ins and outs of this tool, at least until I need to dive into it. If I can just interface, ins and outs of this tool, at least until I need to dive into it. If I can just interface and 90% of the time it's doing exactly what I need,

then fantastic, right? It's just going to make things so much quicker. is Java Dev and I've done a whole lot of Java. And I've written my fair share of Go or whatever, but I do find now when I'm playing around with Go, I know the rough design patterns, I know what I want to accomplish, but I don't know the syntax or I don't know the idioms of the language. But to your point, I can literally be chatting away in VS Code

and I'm doing sort of the big picture outline stuff and it's filling in the gaps which used to take me freaking ages on Stack Overflow to figure out. I can see the same thing with platforms, right? It totally makes sense. Now, one more thought on this, and we may, Brian, have covered this the other day when we talked about MCPs with...

Now I remember the name. Deshaun? No, we had a talk about MCPs from Tellus, one of our dear friends from Tellus, I'm just currently blanking. Tell us who it was. Yeah, tell us who it was, exactly. Dana Harrison, because we talked about MCPs.

Coming back to a software engineering question now, so let's assume more and more people will be able Coming back to a software engineering question now, let's assume more and more people will be able to use all these systems because they can now interact with those systems through natural language and they don't have to learn the ins and outs, which means, as more and more people using it through natural language, these AI agents will go off and make many, many different API calls to all of these different tools. Have you seen that we need to get ready for an influx in API calls

that we need to change and definitely double down on better scalable APIs? Because in the end, it's no longer just be the experts that use a particular tool, but it's going to be the AI agent that are using the APIs of those tools to make it easier accessible to everyone else. So I fear that if we're not doing a good job, systems. Yeah, interesting question, Andy. And I think all the good design principles and all the dangers that are lurking with existing APIs apply to MCP. But to your point that the scale of which things can go wrong is magnified.

Do you know what I mean? As in we can always make massive amounts of calls against an API, but what's the risk profile to your business now? APIs have become more and more business critical. So I just think really from what I'm seeing, reading some great blogs by Christian Posta, profile to your business now. APIs in the platform world. But I think a lot of platforms, they're internally focused. So you can put much more strict guardrails on who can call the platform, what they can do with it.

But when you've got a public facing API, you can have denial of service, you can have people sending trash your way, just trying to hack it, all these kind of things. And I think that will only get worse the more ways you can call an API and the veracity. Like, then agents can in theory just, you know, scour the internet all day 24-7, constantly going at it.

So I think all the things we've been talking about for years in terms of security, rate limiting, DDoS protection, observability is a critical one. Again, if you don't observe the thing, you don't know what's going on at all. Like it just becomes more and more important. And I think the scale at the impact is just getting bigger with agents. Yeah. And also because agents are, you know, non-deterministic. I think the scale at the impact is just getting bigger with agents. And also because agents are non-deterministic.

Everything we do when we call APIs, it is more deterministic. That means we can test for it and the same input will produce the same number of calls to the backend system. But this will change because the same prompt can today produce a different number of API calls to the backend than tomorrow. Yeah, exactly. I do hope that a lot of smart people that spend more time on all of these challenges so that AI agents don't go rogue and do something bad.

Probably a lot of the same kind of anti-patterns. It even sounded like you were talking about an N plus one API call issue, which exists today, but the big, are people thinking about it in this context. If we talk about shift left, shifting our brains to shift API, maybe, to really start baking that stuff in, baking that quality, baking all the security checks, all that stuff into that, and getting it done now, Please start doing that. Hey, Daniel, thank you so much for giving us the time

to talk about a topic that is very dear to your heart because you're working for a company that is trying to make the life of platform engineers better. Not just platform engineers, but for everybody that wants to contribute to platforms. Thanks for the democratizing platform keyword now that we have. not just platform engineers, but for everybody that wants to contribute to platforms. Did we miss anything?

Any final thoughts from your side to our listeners? No, thank about platforms. The reason I do enjoy sort of like sharing these ideas and it's always great to chat with folks like yourselves, but getting that feedback from you, from the community is how I learn. So please folks do reach out to me if you've got any questions, you want to get involved with Crattics, you want to get involved with the other things I'm working on as well. I love that feedback on those questions, so keep them coming. Cool.

Going to get a bunch of AI bots reaching out to you now. I love that feedback on those questions, so keep them coming. Going to get a bunch of AI bots reaching out to you now. Humans only. I'm very much looking forward. I'm sure our paths cross again later this year. I'm sure you will be in Atlanta for QtCon. for yourselves and your colleagues for coming along and then KubeCon and we'll definitely do Plat-Eng Day as part of KubeCon. So I encourage folks listeners, the Colo days, I know there's observability days,

there's platform days, security days, many interesting days at KubeCon are where a lot of very interesting people meet. So I do encourage you listeners to come along and check that out and come and say hi. I'll be on the Sintasso booth or doing a talk hopefully. I'd love to meet you and say hi. Cool.

Awesome. Brian, there was episode 200 something something. 238. Cool. It's funny, Daniel, in the beginning you were talking about how enthusiastic, was it Abby? Yeah, my colleague Abby. You're very enthusiastic as well. It must be something in the water, I'm a critic. We're all very similar, Brian. We all genuinely care about platforms to some degree in terms of whether we've got a software engineering background,

an architecture, a platform, a product owner background. I can tell you both do as well. We spend eight hours a day at our job. If you don't enjoy it, I know some folks have got to do what they've got to do, but I'm very privileged to enjoy my job. That makes it so much easier, like for yourselves, I'm sure the same, so much easier to be enthusiastic. Right? Exactly. Anyway, thank you so much for sharing. I know our last podcast was a similar topic. I don't think these get old though.

I think there's so much to uncover and every conversation has a different angle, different aspects to it And you know there's gonna be a lot of platform in the future so yes, it's it's it's very relevant So hopefully our our listeners are enjoying this all thank you everybody for tuning in once again tuning in right that's an old radio All the old words we say from I'm gonna tape it right anyhow All the old words we say from, I'm going to tape it, right? Anyhow, I'm going to digitally digitize this audio. Anyway, I'm being stupid now. Let me wrap this up.

Thank you everybody. Thank you, Daniel. Thank you, Andy, as always for making this possible. Bye bye. Bye. Bye. Bye. Bye.

Bye. Bye. Bye. Bye.