 Hi, this is your host, Sableem Bhartia, and welcome to a brand new episode of our series, TFR Topic of the Month, a.k.a. T3M. And this month's topic is platform engineering is DevOps there. And today we have with us Narayanan Raghavan, Senior Director of Site Reliability Engineering at Red Hat. Narayanan, it's great to have you on the show. Thank you for having me here. Today's discussion is going to be quite interesting. It's about the cultural changes, the evolution of the terms, jargons, practices, tools that we talk about DevOps, SREs. We have not talked about DevSecOps yet. We will throw that also in the mix at some point. And platform engineering. Before we jump into this topic, I want to just set some like ground so that folks do understand where we're coming from is that we are seeing this discussion in the market in a, hey, DevOps is dead. Now we are talking about platform engineering. If I ask you, what kind of cultural or organizational restructuring you are seeing within the industry, within the market in terms of disciplines like DevOps, SREs and platform engineering. And then we'll talk about what is driving this discussion. In terms of cultural evolution and as a result, in fact, to the organization itself, first thing I'll say across DevOps, SRE and platform engineering, the one common theme is culture, right? So if you, that's the key focus from my perspective is if you don't have that right culture, none of these functions can flourish. And what I mean by that is really boils down to what are your principles? Things like it is okay to fail. Because guess what? Whether you're a DevOps engineer or an SRE or a platform engineer, there are going to be failures. There are going to be escalations. And knowing that it's okay to fail and learning from it, that's going to be important. Assuming positive intent because we're talking about a blameless culture across all three and being able to have a concrete conversation around the challenges and opportunities that's absolutely critical for any healthy organization. Communication, that's a key and I don't have to stress that at all. And the last thing I'll say is being able to disagree and commit, right? And what I mean by that is you can have tons of conversations, it's software, you can rearrange the bits any number of ways but preventing analysis paralysis is going to be key. Across DevOps, SRE and PE, the speed with which you move, part of it is going to be required. Whether you're a platform engineering team or SRE team or what have you, the pace with which especially in this day and age things are moving, it's going to require changes. It's going to put teams in positions where they fail, they're gonna have to regroup, decide on a path and move forward, right? With that said, a lot of companies, at least companies that I've interacted with, they're still trying to figure out what makes sense for them. And in all honesty, I think it boils down to the particular company, the maturity level of the company, the lifecycle that they're at and the size of the company itself, right? So some companies are specifically focused on, there is a need for an SRE function. There are others that are focused on SRE and platform engineering, right? So again, it really depends on your culture, it really depends on your maturity level and really also depends on your scale. Excellent. I actually touched upon a lot of points that I was going to ask you a question for, but when you're talking about three courses, I think it's like, you said three Cs, commitment, culture and communication, that's great there. Now, as you're talking about now, some companies may look at SRE functions. Let's just also look at it that, because once again in the ecosystem, the discussions can lead in different directions. Is it SRE versus DevOps versus platform engineering or is N, okay? Or before we go there, let's also, I would really appreciate if you can define platform engineering, how different it is from DevOps so that will make things very, very clear. Okay, so let's start with platform engineering. Platform engineering really boils down to the speed and consistency for rapid application development using building blocks. And what I mean by that is building blocks are discrete software component microservices that are common across all of your development teams. In other words, your development teams can actually use those building blocks to build whatever it is that they're building, whatever application it is that they're building. They don't have to worry about those building blocks. It's basically a bunch of Lego blocks coming together. So your development teams can focus on the business logic that runs on top, right? From an SRE perspective, the focus is on reliability, scalability, performance, security of your entire fleet, right? Regardless of whether your fleet runs on, on-prem or any of the hyperscalers doesn't matter. SRE is about those functions across your fleet. DevOps is then about breaking down silos between your development teams and operations team, trying to get them to work together well. So they can then focus on speed and continuity of that application lifecycle itself. So from my perspective, those are the three different categories, definitions, et cetera. But let me also focus on the skills that are required for each of those functions. Because I think that's where you start to see separation. Across all three, and I almost want to draw, you know, a two by two matrix, but across all three software engineering is a key skill. You need to know how to code whether you are a DevOps engineer or an SRE or a platform engineer. The second skill is systems engineering skill. SREs and platform engineers absolutely require systems engineering skills versus DevOps. The third skill, and this is where SREs stand out, is crisis management, right? When you manage a fleet at scale, you're going to have escalations, you're going to have issues. Being able to manage that crisis calmly, that's a skill, right? Being collected, being thoughtful about what your next steps are. When you're going through that escalations, that's a skill. DevOps, from a DevOps perspective, I wouldn't say crisis management is a skill you need. From a platform engineering perspective, I'd probably say it's a maybe. Soft skills, these are communication skills. That's the next piece. I'd say soft skills, whether you are a software engineer or a DevOps or SRE or a platform engineer, soft skills have to apply consistently across the board. And then for platform engineering, specifically product management skills, that's the one thing that stands out because a platform engineering team is really building a platform. You're building a platform for an internal audience, in this case, all of your application development teams. And because you're building a platform, you better know and understand what are the use cases that you're solving for, right? So you need a product manager in that space versus in SRE or DevOps, you really don't need that. You don't need that role. The term that we keep hearing, and I want to throw it at you as well, is DevOps dead? So from your opinion, is it really dead? I think we all know the answer, but I would love to hear your take on that. No, DevOps is not dead. I think it really comes down to, again, every company, every culture, the size of the company, the scale of your fleet, the maturity level of your teams, et cetera. DevOps is just the beginning of a transformation towards scale, towards reliability, towards consistency, towards automation, towards self-service, and building a set of capabilities or building blocks that can apply consistently to all of your teams. So I'd say DevOps is just the beginning in many ways, and as teams mature, you get into, do I need SREs, do I need platform engineers, et cetera. So for a company, a large company with multiple application development teams, chances are they're reinventing the wheel when different teams are building applications. At that point, the need for platform, a consistent development platform, development tools, QE tools, that becomes important, right? So investing in a platform engineering space at that point in time makes a lot of sense. As the size of your fleet increases, reliability becomes critical, and even if your fleet is not big, reliability is critical for any production system. So as the criticality, I probably should say it that way, as the criticality of your application increases from a business perspective, the need for reliability, the need for performance, latency, scalability, et cetera, that only goes up, and that's where you need SREs. As these teams are evolving, we are also hearing a lot about developer experience. I want to ask you, first of all, how would you define what is developer experience? It's more than just the flavor of muffins that they want. It's also a lot of other things. And where does it fit into this platform engineering? The way I think about this is platform engineering helps improve developer experience, right? Platform engineering is focusing on a set of tools, set of building blocks, a consistent platform that all developers in the organization can rely on, so they can focus on building the business logic, the applications that are required for your respective businesses. So from my perspective, developer tools goes right into the heart of platform engineering itself. They're large organizations and they're small organizations. Everybody is on their journey, they're in different stages of their journey. Sometimes smaller organizations, they get intimidated when they hear all these new terms in the world, not only term like Kubernetes and other service mesh, but also platform engineering, they're like, it's called SREM. Hey, what do we do about that? So can you share some advice? How they should approach it? They should, should they approach it as, probably we should embrace this term platform engineering, how they should start looking and ask a lot of questions that what we need, why we need it, and then embrace some of these practices. What is the right approach? So the first thing I would say is, I think as an industry, we need to stop relabeling people. So if I have an operations engineer, relabeling somebody in SRE or a platform engineer does not magically bestow upon them SRE skills and platform engineering skills, et cetera. And I think first and foremost, teams, companies have to realize and recognize that just because you called some team or called somebody something, doesn't automatically mean you have a DevOps team or an SRE team or a platform engineering team. With that said, I think there are specific, there's tools, processes, people, skills that teams can focus on to build people, right? To upskill people, to give them tools necessary to do their jobs well. And for me, culture is also part of it. Like I said earlier, the principles you have within your team absolutely matter for the health of that team. If you are fostering innovation in a part of innovation is letting people fail and being okay with failure, celebrating failure, that is important, right? Hard skills, whether it's Kubernetes or Golang or whatever the skill is that makes sense for your respective organization. Being able to invest in it and build consistency with it, that's going to be important, right? One of the things I'd say that we did here at Red Hat is basically upfront, at least within the SRE teams, upfront say we don't want a bunch of random scripts lying around if we are writing code and when we write code, it's going to be in one of these two languages. So bringing that consistency is going to help once you start thinking about scale, right? And it also makes it easier because you don't have siloed knowledge, you don't have hero worship. The last thing I'll say is there's also training, right? Training in soft skills, training in hard skills. And that really boils down to investing in the people that we have and identifying people who have the potential to step into either a DevOps role in a SRE role or a platform engineering role. Narayanan, thank you so much for taking time out today and talk about this topic. And I would love to have you back on the show. Thank you. Thank you for having me again. It was great.