 how would you define platform engineering and how different if it is from DevOps or SREs or they can overlap? These are just labels. It's very good that you bring up the word labels because that is what it is. Like, sometimes it's the same thing, but we give it like different labels. And sometimes that's driven by, you know, like marketing concerns, maybe, just give it a new name to make it sound hot and then it's like easier to market. But then also I feel like there is a shift in focus. So originally it was DevOps meant developers also need to learn about operations so they're able to have full responsibility for the entire lifecycle of the code that they develop and ship. And now, and I guess this will be something that we can talk about going further in this conversation. Now we're kind of like shifting away from this idea of DevOps and saying like, you know what? Devs should just focus on developing, on providing value to the end user and we should try and abstract everything else away so they can just focus on this one thing. And I feel like that's kind of the idea that kind of reemerged in the last couple of years. I think the right way to think about it is not different. It's a natural evolution. And what I mean by that is if you look at any DevOps maturity model, broadly speaking, you have generally five stages where you have no DevOps, you're just starting off, then level three is you've got the basics, you've got everything going, then you get to start measuring things. And then kind of in the last step of DevOps, broadly again speaking, you start optimizing what you're measuring. So where does platform engineering, it's the next step in so far is once you've done all this work, right? Once you've figured out what works, once you've instrumented it to measure it, well, why don't you just reuse all that? Why don't you reuse all that for different groups, for different projects, for different workloads? Because presumably, right, if you've gone through that and if you've done an even remotely decent job, there's value in it and you can reuse a lot of that to help other teams that might not have put forth the effort into it. Now, it's not different in that it doesn't walk away from any of the concepts of DevOps, of the philosophies, right, of either technical or otherwise, it's actually the opposite. You can think of it, I think in the platform engineering versus DevOps, it's now you're productizing it for all intents and purposes. You're productizing the automation, right? You're productizing the pipelines so that others don't have to go and rebuild all that again, right? And presumably, the way to think of it or the way to think of it rather is just packaging up all those different tools. So you do have to, in a sense, really think of it as a product manager, albeit internal, right? So there's a lot of things you might be able to get away from, but that's essentially what platform engineering is talking about or packaging all the stuff. So it's an evolution in a kind of systematic way of packaging all these things. Platform engineering actually has two different sides to it to me and I think part of what I look at is this side of saying enterprises have been given the directive to create self-service environments for their app dev teams, right? That is part of platform engineering and it's a big part of it. But on the other side, and they've been building products or trying to create products that service developer self-service needs from that perspective. On the other side of it, there's also a drive within these companies to consolidate and add more centralized control over how the infrastructure behind those efforts is managed and that is also part of this platform engineering system. So the platform engineering includes both the how do I enable dev self-service without overly constraining developers and as an infrastructure and operations team how do I build and rationalize consolidated control over all of the different infrastructure requests that I have coming in? And platform engineering is really, ends up being a product management function of delivering that type of service because at the end of the day companies need product is the wrong word here because there's no one product that's gonna deliver it. Even rack end doesn't have enough scope to solve all these problems. We don't want to have enough scope to solve all these problems but from a enterprise perspective they actually need to start thinking about this as a product management problem. Which APIs are we gonna do? What features they have? How do we offer those features? How do we deliver it? It's really this advent of defining the relationship between the app dev teams and the backend infrastructure in a productized way. And that's the really significant part of how all this platform engineering sort of works is that productization or this standardization approach. Well, I think of it this way. Platform engineering is sort of industrializing DevOps. So in DevOps, the idea that you could integrate and automate and create automation pipelines that really supported developers in releasing more frequency. And we saw people looking for continuous improvement. Well, now if you scale that and you think about DevOps at sort of the next level of maturity you've got all these different teams, all these different parts of your organization embracing automation and using integrations. And you mentioned that involves security, right? So security comes in as part of that. So do you teach every single one of those teams to do every single one of those things? Or do you say, look, our DevOps has evolved to the point that we need to do platform engineering. So we'd like to centralize and standardize and perhaps have a group who knows how to do certificate management and can do it on behalf of the developers or knows how to create an automation pipeline and can build that integration to the infrastructure in a more standard way. And does that take the friction out of every developer having to do it? So I think of it as like a DevOps enabler or a DevOps accelerator versus something that's in the conflict with DevOps. Platform engineering is the practice of allowing the application development team to really purely focus on the development and reliable operation of their application without having to concern themselves with the complexity and the implementation details of really everything else. And that everything else is the platform. And the platform engineering team's responsibility is to build and run and provide as a service that platform which allows active teams to run in the manner that I just described. I think it can be helpful to go in and share a contrast to the platform engineering model. And that contrast is DevOps. I think these days, if you go to job boards or titles inside organizations, there's still a lot of organizations who still hold on to the DevOps nomenclature. They have a DevOps engineer, right? And I think that the reason that maybe that's stuck is really because similar tools and skill sets are in play in both the DevOps and the platform engineering roles. So it's the tools that back then it was Jenkins. Now it's more get-of-actions or Tecton or Argo CD or whatever it might be. But back in the DevOps days, the people, specific individuals who were wrangling the tools and the releases were a part of DevOps. And it just kind of stuck because the platform engineers are today in the correct model are still wrangling those tools. And I think it's also worth us discussing. Oh wait, just real quick. I know everybody understands this, but bear with me. Okay, because I think it's important to go to recount what the DevOps model was. And even though people might say, no, no, we understand what the DevOps model is. And we've moved away from that. But I would say that in your organization, if you have DevOps engineers or platform engineers who, for example, are wrangling releases for multiple app dev teams, then that would be evidence that you are still stuck on the old DevOps model, okay? The old DevOps model was this. You had a dev team, then you had an ops team. The dev team was responsible for writing the application and they would go and package that, build it to a deployable artifact, a binary or a jar file or whatever it might be. And they would hand it over to the ops team. The ops team would take that deployable artifact, place it on a server that they operate and they would run it. Meaning they would carry the pagers for if there was anything that was problematic from that application. And the reason I think was because back then, sort of the most visible part of the failure when the application failed, had an outage or had problems, the most visible part of that was from the server point of view. You would go in and look at metrics on the server, use the error logs that are very low level that are written to Syslogs and that's why these people were responsible for it. Now, the problem was that the developers domain of concern and the operators domain of concern had nothing to do with each other. The operators didn't really understand the development point of view. We're talking about application specific characteristics like what was the memory utilization on this thing? What are the failure modes of the application itself and not the platform? And conversely, the application development team didn't really have an appreciation of what it meant to operate this thing, what reliability meant and what they needed to do. And so then DevOps was born. And I know DevOps isn't a team, it's not a function, it's a mentality, right? But realistically, you had people who were tasked, they were commissioned to go and say this is your responsibility to the team. And so the DevOps mentality was born where they tried to understand one another's cadences and they try to coordinate that a little better. Okay, now, as the new thing these days, I think I'm way behind the curve and saying something like cloud is sort of the new thing. A lot of organizations are moving over to the cloud and what you really have to get right more than ever on cloud is reliability because it's really, really difficult. If you go in and take the old mentality of how you wrote and deployed and operated applications on, let's say, a local data center or just in that mindset and you move there over to the cloud, everything from sort of the balances of cap theorem to tangibly how the applications operate, it's likely that your application will run worse in the cloud if you just lift and shift. Just your shared resources, you have different uptime or availability of the compute resources that you're running on and that model is gonna put you probably in a worse place. And it really comes down to complexity of having to learn a whole new platform. So moving away from sort of DevOps over to a platform engineering model, if I were to sort of give you a picture and there are two dimensions on one dimension. I would say that the skill set and the sort of mindset is actually pretty similar, right? It's people who are concerned with not, all the things around the product and not the product itself, right? So it's the illities, if you will, right? Reliability, security, scalability, et cetera. And that can come in different forms. It can be a consultative kind of view. And I think a lot of SREs take that mindset where it's like, oh, look, I'm gonna help the team out. We're gonna be a first line of defense. We're gonna help them measure and improve. DevOps tends to do the work sometimes as part of the team, sometimes again, centralized depends. And then the platform engineering, at least the way I've seen it done is generally building a platform. They're building something that then they have internal customers that they're using it. So it's kind of like different approaches or even different degrees to how self-serve is it? How consistent is it? What is the thing that they're responsible for that they own? And is that a concept or is that a system? And if it's a concept, then it's like, okay, I'm gonna be responsible for reliability. What does that mean? I have to now define that set of practices and tools and outcomes. As opposed to the platform where you take the repeatable services that everybody inside of your company requires, which they may be able to get from a cloud provider, but more likely they're gonna need to hook together multiple systems with some configurations, some consistency, and that'll give you everything from compute, network storage, database, identity, observability, et cetera, et cetera, as a part of a platform. And hopefully, obviously some metrics and goals around that, some service law objectives or whatever, but something that is a running system that other teams internally can leverage to build and deliver whatever software they're building. That to me is really what a platform engineering team is that's different. And the SRE approach is much more focused on how do we improve reliability? How do we measure reliability? I would say DevOps is much more about, how do we take responsibility for whatever goes wrong? How do we make sure that all the things that need to be done to deliver the product are done in an appropriate way? I think platform engineering is really a new trend that we're seeing, especially in large organizations where you need to have a center of excellence for how you do cloud infrastructure, cloud engineering best practices. And the platform engineering team typically sits between maybe the operations, more IT centric folks and developers. And their goal is to really be, like I said, center of excellence, establish best practices, put in place the systems that allows the organization to scale and ultimately just empower the rest of the organization to ship faster with confidence, compliance, cost controls, all the things necessary in sort of a modern enterprise looking to go to the cloud. Yeah, it's a fairly new term. But I think at the heart of it, it addresses all problems. And the way I see it is that it's a way to try to address and mask all the complexity that we have today in cloud-native and cloud-native infrastructure. Essentially just, not just in quotes, but just trying to optimize developer productivity and doing so by often allocating a dedicated team, building out an internal platform, an internal team at a large corporation, building out an internal platform that sort of helped building out tool chains, workflows, et cetera, and essentially providing sort of self-service for the internal development teams that the company has. Essentially, it all boils down to that infrastructure is very, very hard today. It's really hard to manage the complexity of the richness of it. So it's not just bad, but we've got this complexity because there's too many decisions, there's too many products, there's too many things to integrate. And how do you make sense of all of that? They can be daunting. And if you then have a dedicated platform team that can focus on taking most of these decisions and providing higher level primitives and work in managing very hard things like security, making sure that you're under compliance and all of these things, so that the dev teams are liberated or set free to focus on what they are best at doing, writing the business logic, et cetera. So that's how I think about platform engineering. Thank you.