 Hi, this is your host of Limhartiya and welcome to a brand new episode of our series, TfHire topic of the month, AKA T3M. And this month's topic is platform engineering is DevOps Dead. And today we have with us once again, probably this spot, Senior Product Marketing Manager at Akamai Technologies. Thank you. And the theme this month is platform engineering is DevOps Dead. Before we jump into this topic, of course, there are different school of thought there are different opinions, but if I just ask you, how would you define platform engineering? What it is and how different if it is from DevOps? 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, any DevOps maturity model, broadly speaking, you have, you know, generally five stages where you have no DevOps, you're just starting off, then, you know, level threes, 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, right? So where does platform engineering it's, 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 or the philosophies, of either technical or otherwise. It's actually the opposite. You can think of it, I think in the platform engineering versus DevOps, 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 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 it. 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. Talk a bit about what is driving this evolution and is the platform in the next phase? Or are we talking, we'll still talk about DevOps will be there, SRS will be there, and platform engineering will also be there. I think everything will be there, right? It is very few technologies that you can say have completely overtaken their predecessors. I'll point to FM radio, right? I was driving from Boston to New York this afternoon or this week and I turned on FM radio, right? Despite the fact that I have 5G all the way. So they will absolutely continue to be there. I mean, maybe in 50 years or something, but I think what compels you in what's driving people is the constant pressure is on all sides to do two things. One is, to your point about how software is delivered, you can have more waterfall, even quarterly release cycles if you're mailing out CDs and tapes, not to go too far back. Maybe even a quarterly or monthly release cycles works if you're kind of downloading updates. It doesn't work if you have a SaaS application and I'll broadly throw the word SaaS out as loaded as it is these days, but the Paramount streaming service, right? For that we were just talking about to watch Star Trek. They have to deal with all of these things and it's immediate. They need, the service is not, oh, I can wait for a software update. The is if author there is a bug, they have to fix this now. And I think the driver there of why to move to whether it's platform engineering or DevOps is a response to all these needs because, hey, you have to roll out a patch quicker. What are you gonna do? You're not gonna use waterfall, right? Hey, we have to add a new feature because we have this XYZ event coming up and yeah, we have to roll that out. How are you gonna do it? Well, DevOps tells us that we should compartmentalize and we should test and all that kind of stuff. You're not gonna do it realistically any other way. So I think that's just what's driving everyone to do all of this, right? You have to become more efficient and look everywhere you can to do so. How much evolution is happening in real work because sometimes these discussions happen at different level vendors. Sometimes they orient at user level also. So what are you seeing in the context of platform engineering? It varies based on who you're talking to and on a couple of factors. So in my previous life, I did a lot of architecture for the SaaS providers and they were especially suited for taking a platform engineering approach. The reason for that was that what they had to build was as a SaaS provider and especially these days the way you consume many of these services, right? Think of any business app that you consume. You swipe the credit card and then all of a sudden you get maybe a new host name, certs that match, a bunch of infrastructure for your own instance, maybe it's shared, maybe it's segmented, however they do it. All that stuff has to happen. And what in the background actually has to happen for that nice little, oh, Pavel's new instance of the SaaS app that he just swept the credit card for. In the background, what actually has to happen, there's a lot of provisioning in reality, right? These, most of these don't have a single group, right? It's not like one single monolith they're just deploying, right? Like some war file that they're just duplicating over and over. It's a number of services that's presented via unified UI and that team's usually the one that has the kind of control being the front, being the front and center for customers. We did this with a few folks and we've talked about publicly in blogs, but the challenges there were exactly what we talked about, serving it and giving everyone the capabilities that they needed in a consistent way. So in this particular, I want a couple of the examples, I think a couple of takeaways of how to be a success in that case. Because remember, you have to almost look at it like you're a product manager in some way, but one, they defined the capabilities. They define the interactions, right? Cause if you're a platform engineering group and you say, Hey, everyone, I have got this great way to deploy and manage all my compute and storage and containers and whatever, whatever, right? Your software life cycles, understand upfront kind of what you're going to provide and whatnot and make sure you've talked to all the different groups and they understand what that platform is going to provide, right? It might sound basic like, Hey, agree on the use case, but if you're providing a platform, make sure the expectations and what you're providing are correct. The other piece is you mentioned it earlier, operations is also a thing, right? Once you deploy it, you have to keep it running. So again, if you were the platform engineering team and you have all these different groups kind of using what you put together, make sure beforehand, and this is one of the things, one of the groups who I worked with did a really great job above. It was, Hey, when you need help, again, almost as a customer, here's what we need. We need this information, this log, right? Where things happen. You don't want to do that when it's, you know, 3 a.m. and you just got the page or duty to say like, Oh, it's broken, right? Figure all that stuff out. Again, not to beat that one too much to death, but put on like your fake, not fake, but amateur product management hat. Yeah, you don't have to worry about TAM and all that kind of stuff necessarily, but look at it that way, right? If you want people to use this, which is also not the goal of you building this platform, right? Because the goal of platform engineering is to further accelerate, take all the benefits, right? Your mean time to restore your velocity, all the stuff that you normally measure with DevOps and make that better and bring it to more people, right? Via this platform that you're going to build that takes care of all the infrastructure. So think of it in many ways as a service that you're providing and with that service comes, how do we interact? What do I need when something's wrong? How do I follow up with the team? Because you are trying to get them to use it, right? To see the benefits of what you built. So I think that's a really important example or some things that we've seen to make these platform engineering things successful. And then this is even before we officially called the platform engineering, right? It's just, hey, we're a SaaS company and we need to be able to service 50 different groups with hundreds of thousands or hundreds of instances. If I ask you that, if you have to make a Venn diagram where we look at, hey, we have DevOps, we have platform engineering, we are sorry, we are not even talking about DevSecOps at this point, but if we look at organization holistically, then hey, this is the right approach for that. It's been like, they're a company who are totally into cloud, they're all cloud native. They're a company who are doing a lot of hybrid. So is that a right or wrong where you say, hey, no, for this kind of use case or this kind of approach or this kind of platform, this is how you should go or no, you have to embrace these practices irrespective of where your workload is running. Does it make sense? Where the workload is running becomes interesting. So I think if it's in the cloud, yes, because any cloud, you should definitely consider it, right? Because there's not 100% of the time, but chances are if you've moved things there, right, aside from some lift and shift stuff that may be kicking around, it tends to be a lot more modern distributed kind of architecture, right? And again, aside from those lift and shift kind of cases. So if you're in the cloud, that's probably one on the balance, hey, is this workload? And is this something that I should kind of pursue a platform engineering perspective? Yeah, absolutely. Just because it's on-prem, would I exclude it? No, but what kind of on-prem do you have, right? Do you have a very classic kind of mainframe or you used a lot of web logic and you got a bunch of J2E stuff kicking around or a bunch of internal stuff? Applications that are more monolithic and less distributed and need less updates or have less updates, would I bother with a platform engineering there? No, because I think going back to, last time we spoke about cost is, it's the same approach you wanna be deliberate is, if I do that for let's say my mainframe application, right, if I go through the effort, because there's gonna be some effort, right? Both technical and kind of selling it internally, selling the notion, getting everyone on board. It's a, you know, that's an effort that you should keep in mind when you're pursuing these and judging your overall ROI. There's gonna be some effort, so is it worth it for those? Possibly, because remember, what does it do for you? It improves your velocity, it lets you address bugs more quickly, right? It gets you patches in places, decreases your failure rate, because you catch things earlier with deployment, you can roll back more quickly. So if that applies to your on-prem or cloud environment, great, it almost always, more often applies in a cloud environment. But I wouldn't say the location is the determining factor, it's more so, is your on-prem like, did you go full containerized? In which case, yeah, absolutely, you know, do a platform engineer for on-prem, by all means. If you're, you know, rocking a bunch of bare metal, you know, HP servers from, you know, maybe five years ago that you've long since amortized and just don't want to touch. Don't know if I'd platform engineer those guys. Since this is kind of the team or topic and the whole idea came from CubeCon last year at Detroit that there were, you know, the booth, you know, the DevOps is dead, blah, blah, blah. So I will throw the question, you know, that we do hear, you know, that, hey, DevOps is dead now the time for something else. From, as you said, no, these things really, I want to hear your opinion, is DevOps really dead? No, no, not at all. And I'll throw out a couple of examples. So let's say you are a younger stage company, right? You're starting a gaming, you know, you're taking a run at some gaming app or an OTT or maybe a commerce site or an AI app, you know, insert thing here. So if you take the kind of conventional wisdom is you come up with an MVP, right? You fail fast, you do some sort of flavor in that. Now, going back to kind of what we said earlier, make your decisions very thoughtfully. So do I in that case, if I'm that person, right? We're on that team. And we say, okay, guys, we can put some investment in creating a platform or do we roll out a couple of new features? In that case, and it's a very personal situation. So I certainly don't want to fault anybody who makes any decision, right? Cause it's, it's, it's a very personal or very specific but is platform engineering is spending the time to do that really going to help. And also by the way, how far along are you in your maturity model, right? You don't want to be halfway up the DevOps ladder and try to jump all the way up to, right? If we consider this as a platform engineering as ostensibly an evolution, right? If you're, I just started and I'm starting to implement some observability. If you're kind of on that rung of the ladder, you probably shouldn't just jump up and grab for, you know, two rungs up until you've got optimization, right? Until you blow out your, your whole process a little bit. So I think that's one of them, right? Is relative maturity and this can vary group by group, right? Large orgs have a unit that might be earlier on. So that's one thing to think about it. And then the other thing is think about how much reuse you're going to get out of it. Some of our customers, we see a lot, especially in the gaming space, there's a ton of different technologies that these folks need to use to make it work as to make their apps work as well as they do that when you actually go load a game, you get a match made in a few milliseconds, right? And you can join like that's a ton of work and there's a ton of different technologies. So in that case, if you do have a pretty heterogeneous set of technologies in your stacks and your clouds, trying to kind of unify it all in this one platform that does everything for everybody can be and will likely be a lot harder, right? If everything's like HTTP based microservices, right? You've just got a bunch of containers and 90% of the workloads in your org work that way. Yeah, yeah, it's gonna be a lot easier to do a platform that but if you're rocking VMs and containers here and then some bare metal here, all of a sudden that's a far bigger challenge, right? To be as useful as you can to as broad and a number of people. Again, not to beat this one too much of death but I'll kick the horse one more time. It becomes almost a product management problem, right? And is that where you really wanna go in search of your improved velocity and time to restore? Once again, thanks for explaining that. Now, if you look at the different organizations, they are in different stages of their own journey. And sometimes when we not only talk about these new technologies, when we talk about these new trends, new jargon, sometimes they get overwhelmed that they are trying to figure out, hey, which is the right approach for us. So if I asked you that, what advice do you have for organizations so that they embrace the right path for their own organization for their own journey? We've all been in a situation where you're kind of thinking to yourself, hey, is the reason this technology choice was made was because somebody wanted to work on it. And while that might be fun for home science projects and whatnot, I think the advice I'd give is to certainly avoid that and to be very thoughtful. Before you figure out how, make sure you can answer what. If you put the how before the what or don't have a what at all, you're not gonna know if you've succeeded or failed or even got there, like, should I stop? If you don't know what you're trying to accomplish, right? So that kind of, if you take that approach, the issue of, oh, hey, let's make a platform. If you can't answer why, stop. It doesn't mean you shouldn't, but you should be able to answer why, right? What are you trying to do, right? I've got a bunch of code that I need to deploy quicker or whatever it is for your case. And if you can't answer why, then look at it because like we said, we've seen those situations where like, oh, it's the right thing to do, but technology isn't always about the most popular thing. Like what we were saying before about FM, it's still around because it still serves a purpose, right? We didn't rip all this out because why? Why would you? It serves its purpose. And if that purpose is still valid, then do it. Why for the sake of some resume padding or, hey, our platform uses XYZ, that's really a durable reason for an IT decision. Pablo, thank you so much for taking time out today and talk about this topic today. And I would love to have you back on the show. Thank you. Thank you.