 Hi, this is your host of Limhartiya and welcome to a brand new episode of our series, TFI 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, once again, Leon Lee, developer advocate at Loft Lab. Leon, it's great to have you on the show. Hi, thanks for having me again. Before we jump into this discussion, I'll ask you, how would you define platform engineering? I would say that a platform is a product and platform engineering is really engineers who work on a specific product that is targeting developers. If you look at internal, the problem that companies are trying to solve with writing the code, deploying the code, securing the code, optimizing the code, what exactly is happening internally and then how do you look at these labels? It's very good that you bring up the word labels because that is what it is. Sometimes it's the same thing, but we give it different labels. And sometimes that's driven by marketing concerns, maybe. Just give it a new name to make it sound hot, and then it's 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 shifting away from this idea of DevOps and saying, 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. Can you also talk about the importance of having or bringing back the developer experience? Yeah, 100% totally makes sense. I would actually argue that developer experience, developer happiness are new concepts, new ideas. And even like the concept of not just building something that's new and exciting, which is, you know, like I used to be an engineer as well, and that was just super fun, like using new technology, building something, like solving a problem in a new way. But then sometimes you forget that in the end, you are solving human problems. You're solving problems for humans, and it's more important that they can use your product in a way that works for them, rather than, you know, like having the newest technology, you know, blockchain is a good example for a problem that's kind of in search, a solution that's kind of in search for a problem still. There are some applications right now, but still it's kind of like being put on stuff that is not necessary. And I feel like with the kind of advent of platform engineering, that's becoming, that's moving more to the foreground, like developer happiness, developer experience, how do we make the infrastructure work for the developers rather than, you know, just using something that's cool and fun for us as platform engineers to build? What are companies doing these days to kind of improve the developer experience while not compromising with what is being delivered to the end user? As we talked about developer experience, developer happiness is becoming more into focus. And especially if you're looking at a developer works 40 hours a week, no matter how efficient they are, if you can improve their velocity, that's a win for you. And things that you can do is, you know, providing better tooling and just trying to understand the developer as a customer, as an internal customer for your own, let's say platform team or infrastructure team, and thus kind of like making it more accessible to developers to do their job. Especially when we say that developers should focus on developing, then, you know, they need to be given kind of the, all the possibilities to succeed at their job. If you look at, you know, industry right now, a lot of layoffs are happening, which also means that teams are now smaller. What impact it is going to have on teams? You know, once again, maybe look at these labels because that also means that, you know, people will have more responsibilities, but that also means that things are getting mature kind of, you know, so talk a bit about the impact and is it going to actually make things better? Yes, I agree with, you know, all the layoffs happening and tech companies kind of are trying to slim down, cut away the fat, as they like to say. Yes, I could imagine that maybe some companies are going back to, you know, wanting those unicorn engineers, those full stack people who can do everything. And as we talked about already, now we're trying to like move away from it again and like having everyone focus on their own things, but then that's a very difficult, that's very difficult for me to kind of say for the future where things will be going. I think it really depends on the company as well. Are they a developer-first company? So are their customers developers themselves or are they catering to end users? Because once you, if you cater to end users who are not developers, then the quality of your, for example, APIs does not matter as much as if you are first and foremost marketing to developers. But then again, I feel like the kind of the advent of platform engineering and developer platforms is not stopping. So that idea will continue probably also because it makes a lot of companies a lot of money, just to have this idea of, oh, now we're not doing DevOps anymore, we're not doing SRE anymore, now we're doing platform engineering, which I don't think it needs to be an either or, but in terms of getting people excited about things and having talks to give and having webinars you can have and like these kinds of interviews, I feel like there's just so much velocity and energy behind having these conversations that I don't think that they will go away. I think it will just continue down the line and unfortunately some smaller companies maybe will get picked up and go away. You have been in SRE for a while, what advice do you have for these startups companies? How should they approach these labels? So once again, as we were talking earlier, the whole idea is to create a product and bring it to the users. I would say don't get caught up in the hype, like really evaluate is this paradigm of this product really solving the core problem of my business. I see a lot of companies or I used to as a consultant were all wrapped up in these like new technologies, maybe because they have really good engineers who are just very interested in getting into that space, but then they are, let's say like an online shop or something like their core business is not hosting a Kubernetes cluster. So why are you putting that much time and effort and money into doing that? So I would say that is like an advice that I would have. The other thing, and as I said before, in the end we're solving human problems and in my personal opinion, code, writing code, that's a byproduct of solving a problem. If you can solve a problem with no code or less code, that is always better because code is cost, code is technical debt and the less of it you have, the better. If you can solve something by design, that's always better than just putting more technology on top. Since you brought the point of no code, low code, I also want to bring the point of open source because as the layouts are happening, teams are getting smaller. It's kind of, there is no need to do it yourself or not invented here syndrome. Leverage as much open source as you can and most of the open source to enterprise space, they also have backing of a commercial vendor. So you can always go to a vendor and then since it's open source, so you can always pick and choose, you will not be logged in there. So how do you see the kind of growth or adoption of open source will also grow not only just because of this microeconomics but also when we are trying to also use these labels and responsibilities. I'm a big fan of open source. I am a strong proponent of it. I think it's proved to me that people don't need to be paid to build great things. They just do it out of the love of the craft and like making things better for themselves and the people around them and the communities. I do see that there's a lot of open source adoption by big companies and I'm glad that a lot of companies are also giving back rather than only consuming and using open source technology without paying for it be it with money or just with like labor. I think that I agree with you that you don't have to build everything in house but then again having open source projects is a huge marketing factor as well that cannot be underestimated. We see it with for example Spotify has backstage and that's a huge thing for them to establish themselves as a company that really cares about the community. Whether it's true or not, I don't know but it's just a huge boost and makes you attractive to other engineers who you might wanna hire or just like have good will in the industry. So I think that maybe using open source or contributing to open source is almost a luxury that startups might not all startups are able to afford but bigger companies let's say Red Hat or doing a lot of enterprise level open source. I think that this will be something we will see more in the future just because open source is such an attractive marketing vehicle. Can you also talk about that? Why people are talking about or why people think that DevOps is dead? Is it really? Thank you for asking that question. Well, personally, I don't think DevOps is dead. I think DevOps is alive and well. It just relocated, it just moved somewhere else. So first of all, there's a lot of differing opinions about what DevOps means. The way that I always have understood DevOps is that it's a practice. It's not necessarily a job title or anything like that. It's just the practice of developers understanding operations to some extent, understanding how their code or how the application that they built lives on a server. How do I need to configure it? What are things that I need to be aware of when I write my code? Because eventually the idea is that if I understand kind of like where my code lives, it will inform kind of how I write my code and maybe try to be more respectful of the resources that I'm using as an example. So then there was a time when DevOps was kind of superseded by something called SRE or a Site Reliability Engineering. I think that came from Google and to me that sounded like just a rebrand of just regular operations, infrastructure, operations, infrastructure, administration, kind of to me it just sounded like the same thing but like in a new package. So people could write books about it and it sounded really cool. And now I feel like we're entering like the third iteration of rebranding where some companies or some people in the space are now claiming that DevOps is dead. I think the idea is that DevOps, the practice of having devs also be responsible for ops is kind of now entering into a stage where it doesn't seem like a good solution anymore. We have Kubernetes now. Kubernetes is such a great way to abstract all the infrastructure things away from you. So you can just use your infrastructure as if it was code. You just talk to it as if it was just like some other service. So we don't need that idea of DevOps as much anymore. So that's probably why people say that DevOps is dead but I feel like the idea, the underlying idea philosophy of when you write code it's important to understand how it lives so you can write better code. That is still alive and well. And so I do not like that. I feel like DevOps is dead is just like a really marketing way of sounding interesting without really having to provide any value in the message. Leon, thank you so much for taking time out today and talk about this topic. And as usual, I would love to have you back on the show. Thank you. Thank you so much for having me and I'm looking forward to talking to you again.