 Hi, this is your host of LimbHartia and welcome to a brand new episode of our series, TFI Topic of the Month, AKA T3M. And this month's topic is platform engineering is DevOps Dead. And I guess today is Kit Merker, Chief Growth Officer at Noobline. Kit, it's good to have you back on the show. Great to be here. Yeah, and today's discussion, as you know, is about platform engineering is DevOps Dead. Before we jump into this discussion, what I would like to hear from you is that what kind of cultural or organizational restructuring you are seeing within organization when it comes to discipline like DevOps, SRE, platform engineering? Yeah, I would say a few things on this. In terms of the org structure, there's a few different modes on the spectrum. One is rebranding, right? You take an IT ops team and you kind of rename them SREs and probably have to give everybody a raise if you do that. But there is a lot of that that I've seen where people say, you know, let's rename the team. And by the way, naming is an important part, right? It helps define the roles and clarifies an approach and gives people some context about what you're trying to do. So that's one side of it. I've seen quite a few teams that are hiring, you know, reliability engineers, you know, SREs, production engineers, et cetera, from the big, how do you say it now? Is it FANG companies? It's now MANG, I don't know. But, you know, from Metta, from Google, from, you know, Apple, they're bringing these folks in that have experience in large scale teams and trying to bring that to enterprises. I've definitely seen a lot of teams building platform engineering groups and platform engineering I think is really a powerful move. I've seen quite a few SREs actually, even where companies have gone through the evolution of saying, okay, we're gonna have a DevOps or a cloud engineering team, then they move to SRE and then they're moving to platform engineering. And I don't know that it changes the work to be honest, but I do think it changes the interfaces and the ownership. I think that's really the key difference in these organizations. I think one of the risks in building an SRE team is that you might end up doing a lot of DIY engineering projects. And I think there's a lot of hesitancy around that right now in early 2023 where we sit with a lot of economic uncertainty and headcount uncertainty. You know, doing DIY is probably not the most effective approach right now, but there's a perception I think amongst engineers that if you don't build infrastructure that you're not gonna be able to get ahead in your career. And so that's something that I think people have to counteract. So that's another thing I've seen. But there's a lot of interesting models like embedded SRE teams versus centralized teams. I've seen quite a few companies, especially larger enterprises that build, they build sort of cross company groups where they'll have like guilds or other kinds of reliability focused virtual teams. And I've seen that be really effective because you don't really have to do much to build in terms of org structure is not political. It becomes really more about learning and sharing ideas and practices, which I think is a really great place to start because I think jumping to org structure is always like a little bit chaotic, right? A little bit risky. I would also like to hear from you that the definitions, as you said, the labels are important. How would you define platform engineering and how different if it is from DevOps or SREs or they can overlap? These are just labels. 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 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 level 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? And 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? We do hear that DevOps is dead now at the time for something else. As you said, these things really, I want to hear your opinion, is DevOps really dead? I don't think it can die. I mean, it's kind of funny, I think it catches headlines and people kind of latched onto it, but I don't see a reason for it to die, to be honest. I think DevOps has been a rallying cry for a lot of people who are trying to find their role. And we've seen the evolution in tooling, which I think is also an evolution in kind of technical competency or even technical literacy. As we're now moving to a mode of low code, no code, I'm even hearing about prompt ops, which I think is the silliest one so far I've seen, but we've got co-pilot and other kinds of tools that are really reducing the barrier to entry for technical contributors. It's not to eliminate engineering or development, in fact, I think to the contrary. More and more of our life is dependent on digital information, but what we've found is that there's patterns and tools that make it easier to do that. And so what I see happening more likely is that the DevOps mindset is going to be applied to more domains, like I think in the ML ops space, for example, machine learning data scientists need a lot of help with their DevOps. That's something I've heard all over the place that ML teams still don't really have a good delivery model for how they're gonna put their models and data production. So I would say in some ways it's growing. And I think in some ways declaring it dead may even be revitalizing, right? So maybe it's a good thing. You also touched briefly in our discussion previously is the importance of developer experience First of all, once again, how would you define developer experience? What is the importance and where does it fit in the platform engineering aspect? You had defining developer experience is actually, it's an interesting question because it's one of those things you kind of know it when you see it, but developers get frustrated when they have to go through sort of consumery types of experiences to do what they want. And developers are trying to automate. I mean, this is really what it comes down to. Rather than manually doing something they wanna automate. So the question becomes, how do you make that easy for people? And so you wanna have simple APIs, you wanna have command line tools, you wanna make it fit into their developer workflow, you wanna make it so you can persist configuration as code. You don't wanna have any sort of unintended side effects. You wanna be transparent about versions. Those kinds of things are all part of that developer experience. And when it's not there, when people try to hide complexity to make it easier, they end up with the unintended side effect of making the developer experience worse. It actually can be antithetical to making a good UX. We think about a good UX for a consumer hiding a lot of the complexity and guiding them down a path, which for a developer, it's like the difference between giving them a Lego set with instructions versus giving them a set of tools that they can go build, can go construct something for themselves. It's a very different way of looking at the world. We have reusable components you can bring together to build stuff. Where does developer experience fit into when we talk about platform engineering? If you think about a platform that you've built for your developers internally, right? You have to give them a developer experience. And you can kind of think of this as like a, you know, a set of reusable components, but you wanna give them clarity about the constraints of that system. If they're trying to build highly reliable, you know, high performance service of some sort on top of your platform and you haven't clarified for them what the reliability targets or the performance targets will be for that service and given them a way to provide feedback about that, you're gonna run into trouble, right? And this is, you know, it's part of developer experience, but it's also just like engineering constraints, right? I'm trying to build something. You told me I'm supposed to use this platform and the platform doesn't give me what I want. How do we have that conversation? And then more importantly, how do we have that conversation at scale, right? Because we don't actually wanna have the conversation. Let's be honest. We wanna have pull requests. We wanna move our meetings into pull requests and APIs, okay, if you're a developer, that's really what you wanna do. How do I reduce the meetings and move it into this more productive mindset where we're working on the system as opposed to talking about the system, right? And I think this is maybe one of the missing pieces of truly building a strong developer experience is making it so that that is incredibly transparent. People see the interfaces and the boundaries of the service and they have a platform where they can, they're not constrained, but they're enhanced. So you might have three databases that you offer as part of your platform and some team truly absolutely needs a fourth type of database. Do you tell them to wedge it into your platform or do you let them go and do it themselves? Well, if they go and do it themselves, they need to take responsibility for reliability, performance, monitoring and all these other things that the platform provides. And if not, then you do it as part of the platform. And this is the kinds of decisions you have to make as a platform team. You have to decide what's good for the vast majority and then where do we handle exceptions? What kind of rules of the road can we give our team so that they can be productive? And this is, I think, one of the challenges of that is it does require a judgment, right? You have to think hard about these kinds of problems. You don't necessarily wanna be on the far end of the spectrum, like which Google kind of is, which is like, there's one way to do everything and everyone will do it that one way. But on the same time you don't want it to be a complete chaos free for all where everybody gets to pick their own things. So there's a balancing act there for sure. But I think generally speaking, you kind of go with the 80-20 rule, so yeah. Okay, thank you so much for talking about this topic today. And as is allowed, I would love to have you back on the show. Thank you. Thanks so much.