 Hi, this is your host of LimbHartia 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 once again, Rob Hershfeldt, CEO and co-founder of Reckon. Rob, it's good to have you today for the show. It's a pleasure. And this one's a really important one for enterprise users, so I'm excited to dive in. When we talk about this DevOps versus platform engineering debates, who is driving this evolution? Where is it happening? Is it happening at customers? They are talking about it. It is with the open source communities. Is it with the vendors? I want to understand what is the ground reality? What is driving this movement? I'm glad you're taking that approach because the platform engineering work that we're seeing is entirely a customer driven, enterprise driven trend line. This is what enterprise CIOs, DevOps teams, infrastructure and operations teams are calling their internal efforts to rationalize the internal infrastructure platforms. And that is a very real problem for them. It has incredibly significant cost, governance, self-service optimization impacts. So the business drivers behind this are very real. They're very pressing. And they're in some ways a consequence of those same teams telling development teams what I would call an app dev team to go do whatever they need to do to be productive. And they're now coming back and saying, whoa, wait a second. Infrastructure is hard. Complexity is hard. Controlling costs is hard. There's a lot that goes into that side of the business that is really real. The other side of what you talked about, the DevOps is dead messaging and this proliferation of dev self-service portals, that is much more vendor facing. So there is a degree of this very real enterprise trend and enterprises looking for help and trying to do this work. And enterprises doing real work does attract a degree of vendors looking to show up with the easy button for those enterprises. If I ask you, how would you define Platform Engineering? What is it? So Platform Engineering actually has two different sides to it to me. And I think part of what I look at is this side of saying enterprises have been given the directive to create self-service environments for their active teams. That is part of Platform Engineering and it's a big part of it. But on the other side, and they've been building products or trying to create products that service developer self-service needs from that perspective. On the other side of it, there's also a drive within these companies to consolidate and add more centralized control over how the infrastructure behind those efforts is managed. And that is also part of this Platform Engineering system. So the Platform Engineering includes both the, how do I enable dev self-service without overly constraining developers, and as an infrastructure and operations team, how do I build and rationalize consolidated control over all of the different infrastructure requests that I have coming in? And Platform Engineering is really ends up being a product management function of delivering that type of service. Because at the end of the day, companies need products that are on word here because there's no one product that's going to deliver it, even Rack End doesn't have enough scope to solve all these problems. We don't want to have enough scope to solve all these problems. But from an enterprise perspective, they actually need to start thinking about this as a product management problem. Which APIs are we going to do? What features they have? How do we offer those features? How do we deliver it? It's really this advent of defining the relationship between the app dev teams and the back end infrastructure in a productized way. That's the really significant part of how all this Platform Engineering sort of works, is that productization or this standardization approach. We've also started talking a lot about developer experience. What is developer experience? And what is its role in Platform Engineering? Or how Platform Engineering enables teams, organizations, to bring back that developer experience? When we look at this problem space, there's two sides to it. There's an app dev experience, what I would call developer experience. And there's an operations experience, which has the unfortunate abbreviation of OX. So not many of us are calling it an OX from that perspective. But what we're really looking at here is the developers need their tools, their interfaces to be ones that work for them. Hide a lot of the complexity, give them very simple interfaces. And it's incredibly varied. And this is one of the challenges of the developer experience. Developers might want to interact through Git, where they're doing GitOps. They might want to interact through a simple dev portal where they have a template and they can click a button and get infrastructure or get things built for them. They might want to interact through a ticket. They might want to interact through a Kubernetes API or a CLI. They might want to interact through any number of ways that they're actually going to do that work. A CI CD platform might do most of their infrastructure requests. Behind the scenes and the developer never even sees it, they just check things in to Git. And so what we're looking at in the challenge here is that from a developer experience, it needs to be self-service. It needs to have the developer's interest. It needs to be simplified and streamlined. And it's not a single thing. And this is, I think, the challenge that platform engineering teams are starting to recognize. On the other side of it, the operations experience can't chase all of those different experiences. They have to have something that comes back to a platform where they can consolidate that work. And they can actually help developers, no matter where, they choose to interact with the systems. And that really becomes sort of the paradox that platform engineers are chasing. There's developer experiences that they can't easily control and dictate. And they don't want to become like, you have to use my portal to do your work. That doesn't fly very well. But at the same time, they can't service the infrastructure differently for each app dev team. They need to start consolidating that work into a consolidated, governed operations experience that actually exposes the infrastructure and shows people complexity and lets them do audits and track things and security patches and things like that. All that has to come in at the operations level side. And so from that perspective, when we think about traditional DevOps, we're not trying to mash one team together to do all the work. We're actually starting to recognize developer experience and operations experience are separate. That doesn't mean that the teams don't talk and collaborate and work together. That's absolutely critical, which is what DevOps is really about. Just means that we're not trying to throw all of the operations work on a dev team or all the dev work on an ops team. We're respecting some boundaries here. How are vendors approaching this paradigm shift of that platform engineering? As you also said that no single vendor can solve all the problems for the customers. So what are vendors doing there or from Racken's perspective? We're seeing a lot of vendors who are chasing the dev portals and looking at a dev portal as a platform engineering solution. And those typically have very lightweight orchestration. They have some very lightweight interfaces back into infrastructure, maybe the ability to run Terraform. But it's not really an operations tool, it's really a dev tool. And I think that makes sense because a lot of developers, a lot of vendors want to do the dev access systems. On the other side of the, there aren't really a lot of companies that want to do the operations interactions because frankly, it's really hard and complex and the operations teams have to deal with all that real complexity. So a company like Racken, where our bread and butter is helping make reliable automation and build end-to-ends workflows for customers that tie back into all of that complexity and expose the complexity so that you can manage it in a repeatable way. It's not as fun a space, but it's actually a real lift for customers. And that's sort of how we see this market being bifurcated. There's a lot of sort of vendors chasing that dev space, not as many chasing the ops space. Let's also look at smaller customers. Sometimes when they do see these movements, they get overwhelmed, they get scared, they get worried because sometimes a lot of messaging is also needed. So how should they approach it? And also once again, the bottom line is what is actually going on internally because the way they operate is totally different than the way big players operate. It's interesting. A lot of the big teams have the same problems that the small teams do. So I don't think in this case it's really that different because neither is able to drive the dev teams with a whole bunch of prescriptive solutions. So I think the big difference between the big and the small is that in a small team, a lot of times you'll have one development effort where they have started this process, they've been doing the infrastructure work and if they're doing whichever group is doing infrastructure best, might become the platform team or might have that, the platform they're using might become the standard platform that that group is trying to use or that company is trying to use. And so they end up having a different motion here to standardize and work through that standardization process. The bigger companies typically are looking for ways to, they have more bottoms up management, they have more tops down management where the executives can come in and say we have to start rationalizing these things and they're a little bit more siloed. So it's easier for them to start from an operation side and then start working with the application development teams. But either way, it's politically very challenging because what you've got to be able to do is have the app dev teams give up a certain degree of control and autonomy on the infrastructure side that they might be used to. Typically in a bigger company, those teams are not particularly excited about governance and security and audit and cost management and all those things that are coming in as part of a platform engineering drive. And so we do see the bigger companies a little bit more concerned about that. But either way, as long as, once you have two app dev teams, you actually have a need to start thinking about how platform engineering is gonna start to optimize these pieces. And it can't start just by putting dev portals in front of people. You have to have some understanding of how it's gonna scale. I also wanna talk about something contemporary which is, of course, this is all contemporary is that we are also looking at a lot of layoffs. Teams are getting smaller. How much impact it will have on this platform engineering approach or it is actually very well aligned with or for smaller teams, tightly knit teams. We are definitely seeing companies trying to pull back on how much infrastructure and automation work they're doing from that perspective. Like there can scale back app dev teams. It's very hard to scale back operations work because operations are actually embedded in running the system. So it's hard to stop a system and therefore it's harder to stop an operations piece. But every company we know, this is true before the layoffs and it really hasn't changed now that we're trying to be better and more efficient with using people's time and talents is that we have to be able to automate things in a more consistent way across teams. And so if you take an app dev team and they're looking at scaling back their resource utilization both in people and in actual consumption of cloud or consumption of infrastructure, the place where they're gonna wanna do that is they wanna be able to say, oh, maybe I can take these automation engineers, DevOps people that I have on my team and move them back into a centralized function, right? We've had conversations with enterprise customers where they were trying, they had 10 full-time Terraform engineers and they were trying to hire another 30 full-time Terraform engineers. So it's not a question of losing people. It's actually a question of, not having to hire a whole bunch of engineers who are frankly impossible to find and then pull them back and consolidate that work. So this is why platform engineering has been going on for years inside these enterprises. They cannot hire the automation people that they wanna hire. They don't wanna push it into devs. The devs really don't want the work, especially in a slowdown, the devs are having enough trouble staffing the positions they have. So we're looking at ways that we can take that automation complexity, turn it into a skill set that is repeatable across multiple app dev teams in a shared resource. And that is a very high urgency in enterprise, right? How do I take skill sets that are hard to find and expensive and make them into shared resources instead of siloed resources? That, fundamentally, you wanna definition of platform engineering. That's the definition of platform engineering. And the economic component is huge. One of the things that I've been thinking about lately is when we build automation, we don't do a very good job of doing it in a shared reusable way. And it's one of the things that Rackin really spends a lot of time thinking about is how do I make automation from being custom team by team by team or company by company by company and finding ways to make it economic to reuse automation or have automation that is reusable across teams, across companies, across different infrastructures. That really changes the economics here, just like what you've been getting to here is that if you can take automation that one team is successful with and use it across your organization, then that creates tremendous value impacts. It also makes it easier to maintain the automation over time, fix it, patch it, be reassured that if one team finds an error, you can translate it to other teams. If you have to apply a security patch, you can do it uniformly. Frankly, the way we've been doing app dev support right now is just not sustainable. And that's what platform engineering is really finding out. You have to have a consistent way to secure and manage your infrastructure without interfering with the app dev effectiveness. How are companies approaching platform engineering or if you look at relatively small or newer companies, how they should approach. So if you have any advice or suggestion for them. Good starting point is for companies to recognize that they've already been doing this work. They just haven't been doing it very formally and effectively. So I think the first thing they need to do is start actually realizing that this is a formal function that they need to think about from an IT and operations perspective and then start looking at it as a product management perspective. How can I create a standardized API that all of my app dev teams can consume in a uniform way? What changes do I need to make to rationalize how these pieces are going, look for the low hanging fruit? Frankly, most companies that I know of have been building platform engineering efforts for years. In a lot of cases they build them, they're not that successful and they shut it down or they move over, they have competing ones within an organization that are ultimately duking it out. Companies need to recognize that and actually control and manage how those functions work. And the nice thing now is that they can actually start looking to the market for some support. We as RACN can come in and actually take a lot of the infrastructure API burden off of somebody by providing a uniform API. It's not gonna reduce the amount of operations work that you have to understand, but it is gonna make it much more uniform and consistent across the board. It gives you an API that makes it easier to consume or look at how you can take dev portals that you might have written by yourself and start migrating into more standardized bi-vendored infrastructure portal or migrate people into a more consistent front-end system to do that. Migrating developers to use different front-ends is a challenge that they will come to you with dev front-ends. It's much harder to dictate that. So for most of these enterprises, helping automate the back-end in a consistent way is actually an easier path because it's less disruptive. Rob, once again, thank you so much for taking time out today and cover this topic this month and I am looking forward to discussing new topic with you soon. Thank you. Thank you, Swap.