 Hi, this is your host of Limhartiya and welcome to a brand new episode of our series, TFR topic of the month, AKA T3M. And this month's topic is platform engineering, is DevOps there. And today we have with us Jonas Bonier, founder and CEO of LightBend. Jonas, it's great to have you on the show. Thanks a lot. Thanks for having me. And as you know, this discussion going on in the market or ecosystem or industry, whatever place you want to call it, that we are starting to talk about platform engineering now. Last year at CubeCon, there are some booths with a sign like DevOps is dead. But the fact is, I mean, it depends on which camp you are in. So, but before we jump into this much wider discussion, I would like to hear from you, how would you define platform engineering? Yeah, it's a fairly new term. But I think it's sort of, 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, I'm saying 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. You know, it essentially all boils down to that infrastructure is very, very hard today. It's really hard to manage the complexity of the richness of the, you know? So it's not just bad, you know? But, you know, we 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, you know, 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. How is this approach and of course building a platform internally for consumption? But if you look at from the discipline side of thing, practices, you know, how different is it from, let's say DevOps or SREs? DevOps been around for quite a while. And the way, you know, the way I view the DevOps is that it's, it's, it's, there's probably many definitions, but I think DevOps is mostly useful as a way to optimize the development process, getting, getting rigor into it and also optimizing the application in terms of performance availability and scale and ensuring that it, you know, it executes optimally, you know, you can operate it reliably and all of those things. Well, platform engineering is really about optimizing the developer experience. And as I just said before, the developer experience for your internal teams. And so in a, in a, in a way instead of optimizing, you know, things like I said, performance availability, the process and stuff is sort of instead, it gives tools to the developer teams to sort of efficiently tackle these challenges themselves in a way, but through higher level abstractions to most of the decisions being taken already for them limited options, but probably the right options for your organization. So, so it's, it's, it's a little bit of, of difference in terms of goal, I'd say, you know, I mean, but they, they of course blend and overlap a lot. You have been talking about, when you're explaining platform engineering, that it's about developer experience. I want to talk about developer experience, but I also want to kind of quickly address the elephant in the room that is DevOps really dead? And why do we hear that? Of course, you know, it's easy to, I mean, when something new comes out, it is very easy to always think that the, the whole thing is dead. You know, of course, there's very far from the truth, you know, the internal development teams that provide platform engineering, I mean, then they of course use DevOps practices, et cetera. But, but I, you know, the way I view it is that it's, for first, you know, it's of course not dead, but, but I don't think it should be long-term, at least, you know, if we, if we think about this as a new trend that will stay, and at least within large organizations, I don't think it's dead DevOps should be sucking up internal resources from the dead, from the dev teams anymore. And we are increasingly seeing that, that, you know, the ops part of DevOps should be handled somewhere else, or more efficiently handled somewhere else. And I think the reason for this drive is that, is that, you know, even the Kubernetes and, you know, the whole CNCF ecosystem is amazing. You know, we owe so much to it. It's actually easy to forget how good it is, because we're almost taking it for granted now. But it has grown overwhelmingly complex. And, and it's really only the, in my experience, when you're talking to our customers and so on, it's really the most, only the most well-funded developer teams that can really navigate this complexity in a really good way, and truly deliver, you know, ROI quickly to their organizations. And, and I think this is, you know, this is the reason why we start to see no ops talked a lot about a lot. No ops is really, of course, it's not about removing operations, but it's about delegating operations. It has a way to mask the complexity of building these systems for the dev teams. And, you know, thinking about how we got there, you know, serverless was, of course, extremely groundbreaking. I've talked a lot about that in the past. You know, we owe a lot of the, I think the showing what possible in terms of future of cloud development to serverless. So it was definitely groundbreaking, but, but, but it, but it was, it didn't, you know, get us all the way, I think. The, the, the ability to, it's like high complexity and managed complexity for non-trivial mission critical apps is still very hard for most teams. And this is why I really bet, and we at Leipan, of course, also really bet on, on no ops, you know, or zero ops or whatever you want to call it. I think, I think this year is, it has matured and I really think that, that it will, more and more vendors will provide no ops solutions to developers to, to deliver the, you know, just the right set of abstractions. It's, you don't want to abstract away too much, you know, because then you, then you can't do anything useful, but, but like, sort of climbing this ladder of abstractions, you know, something I owe is like a metaphor I'm trying. I'm always using, when I talk about these things. You know, we've been doing that as an industry many, many times. You know, for me, you know, from assembly code, from machine code to assembly code to C, you know, and in the infrastructure space, you know, for through containers, communities, and all the whole ecosystem on top of that, in many different areas. And I think it's, it's time again now to, to abstract overall this great infrastructure that we currently have, simply to set the developers free to, yet again, focus on what's most important. And, you know, one, one thing that that one sort of term that I really believe in, you know, that sort of, or term more of a trend is this infrastructure inferred from code, you know, where you, where you, where you can, based on the code itself, sort of infer the infrastructure needed to, to drive that code, sort of for through annotations in the code or configurations and stuff, but that you simply just that the developer only need to focus on the code and the infrastructure and everything that needs, it's like inferred from that and managed and sort of delivered by the, by the platform in an like zero ops, no ops way. And, you know, what's really exciting about that and what we see at Leipen is that this really enables smaller firms to compete on equal ground with larger organizations, which is, which I find is quite, quite, yeah, quite amazing actually. What do you really mean by developer experience number one? Number two is that what companies can do to improve their developer experience? And number three is that, how does that fit into platform engineering? I think this developer experience, I guess it's a word that probably has many definitions and depending on who you ask. But for me, I think it's, it's probably two things, you know, first is like this sort of the sum, in a sort of an abstract way, sort of the sum of the responsibilities that we ask of a developer team. And that combined with the tools and, you know, the enabling practices that are available to meet these responsibilities. So it's effectively getting the job done. And, you know, it's, I have to say again, you know, it's like the more responsibilities that we put on the developers, the less focused time they can have on writing business logic, especially the driving the application forward in terms of features. So in a way, you know, that, you know, this, so that means that, you know, they can't move as fast and then you have to add more resources to get where you need to be, which means more is going to be more costly for the organizations, essentially, et cetera. So I really think that it's like, you know, everyone wants to move faster and time to market is very important today. And, you know, speed is still a competitive advantage. But also, you know, we see a lot that the companies are trying to reduce cost. So, you know, and balancing these is very hard. And I think if you get confused by the cloud native infrastructure space and, you know, and get stuck there, then you simply can't move as fast with the small amount of resources that you might have. So I think that's why the focus on developer experience is so important and is arising yet again, you know, as one of the more important things. And, yeah. So can you also talk about, you know, how does this platform engineering approach also enables, you know, teams to bring back that developer experience to them? You know, platforms and platform engineering is really all about having a qualified team internally to build out a platform that abstracts away all the complexities of not all, but most of the complexities of the underlying infrastructure and a team that understands the business in the company that often and hopefully, you know, also what each, you know, team, development team in the organization is trying to accomplish, which might be different in different companies. But, you know, I think the benefit here is that you have one skilled team that are able to provide the right abstractions in terms of developer experience for each one of these teams or the collective needs of their development teams. And taking, because if you have, like if you're overwhelmed with the decisions, you know, perhaps not all decisions to be taken at the lower level, some decisions might be key to actually take higher up, but deciding on what to abstract and not to abstract and what to delegate to the developer teams to take control over and what to take, you know, once and for all by the internal developer platform. I think that's something that is, it's a skill, but that's, you know, it's through the essence of platform engineering. And through that process, you know, you come up with the best developer experience for your internal teams. And as I said, that will look different for different organizations and perhaps different developer teams that you're trying to serve through this internal developer platform as well. But it's all about optimizing the speed as you can, each one of these teams can deliver features and not being overwhelmed by a choice and drowning complexity. What advice do you have? Because what happens in today's world as you were talking about, we are talking about Kubernetes, a lot of new technologies are coming out and a lot of new companies, they get all overwhelmed. Hey, we have to now embrace platform engineering. They don't even know what platform engineering is. And so, what is your approach? How they should approach, you know, these kinds of practices so that they don't start with, hey, that is a big buzzword we should embrace. They should start with, hey, what are we trying to do here? And I start off the question. So, what is your approach for them for what is your advice for them to approach platform engineering in the right way? First, I think you need to understand if you really need platform engineering. They're, I mean, it is a big investment and we've seen it used for a few years and not always succeed, at least that I've seen. And it's, so it is a big endeavor for sure. I think it can really maximize the value long-term, but it's not something that should, like a decision that should be taken lightly, I think. There are public platforms and public services that can give you some of that. Of course, they are not tailored for your organization and for your specific needs. But if they are general enough, you know, no ops type of solutions, service type of solutions, infrastructure, from code type of solutions, you know? We're building one in LightBend, I think that can serve our type of customers very well. But I think you should start with, you know, one level up, you know, I mean, everyone wants to move faster and it's really about simplifying and abstracting and try to automate as much as absolutely possible. And I think that is true more today than ever. You know, if we just look around, you know, it's like we're living in a world that's sort of shaking by a lot of global changes, you know, that impacts, of course, businesses, but also we as humans and society, you know, with things like wars and conflicts and, you know, still lingering pandemic and we're going into recession and et cetera. And of course, all these issues are interwoven and they multiply, you know, by the impact of each other and they affect the businesses, you know, at the same time, as I said before, companies still need to deliver features fast to customers. That will never stop, that will always be the case and speed is a competitive advantage and so on. But at the same time, we need now I think more than ever this year, you know, manage costs and resources, you know, many large corporations are laying off, you know, thousands of people and it's because everyone realizes that we need to manage the cost. Still we need to deliver features for our customers. So, you know, that brings me to my passion and that's really about abstracting, you know, climbing this ladder of abstraction, do more with less and provide solutions and developer platforms that help developers to focus on the code. If that is through some sort of internal developer platform or if you reach for more general platforms that are available, you know, that's the decision, each organization need to be making themselves. But the key is here, like try to delegate as much as absolutely possible, you know. And often when you ask engineers, they like to do, they need to agree to details because it makes them feel empowered and they like the control. But so my message to a lot of these engineers like let go of control, you know, you actually don't need to turn every knob. You don't need to have control over everything. Have some faith, you know, and delegate. Let it free you up to focus on the stuff that really matters, I think. Benas, thank you so much for taking time out today and talk about this topic. And as well, I would love to have you back on the show. Thank you. Thank you very much. I really enjoyed being here and talking with you. It's a topic I'm very passionate about. So thank you.