 Hi, this is your host of LimbHartia and welcome to a brand new episode of our series, TfHire topic of the month, AKA T3M. And this month's topic is platform engineering is DevOps there. And who is better to talk about this topic than Austin Parker, head of developer relations at LightStep Austin. It's great to have you back on the show. It's wonderful to be here. It's been a little bit, but it's always great to talk to you. How would you define that from engineering? Because when we were at KubeCon, there are some companies who had DevOps is that I don't actually look at the labels that much. What I look at is that modern companies are embracing modern technologies and they are trying to solve some problems internally. And there are some ground realities versus what I be here and what we see. So let's hear from you. Quite simply, I think that platform engineering is, really it's a specialty of engineering, right? Like you might be a back-end engineer, you might be a front-end engineer. I think you can be a platform engineer. And a platform engineer is someone that is building tools and platforms to help developers do their job more efficiently, help them unlock sort of the potential that exists within the cloud and all these really cool abstractions that we've built over it. And it's someone that is really laser focused and sort of that experience of developing, right? Making it easier for other people to do their jobs. Talk a bit about this discussion which started already and then, you know, media was also covering, you know, that platform engineering and DevOps is gone. How do you see that once again, not only because Lightest of Youth, for example, yourself are tech company, but not only company like this, but also your users and customers. What actually is happening within these teams? Why are we talking about these labels? I think there's a trend in software, especially, you know, kind of in this bleeding edge cloud native world to try to get ahead of sort of terms, right? So we say controversial things like DevOps is dead or we say like, ah, you know, you have to be doing observability or whatever. And we're making this sort of fundamental attribution error, right? Like DevOps isn't dead, DevOps isn't gone because you can't kill what is really sort of a cultural thing, right? Let's think about where DevOps came from and let's like look back in history, you know, 20, 30 years ago, and I say 20, 30 years ago, but there are still places that do this today where if you walked into your job as a software developer, as a backend engineer or something, you sat down and said, okay, I'm gonna write code today and I'm gonna write code tomorrow and that's all you're really doing. You're writing code and then once you're done writing the code, you throw it over the wall to someone and it's their job now. And what we've realized as professionals trying to build products to help people to improve customer experience, whatever you wanna say, we've realized that actually, no, you need to know, you need to like think about that deployment side, right? You need to think about like, where is my code running? What are the capabilities of the underlying hardware and databases and so on and so forth? And as a developer, I need to own my code beyond just like writing it into the IDE and saving it. And that is what DevOps is. DevOps is really that shared responsibility. It's that shift left of moving things that formerly were someone else's responsibility more towards the place where we write the code so that we have more ownership over what we're actually doing in production. And that lets us not only be more efficient and effective because now I don't have to have, I don't have these silos of knowledge and experience and whatever else. Now I can actually take advantage of all of these cool things we're building in the cloud, right? I can take advantage of really neat database abstractions or external APIs or whatever because we're being able to pull sort of the development in the operations world closer together. And platform engineering is a compliment to that, right? Platform engineering is me saying as an engineer, well, I'm gonna work on building a better platform to do DevOps on, right? To enable or to accelerate DevOps culture inside my organization. I do remember, you know, we had a discussion where you were saying that, you should not even have DevOps in your title. So if once again, going back to the ground reality, should you have platform engineering in your title? And if yes, why? I think, yeah, no, I think, you know, you can't have DevOps in your title, right? Because DevOps is this cultural thing, but platform engineer, sure, right? You can be a senior platform engineer. You can be a junior platform engineer. I think there's a lot of overlap there with sort of site reliability engineering. And these are, you know, not quite two sides of the same coins, but certainly if you are interested in SRE, platform engineering is going to be like very appealing to you as kind of a, you know, area of focus. But absolutely, like platform engineering is a crucial part of unlocking, you know, more productivity, better end user experience, just better, like more happiness, really, I think. You know, if we look at the categories of stuff that you're supposed to deal with in platform engineering, like how easy is it to really deploy code? How easy is it to understand what my code is doing in production? How hard is it to profile things or to kind of get this end to end understanding what's going on in prod? You know, these are features that platform engineers can deliver to sort of their end users, right, to their developer audiences. And that's all absolutely crucial stuff if you're trying to make it, you know, make the actual practice of programming better for your colleagues and coworkers. So absolutely, like you can be a platform engineer and you can go and build these cool platforms. I think the interesting thing, and this is what I see a lot of our customers, you know, grappling with right now, is that it's the rate of change of technology and this idea that how are you going to build a platform that's kind of better than the off-the-shelf stuff, right? And that's a whole other conversation, but it's something that you need to consider on your journey towards platform engineering. Let's just look at it from a different perspective that are these like platform engineering and DevOps, like opposite pools, is it platform engineering versus DevOps or is it like one is just a subset of once again cultural thing? How would you look at that? The way I like to think of it is that DevOps is sort of a foundational thing, right? Or I also, I say this about observability as well. Like it's a, you know, it's kind of like sand or water or air. It's something that fills in all the gaps and fills in around everything else in your org. So if you think about DevOps as being sort of this this ether almost where it's just like, this is something that we are doing as an organization or as a team, as a company, then platform engineering is a concrete realization of that. If you have a DevOps culture and you are, you know, have an organization that's focused on DevOps, then you can build platform engineering in that. In a similar way, you know, if you're trying to do, you know, next level monitoring or, you know, automated alerting or, you know, unified telemetry, then observability is kind of that foundational, you know, that sort of thing that suffuses the org and you're gonna build this other stuff on top of that, right? Like you can't build like really, and there's a lot of like hand in hand here, right? Like if you're platform engineers want to say like, okay, we're gonna build this cool portal or this really neat continuous profiling system for you and make it very accessible to developers, then that's also gonna start pulling in from all these other things. You're gonna start bringing in, you know, hey, I need this feature from open telemetry and I need this sort of data storage thing and I need Kubernetes and I need da, da, da, da, da, da, da. You know, that's the engineering aspect of this, right? Is that you're building up this kind of set of layers almost where someone, and then building like a really nice UI and UX on it for your developers to come in and say like, okay, when I deploy, now I get all this stuff for free rather than having to kind of build it all myself every time. But you don't get there without having that commitment to DevOps. You don't get there having that commitment to observability. So this is the fundamental thing. You know, we need to flip our thinking and stop thinking about like DevOps as a product or observability as a product. You know, these are very low layered cultural and you know, organizational concepts. These are states of mind more so than products or features. And then things like platform engineering and you know, unified telemetry and open telemetry and stuff like that. Those are what is on top of that foundation. Since you have a title developer relations we also talk about developer experience because if you look at ops team, security team there are certain teams who are very calculated very methodological, very mechanical or mathematical but then there are also teams, I mean, we used to call developers as poets or artists because they are creating something new. So the way they look at things could be different. So how much important should there be when we do talk about platform engineering or DevOps or move to these teams to also kind of create that developer experience or is there a such thing as developer experience or the culture which kind of promotes that whole because innovative because that's you're creating something new you're trying to solve a problem there. That's interesting. I think one thing, you know, to pluck on one thread we talk about developer experience and a lot of times I've seen this in organizations that's saying like, you know, we expect you to come in and we think our developer experience is so good for you know, internal platforms that you can make a pull request in your first day, you can ship code to prod within 48 hours of starting and that's great. But I also think that like an important part of developer experience is how easily can I find information about something, right? Like how good are the docs? First time that I, you know, I go into somewhere and the first time you're on call, first time you take the pager like and you do get an alert, you know, how easy is it to actually understand that alert and to find the right dashboards or find the right documentation that helps you understand like what's going on and what do I need to do to fix it? I think it's very easy to kind of get caught up in this mindset of, you know, we're talking about developer experience, we're just talking about like lines of code or we're talking about, you know, efficiency and performance, but there's a whole, you know, there's that creative aspect you talked about. There's also like the, being a librarian, right? Like you could be a platform engineer and you're, I think there's like tons of value in being a platform engineer whose entire goal is just like improved developer documentation for internal users. I think there's parts that are improve the accessibility of platforms, right? For people with varying, you know, not everyone is the same type of learner. Some people are going to come in and they're going to be very, like you said, very focused on sort of the math and the algorithms and they're going to have a mind that works one way but you're probably going to have a pretty diverse team and how do you make the developer experience accessible to people on your team that aren't, you know, that don't have the same background as you, right? Both in cultural or educational or whatnot. So there's a surprising amount that can go into the concept of a platform and what developer experience actually means. And that's something that we should keep in mind as we think about how to grow these teams and how to grow this practice in the industry. Austin, once again, thank you so much for explaining things so beautifully as usual and talk about this screen and I look forward to our next discussion. Thank you. Thank you. It's great to be on.