 Hi, this is your host, Saptan Bahartiya, and welcome to another episode of T3M, our topic of this month. And topic of this month is infrastructure as code. And today we have with us once again, Rob Herschfeld, CEO of Rec and Rob. It's great to have you on the show. Swap, I'm excited to be here for one of my favorite topics. Exactly. When I was working on this series, you know, your name popped up first. I was like, okay, maybe this actually a series is too fully dedicated to you and Rec. And we have talked about infrastructure as code so many times. And, you know, we have some lengthy discussions about it. Talk a bit about how do you look at infrastructure as code? How do you use it? And is it different from how others use it? I do think we treat infrastructure as code. And this is a RACN phenomena, but it also comes back to my conversations in the industry. We look at infrastructure as code as much more of a process focused thought instead of tools. So our idea is that the operations team wants to be more like a development team in that how they approach management and automation of their infrastructure. So a dev test prod, high degrees of reuse, a lot of modularity, stop inventing custom stuff all the time, have high reuse, strong APIs, you know, those are the things to me that really drive infrastructure as code processes and practices, not where sort of a lot of people get stuck, which is can I describe my infrastructure in YAML and then submit it, you know, and then store it and get that to me is so low on the hierarchy of infrastructure as code. It's almost laughable. Before I was talking to you, I was recording a show and the team that they gave was that has DevOps kind of lost its luster. So when we look at infrastructure as code, once again, talk a bit about some of the, as you said, practices, processes. What does it mean from these cultural movements? What does it mean for DevOps? And, you know, what DevOps teams can do to once again look at things more like code. It's interesting because DevOps is also a very process statement, but it's very focused on collaboration as the core piece for what makes DevOps DevOps in my mind. It really is this idea that the team should be working together this introduction of the concept of a pipeline of going from a developer into production. And to me, a lot of what we've evolved to from a DevOps perspective is this idea of pipelines. One of the things Racken really promotes is this concept of an infrastructure pipelines. Very similar concept, but connecting together all of the pieces and parts that are necessary to run your infrastructure. And this is one of the things that people often forget when they're dealing with infrastructure. Infrastructure is not one thing. It's actually a connected series of different components, different services, different capabilities for an enterprise, especially on premises, bringing systems online and operating them is usually 10 to 15 different systems that all have to be orchestrated to make that work. And that's where the pipeline comes in. If you're using cloud, people use Terraform. If you looked inside your Terraform plan, the Terraform plan is actually a mini orchestration that's connecting together all of the cloud services for you. And people overlook the fact that there really are a lot of moving parts that have to be connected together. So this idea of pipelining all of the services is very compatible with what DevOps looks at from connecting together or pipelining together different teams and making them work together. They're incredibly compatible components, sort of different conceptually. I think just because there's a discipline involved in infrastructure is code that DevOps teams welcome, but it's a different thought process. And I've been listening to you. I also remember the whole series that we did on infrastructure as code and there was a whole episode dedicated to just collaboration. And once again, you mentioned collaboration a couple of times. Talk about the importance of collaboration and why do you focus so heavily on collaboration? It's one of the things that sort of the formation story for rack and there was was the reason why we started the company is because when we were doing operations work and bringing automation into customer environments. When we were when we were forming it inside of a team at Dell, what we kept finding was that we would bring in automation and then the automation would end up unique at each customer. And so as we improve things, we couldn't help each customer improve. We couldn't share things back. We couldn't work within our teams. And when as rack in one of the things that we find when we work with customers today is that each team is an automation silo. And they have trouble sharing automation between their teams, even if they're doing very similar things with very similar infrastructure. So I look at the amount of waste and frustration, time, toil, right? All these all these complexity all these problems that we have in our in our day to day lives as operators and on the infrastructure side that are exacerbated by the idea that we're not collaborating. We're not reusing each other's work. We're not able to take advantage of the great automation of the team sitting next to me or the company sitting next to me. In a way that allows us to benefit from that shared work. And that is a significant problem, right? I have a strong history in open source and when in open source we try to solve problems together. And it has always been frustrating to me that operations teams have a lot of trouble or before rack in had a lot of trouble actually sharing and reusing code. And that's been a big focus for us as sort of the formation story for rack in is addressing that collaboration story, you know, at the automation level. When we talk about automation, we cannot talk about the big elephant in the loop these days, which is genitive AI, you know, gen AI, LLMs talk about its role. Is it going to help or hurt? This is one of those alarm bells that I've been been trying to sound for people is that, you know, we see people get very excited about LLMs and using code generation techniques. And it works actually very well. I've done some talking about this and shown some demos, but the challenge is that if you're not careful, it's very easy to have the LLM generate a really significant amount of technical debt, meaning code that is generated for one use that isn't maintained by a person is not designed to be maintained by a person is, you know, you're not able to then reuse that. So if you're using LLMs to repeat info code that you might already have, you might generate it very quickly and you might say, I didn't want to reuse code that I already had. I was able to generate new code and it's great and new automation and that's great. The challenge is that everything that people build automation and code wise has a life and has a life cycle to it. So unless you're using LLM for truly throw away scripts, you're potentially walking into cases where it would have been a better investment and we're working to make LLMs help do this to find examples of scripts that already exist where you can say, oh, wait a second, somebody is 90%, 95% of the way there. I can use the LLM to help me understand, interpret, extend and add to the code, the automation that I already have and then collaborate with the people who own that original code. So now you have one piece of code servicing both people. It is definitely a danger that we're running towards, I wouldn't even say walking, we're running towards this idea that we're going to have more and more bespoke automation. We did a roundtable recently where we heard from financial operators in the financial services area and one of the things that stunned me was they were like, it's not that we don't have enough automation. We actually have too much automation and so if we turn around and have LLMs magnify that effect and create even more, we really run the risk of just this explosion of unmaintainable infrastructure. And I think most people already feel like they have more automation than they know how to maintain and more infrastructure than they can track. So we're going to have to use LLMs a lot more carefully to solve that problem or we're just going to race to the bottom fast. Can you also talk about what kind of trends you're seeing in the context of ISC in the ecosystem? ISC is definitely very well entrenched. One of the challenges that we see from a trend perspective is that people keep working in silos here. They take something like a terraform and then they wrap terraform in an orchestrator and then have to then bolt in Ansible or some other automation configuration or bash scripts or things into that system. And so what we see is we see a lot of really interesting tools that get people very excited, often centered on terraform, which is a HashiCorp open source project. And so what we've seen here is that there's a lot of enthusiasm for solving these in siloed dimensions and they add a lot of value doing that. What the challenge is that we're not seeing the collaboration on the other side. So as people start looking at these tools and taking advantage of this infrastructure, they really need to be aware of how do we reuse this technology. It's very common for me to talk to a platform team at an enterprise that has thousands and thousands of terraform scripts and are trying to figure out how to consolidate that work. That's the purpose of the platform team and sort of the growth of platform teams, which is another trend line that I see. But the platform teams themselves are a response to this automation sprawl that we've been creating. And so we have to be careful not to take control away from people, but definitely to encourage a reduction in the sprawl because ultimately it just becomes a challenge and a security issue, a compliance issue, a governance problem when you have a lot of duplicated automation running around. And so that's been something that we're tracking and we're seeing as much as people are enthusiastic about all these tools, they're starting to scratch their head on the governance side of it. And can you also talk about what role is Reckon playing in once again helping organizations kind of embrace these practices, these processes? I appreciate the question. We took an infrastructure as code approach and architecture even before it was called infrastructure as code. We've had several names for it in the past. And at the very foundation when we built the system and I think this is important for thinking how this works. Infrastructure is code thinking, right? The ability to have immutable artifacts, get processes, dev test prod, right? Share and reuse components. So the composable modularity of the way we build automation is designed in from the very start. And that has been a critical piece to how we build a digital rebar or product and make it so that when people build automation, they're able to leverage the existing infrastructure pipelines that we have in place. The processes, the methodologies, the ability to have a very concrete dev process so that when you go into production, every all of your automation is immutable and locked down. I focus on that a lot because it ends up creating a really significant value in ROI because nobody wants variation and change or uncontrolled code in their production environments. And so being able to have these infrastructures code processes, some GitOps and know exactly what's deployed in which places and have ways to manage that and describe it and collect the information. Those are actually the underpinnings of infrastructure is code. Those process controls and gates and really empowering people. And I can tell you that the ROI that the teams who adopt these practices right through digital rebar or through their own process. The ROIs are really significant. Their operators are much more productive. Their infrastructure is more reliable. It's more robust. They're able to create compliance reports and actually tell people what they're doing. They can respond to security issues much more quickly. They actually can rebuild their whole infrastructure from scratch in an hour or two. These are game changing impacts and how people manage and run infrastructure. And they're very real. We see customers. People don't think financial institutions are particularly high achieving IT organizations. They're wrong. They're remarkable IT. They spend a lot and they invest a lot and they do a lot of work in IT. But we've seen just dramatic turnarounds on how quickly organizations can get things done and how reliably and how much especially in highly regulated organizations, how much they can be confident that they know what's going on and they can quickly respond to issues. Rob, thank you so much for taking time out today and talk about, as you said, our favorite topics. Thanks for all those insights. And as usual, I would love to chat with you again soon. Thank you. Thank you, Swap. I appreciate the time and I'm looking forward to our next conversation.