[00:00:00] Chapter 1: Opening and Code RED moment
Kasper Borg Nissen: Hello and welcome to Code RED. I'm Kasper Borg Nissen, principal developer advocate at Dash0 and co-host of the Code RED podcast. Here we explore platform engineering, observability, and the people shaping how modern software systems are built and operated. Today's episode is about a shift that sounds subtle, but fundamentally changes how internal platforms succeed or fail. Treating the platform as a product, I'm really happy to be joined by Abby Bangser. Abby is a founding principal engineer at Syntasso, a Cncf ambassador, and a co-chair of KubeCon Cloudnativecon. She's also the co-author of the O'Reilly Report platform as a product. This is a person that's been thinking deeply about how platforms don't just serve the teams that use them, but also the teams that build on top of them and what it really takes to make that work at scale. Abby, thank you so much for joining me today.
Abby Bangser: Oh, thank you so much for having me. Kasper. I remember sitting and watching your talks about observability and platform engineering and, and the thin line between them at KubeCon when you were co-chair. So it's definitely been inspiring to be able to follow in your footsteps.
Kasper Borg Nissen: Awesome. Thank you. So before we dive into all of this, let's start with our traditional Code RED opener. What has been your biggest Code RED moment? An incident, a platform failure, or maybe a hard lesson that sort of helped shape how you think about platforms today?
Abby Bangser: Yeah, it's hard because with Code RED, I always want to think about something that moves very quickly, right? That 3 a.m. wake up call and the incident that, you know, you're trying to debug live with customers, you know, complaining at you and worried about things. But I think the one that has had the most impact on my platform engineering thinking was actually more of a slow burn, which was just back to back migrations of watching the companies I was working for go from on premise data centers to cloud computing. But with cloud being with kind of self-hosted Kubernetes and then needing to transition to the cloud, hosted Kubernetes and all these big transitions that I witnessed kind of take multiple months and in some cases years to manage back to back to back. And I think the hardest lesson I learned is that as much as we pride ourselves on being high leverage in the kind of operations platform engineering space, you know, 20 software engineers to one platform engineer, as soon as you need all 20 of those software engineers to change, your leverage goes away. So yeah, so I think my hard fought lesson was around migration challenges. Really?
[00:02:22] Chapter 2: Abby’s unconventional path to platform engineering
Kasper Borg Nissen: Yeah. I also there, in my previous job, I also experienced this. So yeah, I could definitely resonate with that. So before we go deeper, could you briefly introduce yourself for our listeners, your background and how you sort of ended up working so deeply in engineering, you sort of already like gave some of it away, I guess.
Abby Bangser: yeah, I'll try and keep it short. I have a little bit of a roundabout way. I didn't study computer science. I, you know, didn't get born thinking I'd be in this space. I worked in actually investments when I first left uni and found out that I really enjoyed the process of gathering data and cleaning it and making it useful to make business decisions around, which led me to applying to work at ThoughtWorks as a consultant. And while I wasn't capable enough as a software engineer, when I applied, they brought me in as a QA, and it turns out I really enjoyed that. And so I would argue that my entire career in software delivery has been around quality, just at different points in the life cycle and at different kind of depths. So starting with kind of test automation, going into quality of implementation or ideas and how we do that. Going into DevOps, I did a lot of work with how to make local environments more similar to production. So we were building more realistic environments. And that of course led me to production testing and production observability, and soon into how to bring some of these ideas I was doing on my individual teams into wider impact with kind of SRE and then platform engineering. So yeah, it's been a bit of a winding trail, but I think it all has a thread towards quality and supporting software delivery.
[00:03:58] Chapter 3: From “why” to “how” of platform as a product
Kasper Borg Nissen: Yeah. And I guess that also becomes more evident right now in the space that we're in right now, with all the complexity and all the services that are being built everywhere and, and the infrastructure just being even more complex. Today. So yeah, it sounds like a really interesting point. Also coming out of ThoughtWorks, where many of these ideas initially were born like microservices coming out of there and all of these continuous delivery and all of these thoughts as well. So interesting, interesting path.
Abby Bangser: Yeah, definitely.
Kasper Borg Nissen: So you just gave a keynote at KubeCon Cloudnativecon in Amsterdam that builds directly on your work around platform as a product. I was really excited to see you take the conversation further this time. And for people who haven't seen The talk yet, what was sort of the core idea you wanted to introduce in Amsterdam, and why did this feel like the right moment for a topic like this?
Abby Bangser: Yeah. So I guess the context starts in Atlanta a few months ago a few more months ago, where I challenged the community because it feels like the challenge in platform engineering today is not actually about developer experience in the sense of consuming from platforms. That is difficult, but it will perpetually be difficult. That's product engineering. The challenge is actually supplying, getting what people need even onto the platform to be able to be consumed. It's that producer side of creating things and the kind of centralized bottleneck we're recreating by centralizing a single team or group of teams who's producing everything that's becoming available on a platform. And I think what was really interesting to me is that I prepared that talk. I delivered that talk about the platform marketplace, the need to support producers of the individual components and capabilities on a platform completely, you know, based on what I was seeing in the industry, it turns out we had 2 or 3 other talks at the event that were on that same idea of how do we create that marketplace? How do we create that inner sourcing model to be able to extend the creation of capabilities on a platform. And so I think it was really important to come into Amsterdam with some more answers as to how, because what I was doing in Atlanta was sharing why. But people, once they once they believe it, they go, but how? And so being able to talk in Amsterdam about how and talking about what it looks like to set certain demands of a capability on a platform, set certain expectations of what makes a capability, something that can be incorporated successfully into a platform and operated on a platform was really important to me. So. So that was why I focused on it.
[00:06:27] Chapter 4: Extending the product metaphor—platform as a marketplace
Kasper Borg Nissen: Yeah. I just rewatched your keynote from Atlanta this morning about especially like the slides about with all the puppies on it, that really resonates. So acknowledging that these personas exist, how does this change how we think about platform as a product then? Does it change anything in how we perceive this?
Abby Bangser: I think if anything, it just extends the metaphor further is the way I would put it. Maybe in that I think that one of the reasons that we're really struggling with platform as a product in many kind of real companies, end user companies, people try and actually build this in the wild is because we're wearing so many hats of infrastructure and operations and cloud engineers as well. We're writing the infrastructure as code and configuration as code. We are operating the pagers on these services that are running, as well as trying to think about what it looks like to be a golden path for end users and user experience and what interfaces they might want. And I think when you acknowledge that that is too broad a stack for any one team to support, you actually can carve out a team that really is focused on the product side of things, that's focused on how do you create that marketplace like Etsy does for buyers and sellers of custom goods, create a marketplace that connects people rather than worrying about being the only one who creates those custom goods. So I think it can in the long run and even in the short run, help a lot. I just think people have to kind of have that shift in mentality.
Kasper Borg Nissen: Yeah. And I really like the App Store kind of analogy. It makes a lot of sense that we are now, we now, as companies need to build our own internal app stores that also supports that the producers of whatever it might be of an internal product that has to be supported as well. It's like a different way of thinking because I think many people, when they're starting with platform engineering, they hire like a platform, central platform team, and then they just start pushing out different services that help developers initially. But, this is like a shift towards really treating your platform as a product and also acknowledging that there's people on top of your platform that can also build platforms for other people. So it's not only like a single platform, but there's multiple levels of platforms, teams. As I hear it.
Abby Bangser: I think Gregor Hope might have been the person who said that it's only a platform when someone has done something surprising with it. Otherwise it's just a product. Like it's just a tool, right? So I think the interesting part about platforms is that they internal developer platforms is that people can be building on top of them in ways that you could never have imagined when you created those capabilities. And I think that is the power of them. But it's also the complexity of trying to, trying to support those crazy use cases sometimes.
[00:09:04] Chapter 5: The Platform as a Product report—scope and intent
Kasper Borg Nissen: So now we talked a little bit about the platform as a product report that you are a co-author of, and that was released at KubeCon in Atlanta last year for, for people that are not familiar with it, can you just give a brief overview of what it is and why it sort of feels like this was the right time to publish a piece like this?
Abby Bangser: Yeah, absolutely. It's a fairly short piece, which I think is really powerful in connection with some of the other like longer pages, papers that are out, you know. So the most recent O'Reilly book on platform engineering and all that this is, is I think 60 pages, 70 pages, something like that. And I think that it really focuses on my team's experience at Syntasso. So Colin Humphries, who was the CTO at pivotal, and Daniel Bryant, who has built many a platform and been in the industry for a long time. And Kat Morris, who's a product manager in platforms, which is not the most common, most experienced role, but she has many years experience bringing all of our stories together and giving, as I said, you know, wanted to do with this keynote in Amsterdam, bringing concrete implementations out to people. So, you know, what should you be measuring? How can you start to interrogate your own success in platform engineering to decide where to invest further and what does good look like in your organization? So that's really the goal of it. And I think hopefully we've heard a lot of really positive things come back from people about it.
[00:10:24] Chapter 6: The hardest part—deciding what success means
Kasper Borg Nissen: Awesome. Awesome. So from your experience, when people are like adopting this mindset of, of treating your platform as a product, what's usually the hardest part is that the mindset, is it the structure or is it the incentives? Why do people struggle?
Abby Bangser: Yeah, I think it's trying to figure out what they're trying to achieve with that platform, to therefore be able to measure the success of their platform. So measurement, I guess maybe would be the overarching challenge. I think measurements are always very difficult, especially in these auxiliary roles, like a platform where there isn't just dollars in dollars out that you can measure like you would with a product someone's paying for, right. Physical product. But I think if I dig below the easy answer of measurement, the fact of the matter is, is that different people want a platform for different reasons, and you have to figure out why who within your organization wants this platform and why and when. There's different reasons what the priorities are. Are you doing this for a developer experience like so many people are shouting about in the industry? Or actually, is that not the equivalent of buying a foosball machine for your, your office, like, or, you know, you know, putting, you know, ice cream in the freezer and that's not actually all that important to you. What you really care about is risk because you've had a lot of security incidents and you're paying out for SLAs and things like that. Or is it that cost you've been seeing sprawl of your cloud bill, and you really need to start getting that under control. There's so many reasons, and I think to succeed with a product, you have to have an opinion. And until you know what you're trying to succeed at the the ethos behind that product, you're going to really struggle to hold that opinion as you invest in new features and new new parts of the product. So I think that's really the hardest part.
Kasper Borg Nissen: Yeah, I. Agree from my past experience also, we build a lot of one of the reasons that we build a platform, at least, was also to hide a lot of complexity around compliance and build a lot of security and all of these things in, because I'm coming from a, the banking and financial services industry. So, having like a platform that took care of many of those things, at least for us, made a lot of sense.
[00:12:26] Chapter 7: Golden paths vs. golden bricks and composability
Abby Bangser: Definitely. But that's different than having developers be super excited because it's warm and fuzzy to use it, right? It doesn't mean that you don't need to invest in developer experience because you need adoption and you need users to, to work with it. But there are different tensions when you have a clear understanding of what the measurement of success is for that platform.
Kasper Borg Nissen: Exactly. So in the report, there's also a lot of talk about product thinking, user's feedback loop adoption and long term evolution. Why do you, like most often see organizations get stuck in the product mindset or the product mindset? Sorry. I'm also getting stuck in this over the project mindset when building platforms because many people are like building projects instead of products, right?
Abby Bangser: You say getting stuck in. I think that that's a good way of phrasing it because it often comes right from the start, unfortunately. So it's, it's almost about never being outside of the project mindset, because often the thing that gets a budget the first time around is a project. It's a migration, it's a, you know clear deliverable that you're trying to manage. And that project balancing the need to deliver that project on budget and on time with the need to build a sustainable product that can take on the next project as well. And actually create a product long term can be really difficult and take really strong leadership, not just from within the team, but from above the team where there's pressures like budget holding and things like that. So I think, yeah, I think where people get stuck is when they do not have buy in from the people above that are holding budgets that can give them the investment to actually build that sustainable product on the long term.
Kasper Borg Nissen: Yeah. So, when there were people starting out with a product that it's an early warning sign as I hear it.
Abby Bangser: Yes, definitely.
Kasper Borg Nissen: All right. So let's move on to the topic of golden paths, choices and flexibility, because I think these are also some words that keeps coming up in this platform engineering journey platform as a product. I think a lot of platform conversations eventually lands on how do we build a golden path or pave workflow that sort of guides teams towards using best practices that are defined internally in organizations out there. In theory, they are meant to reduce friction and cognitive load, but in practice they can sometimes become too rigid. So how do you think about designing golden paths in a way that guides teams without constraining them?
Abby Bangser: Yeah. So as you say, like they're meant to be reducing friction, right? But they can only reduce friction if they're the direction people want to go. So I don't know if you've probably seen some of these memes of like the path people walk versus the path that was built by pavers, right? You know, in physical world, like where you have this paved road and then the grass and then a dirt path through the grass because that's the easiest way to go. Humans are looking for the easiest way to do their job, and that is going to be different for different people in the organization. And what I've come to realize is that there is never going to be one way for everyone in the org, and there shouldn't be in any org of any size. You're going to have some people who are in the pioneering stage of development for their product, where they are exploring new ideas and doing things very differently. They're going to have some people who are in the more pastoral stage, where they're happy to sort of continue to build out something that's already quite stable. They don't have any crazy requirements and things like that. You're always gonna have different personalities. Some people care deeply about the nitty gritty, and other people are like, hey, this is good enough.
Abby Bangser: And I think the only way to make this idea of Golden Path successful is to realize that just like in the physical world, if you create a path that is all or nothing, you are more likely to fail than succeed. Because getting it 100% right is the only way of getting it right. But if you create a path that's a bit more modular in nature, you have a chance of getting it, of having it be mostly right and having that still be useful. So I think people have used the term golden bricks here. So the idea of you, you codify the things that matter to your organization, that should reduce friction for a small piece of the platform still. So what is database with encryption and backups and all of that look like, but it's just the database. And then all of a sudden, when you need a test environment that includes that database, you can compose multiple bricks so that when one team needs one type of test environment, one team needs another. You can grab the right bricks as and when you need it. And I think that composability is what makes the difference between a unsustainable golden path and one that can really grow with your product and your platform.
[00:16:59] Chapter 8: Sizing bricks and who builds them
Kasper Borg Nissen: So that is a really interesting thought. I really like the energy analogy around Lego bricks and golden bricks. I also actually saw a talk from Lego like discussing these things.
Abby Bangser: Baseplate.
Kasper Borg Nissen: Lego.
Abby Bangser: Bricks. How could they come up with a better platform name than baseplate? I love it, I love Lego exactly.
Kasper Borg Nissen: But but a brick and the golden path and the products that you're building internally, how do you then sort of figure out how, how big should my bricks be compared to the product and the team that we are defining around this particular platform product? And who's building the small bricks and who is assembling the paths in this case, then?
Abby Bangser: Well, Kasper, this is the hard part. But like, this is also the part that makes being a product engineer so exciting. And I think that this is hard for people in the platform space, because a lot of us don't have experience with this previously. But thankfully, the humans around us and the industry around us does. So I would look to some of the industry thinking around things like domain driven design and things like how you shape microservices. First of all, you're going to get it wrong. It's one of the answers, but you can evolve and you can combine services where needed. You can separate them where needed. The big thing here is to design out and create clear contracts, which allow you to version things and therefore transition as and when you need to. So as for how to decide what shape and size to build, my biggest recommendation is it's helpful to have something that is as permissive as your company will allow as the the lowest level brick, and then build up from there with more opinions that all drive down through that baseline brick, which gives you that chance to build multiple examples. So what I mean by that is a bucket in the cloud may look, there may be certain requirements around labeling and around costs, you know, tracking and around regions that you use that are across the board.
Abby Bangser: Every bucket in the entire organization meets these requirements. Now, most buckets should be private, but some are for websites and they need to be public. You can make those two example bricks feed into that, that baseline company one, allowing you to have that sort of composability and abstractions that build on top of each other. So and then I guess the second question you asked was, who does that different from humans, I think sometimes, right? So you know, who's making the, the baseline brick of, of how to get a bucket at the organization is almost certainly going to be an infrastructure oriented human as you move up the Abstraction levels. I think you do start to get people who have job titles in more platform engineering or developer experience or, you know, those kinds of developer enablement, those kinds of roles that are looking at how do I find that way of enabling people in my organization as effectively as possible? And what can I use to my advantage? And they can start doing that composition for the end users, rather than asking the end users to figure it out for themselves.
Kasper Borg Nissen: Yeah. And a question in this related to this is also, I guess, being able to decompose into smaller bricks also, I guess, allows you to design for different personas that are on the platform, right? Because right now you might be like building a platform very targeted directly towards application developers, but you might have data teams and maybe AI, ML as well, where part of the platform components could be stitched together in such a way that it could also remove friction for other stakeholders.
[00:20:30] Chapter 9: Personas, reuse, and API-first decomposition
Abby Bangser: Absolutely. I've actually literally just done this with some of our customers with Craddock's and that they, they were like, there's absolutely no reason anyone will need to create a service account individually. Like we're creating service accounts because we need them for this piece of infrastructure. Then they came back and they're like, okay, so we kind of need service accounts in other places. And we're like, all right, great. So we pulled out the, the logic that creates a service account. And we said instead of that logic, while creating this database, you're going to call out to this other service that's going to get you a service account. And then that, that craddock's promise will provide you your service account and provide anyone else their service account as and when they need it. And so that decomposition can only be true if you have APIs that encapsulate the full logic and therefore can change how they implement something without the users having to change anything about what they're doing. Because the application developer who needs a database doesn't care where the service account comes from, they just know that they need a database they can access. So we need to make sure that stayed stable. So. And it did with the API.
[00:21:32] Chapter 10: Measuring platform success with a scorecard
Kasper Borg Nissen: All right. Moving on to another topic, because now we've sort of established that we need to build a platform and we need to build products on our platform. But, how do we measure the success of our platform when we get it out into the hands of our, our stakeholders and users? And if the platform is a product, it needs product metrics, right? More than it needs platform metrics. I think in the report, you introduce the idea of an internal platform scorecard. How should teams actually think about measuring platform success?
Abby Bangser: I think you hit it on the head there when you described that there's layers of metrics. And I'll step back for a second and just say that's true in application software development too, right? You have things like CPU and memory at the base level, you have request duration, you know, kind of moving up the stack. You have then, you know, user success on sales, all this, like all these are important for different reasons. And so when talking about platforms, we need to know that the platform itself is is useful and we also need to know its operating efficiently from a compute point of view. So you do need those different levels. The scorecard that you're mentioning there talks a lot about the effectiveness of your ability to build a platform. And so the key metrics that we're talking about there are around, how hard is it to get a new capability onto the platform? How hard is it for someone to get something from the platform? How hard is it to update everything that has been requested from the platform? So in concrete terms, hey, platform team, I don't like SQL anymore. I want NoSQL shows my age a little bit. I dealt with this a fair amount. I want mango all right. Cool.
Kasper Borg Nissen: I've been that too.
Abby Bangser: All right. How long? How long will it take for me to get mango that has been blessed by my company sufficiently productionized for use by my teams? How long will that take for me to get out to you? That's the first one. The second one is, is once I have it out ready for you to get access to, how fast can you get it? Can you get it in minutes or days or weeks for your instance of Mongo? And finally, when Mongo needs to be patched because again, we've been there, how hard is it for us to go through and patch the tens, hundreds or maybe thousands of instances across the organization? So that's what's that's talking about the effectiveness of the platform as a as a mechanism. And then, of course, you're going to want metrics above that, like how effective are the actual capabilities and delivering value out to the users and how are you? And we also going to want metrics below that, like how much compute are we spending to be able to do this? Is this the right cost value ratio and all that kind of stuff? But if you don't have the mechanism to deliver value through your platform, then what are you doing? And that's why we focus that scorecard on that.
[00:24:18] Chapter 11: Different metrics for producers and consumers
Kasper Borg Nissen: Maybe circling back to the producer and consumer that we started at, are there any like differences in success when you're talking about consumption and contribution of a platform, because there must be different metrics as I can can sort of resonate myself to.
Abby Bangser: Yeah, definitely. Right. Because like in some ways, as a consumer, your platform almost should be like air, like you should only it unfortunately only bothers you when it's not there. Like when it's all working fine. You're like, what are you talking about air. I don't think about that. And so in some ways, the, unfortunately, the metrics for consumers are a lot of times around the lack of pain, which can be very hard to measure in the good days, right? Because you're like, are they not complaining because they're not using it or because it works? And if it's working, should we change anything or just leave it be? You know, those kinds of questions versus as a producer, what you're hoping to have access to is, is the details about those users. How many people are using your, your capability? In what way are they using it? Are they keep are they struggling with anything about that use? Are they updating things regularly? Are there certain aspects that they wish they could change, that they can't and things like that. And that's that product mindset of what my capability needs to be improved. And so yeah, I guess that's, that's when I think about the measurements across the board. Those are some of the things I think about.
[00:25:37] Chapter 12: Observability on vs. of the platform
Kasper Borg Nissen: Yeah. So moving into observability on versus for the platform, because that's also like an area where we can, can talk a little bit about different things, right? Because that's also true perspectives from, from a platform engineering perspective, that on one hand, they need to observe the platform depending on where they are in these layers of platform. But they also probably, or in many cases need to provide abstractions or pay paths or whatever for, for the applications developers out there, how do you sort of see this about these two different roles? And, yeah, how do you think about that distinction?
Abby Bangser: Yeah, I came up with this distinction when I was having a conversation almost about a year ago now, and it seems to help highlight for people what they're, what they're actually asking about when they ask about platform observability. So we'll see if it lands with you and your audience. So when I think about observability on the platform, I think about this as that consumer, that consumer perspective. Maybe based on your last, your last question, the consumers care that their applications that they're running on this platform can be observed. They can generate telemetry for it, that telemetry can be viewed in in interfaces and graphs, and then be fed into things like alerts and, and SLAs and SLOs and all of that. So the platform offering the capability of telemetry collection, possibly pipeline of, of telemetry, cleaning and managing and also storage, possibly some you know, baseline graphs and visualizations or alerts, all of those things are examples of what capabilities or products the platform might want to offer to its users. And that would be observability on the platform, things that people can take, take from the platform and use versus observability of the platform would be, how do you know if the platform is working? How do you know if the products, the capabilities that you're providing are being useful? Those are the things where you're actually observing the platform itself and not the things running on top of it. And so yeah, both, I think are very important. They just target maybe different audiences.
[00:27:47] Chapter 13: What observability should the platform provide?
Kasper Borg Nissen: Yeah, I totally agree. So from, from the on platform perspective, what should teams sort of recently expect to get out of the box when they I think you talked a little bit on this already. So I think you mentioned alerts and dashboards, etc. all of that is click a button somewhere. You get a service and then your service, your application is just automatically instrumented, your alerts are set up and you don't have to do anything. Or is it something else that people should expect? You should expect in.
Abby Bangser: Your threw me right into the firestorm that is the observability ecosystem. Aren't you there? Thanks, Kasper. I thought we were friends. No. So I say you're throwing me into the into that ecosystem, that firestorm, because I think there's a lot of debate over whether or not anyone can instrument your code for you, how much observability someone can do for you versus how much you need to do for yourself when you are building software, right? Because you're the one that knows the business domain, you're the one that knows the software, you're the one that knows the end user. So I would say at a baseline, what I would think is the first level of support a platform can provide users with. When it comes to observability, it's that telemetry collection and storage. I think those things are something that are pretty low level infrastructure. They're, they're not something that's very differentiating. Those are things that you can do for people. Beyond that, I think a lot of people will try to get to the stage of giving initial access to visualizations and alerts and those kinds of things, maybe with some really baseline examples, maybe with some like baseline required ones that you have to have, and then you can extend from there.
Abby Bangser: I think the idea I've tried to give observability out of the box, I have tried to be like, here is your dashboard with everything, and here's a set of alerts. And it's been great. And I actually wound up with more questions to me on the platform team than had I not done that, because it turned out that by doing that, they didn't know anything about their app. Then they didn't invest in figuring out what those graphs meant, but they would all of a sudden get paged by one of my alerts and not know what to do with the graph and walk over to my desk and ask me. Versus if I kept that more lightweight, it felt like they invested more of their own time to understand. So it is a spectrum. I think collection and storage is pretty clearly something the platform can help users with. I think visualization, alerting, and those kinds of sides of things are a little bit more of a balancing act depending on your organization. Yeah.
[00:30:13] Chapter 14: Observing developer experience and leading indicators
Kasper Borg Nissen: And I think many can resonate with that story of providing like Dashboards, etc. out of the box. And then people are like, what is this? Because maybe the culture wasn't there, or maybe it takes time. It all takes time, right? It does. I think it's I think you had to have a really good point about like having a good baseline. Part of the platform. And then I've heard people talk about that observability is a team sport that everyone needs to add their own business metrics. Of course, they need to have their insights and understanding of what is going on inside in, in their services, but providing like the baseline and the base infrastructure for collection and shipping it off to somewhere is definitely also what I believe in. So moving on to user observability and platform trust, because that is also another topic sort of related to observability, but user observability is a little bit different because I think it's a, it's a concept from the platform as a product book or report, and it's about visibility into how developers actually interact with the platform rather than what the platform is doing, but but how your users are actually interacting with the platform, not just whether their platform is technically healthy or whether it's usable, trusted, and helping teams move forward. But how should platform teams think about observing developer experience? Is it more similar to what if you're building a SaaS product product out there, you are probably going deep into and understanding how your users click different buttons. And you might have session tracking, and you might have all kinds of interesting things to understand how people are using your product. Is it very much the same when you're doing this internally?
Abby Bangser: Careful now, Kasper, that's starting to sound like you're giving me a softball question. No, I mean, I think I mean, yes, like to me, you just described platform as a product, right? Or anything as a product. A SaaS product is, is a quintessential example of something that you want to try and understand you know, how your users are using it. And so if we can get to the point where our internal developer platforms are as understandable as a SaaS vendor SaaS product, we are in a very good position, I would say.
Kasper Borg Nissen: What kind of signals do you see platform teams like. To detect friction before developers like Lose trust or, as you mentioned earlier, bypass the platform and like paving this path on their own next to the actual paved path.
Abby Bangser: Leading indicators, those are honestly sometimes the hardest things to find. I think that it's hard. There's a couple of things that I think about and I've tried myself. So first of all, I think if you have an ability to understand overall spend on infrastructure through through expense reports or budgeting and things like that, you might be able to extrapolate how much of that is coming through the platform's budget and not the platform's budget, who has expensed, who has an expense report every month for a different cloud account that you're not aware of? Right. And what are they doing with it? That might be a way of being able to track that people have gone off the platform. But the one that I always, to be clear, I've not yet implemented this anywhere, but I so wanted to is that I created a kind of custom CLI tool for my last company. I was at and we people were super excited to use it because we were solving some challenges for them. And they were like, great, but we knew that wouldn't last, right? Like, so we solved a couple challenges.
Abby Bangser: Eventually they're going to get frustrated by us and by it. And I so wanted to put in a little command that just said yelling or just like, like something like that, you know, everyone has like yelling channels and Slack and discord and teams and they just start being angry. And I just want to, I guess the point of that idea is that I want to be, I want to make sure that when people want to yell that there is somewhere that we are capturing that yell, that we are giving them a place where they're working that doesn't say, go open this tab and log in single sign on, and then click this button, and then fill out this form with four fields and tell us why you're upset. Instead, it's just a free form. I am mad, and I think that's like the best chance we have of like a leading indicator, but I can't, I can't offer it as proven to work, but I would love to hear if anyone has tried something like that. Sounds good.
[00:34:18] Chapter 15: Platforms as the evolution of DevOps
Kasper Borg Nissen: Sounds like a great vegan product. Doing some vibe coding and trying to write a thing like this and just put it out there in the open. Yeah. I think many people would actually like resonate a lot and use something like this. I think it's a nice idea to just capture that initial reaction when people are struggling. I really like that. Yeah. I think in one of your talks last year, you used a like a deliberate, provocative line. You said that DevOps was a dev improvement. Platforms are the DevOps, but not in in the way you might think. I guess that tends to catch people's attention. What do you mean by that? Is there, is there is this where the idea of curating an ecosystem becomes more important than simply enabling autonomy?
Abby Bangser: Yeah. Oh, man. That sometimes every once in a while I'll go something catchy, won't I? That one. I definitely stand by that I think I've done. I think that was at a time when I was doing a lot of talks about how platform engineering was not, ironically, not calling DevOps dead, but it was an evolution of a learning from DevOps. Right. So being the anti DevOps doesn't mean that DevOps as a concept is dead. It just means it's tackling from a different angle. So DevOps is a mentality I still think is alive and well in the most effective organizations. It's about understanding that you are building and operating a piece of software for the long haul as a team. And I think what we've realized, though, is two things. One, the taller the stack of software that you have to build and run, the harder that is. So if you're doing everything from mobile app down to plugging in the server, you're going to have a struggle. And then two is the more humans that are doing that, the more stacks that you have to do at your organization that look similar, the more wasted effort you have. So at platform engineering comes in and does is it tries to chop that stack shorter so it makes the platform build and operate half of it, or some portion of it, and the app team build and operate the portion above, so that shortens both of those stacks, making it more sustainable. And then secondly, it makes it so that there's less duplication, therefore less waste within the organization. So I think that's really what I was getting at there is that platform is like a scaled DevOps is another way. I think I've put that before.
[00:36:31] Chapter 16: Where mobile fits in platform scope
Kasper Borg Nissen: Okay. It was actually quite interesting now that you brought up mobile applications as well. How does like mobile applications and platform engineering like fit together do? How do you see that sort of do we also do the platform team also need to provide a lot of like paved paths for, for mobile developers? Or how do you see that sort of distinction or like separation there, if there's any?
Abby Bangser: Yeah. The only thing I can say is that to me, a platform is what is unique to your business, but common to your teams. So if you have a single mobile app team and then you have hundreds and hundreds of web app teams. I don't think your platform should worry much about the mobile app team. The mobile app team is unique. They may need extra resources to be able to support this taller stack that they have to manage, but without the duplication of that stack, without the commonality across teams, trying to codify that into a shared platform is going to be potentially a wasted effort. So I think it depends. Yeah. So that's your platform is a product and a product should be valuable as an economy of scale. It should be something that you are spending less to make than you are selling it for, than you are making on top of it. And the only way to do that is to keep things that are unique to your organization, but common across enough teams that you have that that economy of scale, really. So yeah, that's how I look at that, right?
[00:37:53] Chapter 17: AI’s impact—more important and more pressured
Kasper Borg Nissen: It's hard to talk about platforms today without talking about AI. And AI assisted development is accelerating everything. More code, more services, faster feedback loops, and more change happening closer to production. From your perspective, does this make platforms thinking more important or more fragile?
Abby Bangser: Why not both? So I think it's so much more important because the idea that you're agentic AI is gonna open up a Jira ticket and wait two weeks to get infrastructure so it can continue on its loop is just laughable, right? I mean, it's laughable that you want a human to do that. But when you put it into Agentic AI, it becomes obvious that's not going to be the way forward. So obviously, I think it's more important because not only can you not wait the two weeks, you still need confidence that the underpinnings of all of these applications are secure, that they're relevant to your business, that they are cost effective. So you really do still need that optimization, that platform engineering brings. As for fragility, like I think that the more use a product has, the more likelihood an edge case gets hit. So I don't think it actually makes platforms more fragile. I just think that it does put more pressure on them to be aware of all these edge cases and all these use cases because they will be challenged by the speed at which Agentic AI is moving.
[00:39:10] Chapter 18: Biggest opportunities for platforms in AI
Kasper Borg Nissen: What do you see as the biggest opportunities for platform engineering in AI? Is it. Is it around? Because I think many, many people are talking about natural language interfaces. Is it all the automation that can happen? Or is it the insights that you can now put AI to on your data and get some more valuable insight? What do you see as the biggest opportunities for platform engineers out there and developers?
Abby Bangser: It's a, it's a why not all situation, but you are asking for biggest. So I would say the biggest is turning access to resources into oxygen when it comes to genetic AI as much as it is when we talk about it for humans. So you know that that pressure to make sure that the access to the resources that are needed is not slowing down. Your innovative process, I think, is the thing that is the biggest opportunity. Because at the end of the day, it's a theory of constraints all over the software delivery lifecycle. Nobody wants to be the bottleneck, but the bottleneck does move like a really annoying itch. And right now, that itch is sitting on access to resources. And until we can unblock that, it's going to be there. And once we unblock it, then we'll find where else we need to go and, and keep doing work.
[00:40:17] Chapter 19: Closing takeaway and wrap
Kasper Borg Nissen: So if listeners take away one idea from this conversation about platforms and observability product thinking, what would you want it to be?
Abby Bangser: I think it's, it's that platforms are an outcome. And platform engineering is about building the kind of framework and capability of a platform, not the platform itself. The platform will only be sustainably built when we can have that sort of multiple producer mindset that brings everyone on the journey, allowing everyone to contribute and, and create that marketplace. And so it's not that platform engineering isn't important. It's that it's high leverage. And we should allow the infrastructure engineers and, and cloud engineers to do what they do best and just make that accessible to the app developers. So yeah, I think that's probably the thing I'm most passionate about when it comes to this awesome EP.
Kasper Borg Nissen: This has been such an interesting and thoughtful conversation. I really appreciate how clearly you can extract your responsibility and product thinking, and how observability isn't just a technical concern, but something that shapes trust and developer experience. Thank you so much for joining me on Code RED.
Abby Bangser: Yeah, thank you for having me. I really hope to hear from people how they think about some of these ideas. Some of them are a little more forward on the edge than others. So please reach out to me. I'm on LinkedIn. I'm in the Cncf Slack so you can come find me. And I'd love to hear how you're, you're tackling these challenges.
Kasper Borg Nissen: For those listening, we'll include a link in the episode description to the platform as a product report. If today's episode resonated with you, share it with your platform team. Because treating your platform as a product isn't just a mindset shift. It's often the difference between a platform that gets adopted and one that gets worked around. Thanks again for tuning in to Code RED. I'm Kasper Borg Nissen, and we'll see you in the next episode.
