 what I see consistently is developers want to develop, right? That's what gets them up in the morning. That's what gets them excited. They want to build these applications that have an impact on their customers or on their business or whoever they're supporting. And I think anything that gets in the way of that is an issue for them. Hi, this is your host, Soplin Bharti and welcome to you. Let's talk. And today we have with us Mark Krister, VP of Strategy of Progress, Chef. Mark is great to have you on the show. Thanks, Svangal. It's great to be here. Yeah. And I was looking at the kind of topic you suggested what we should discuss today. And it was like, has DevOps lost its luster? So I will like, when I look at the topic about, hey, this is interesting, which also kind of threw me to a lot of discussion that I have. We do talk about all these culture movements. And we say, you know, DevOps should not even be in your job title. It's kind of process. You know, it's like practice it within teams. So just these are labels. But if you look at the basic word that is going on is, you know, the dev teams creating new packages, new software that adds business value, and then ops team, we actually run that. And that takes me to the old time of Linux sys admins, you know. So if you look at it, that we can change all those like fashions, but there are certain specializations will also be there. People will always be specialized in networking, storage, security is a very specialized field. And, you know, we like to do certain things. So before we get into deeper into this discussion, what I do want to hear from you as you talk to a lot of customers, clients, but you keep an eye on the ecosystem, how we have seen the evolution of developers, dev teams, where they are trying to balance themselves between, you know, that own what you have built, like the whole developer culture versus maintaining a distance from operations, because we talk about dev ops, we talk about DevSecOps, a lot of things are moving in developers pipeline with shift left. So talk about what you're seeing there. You know, I think what I see consistently is developers want to develop, right? They that's what gets them up in the morning. That's what gets them excited. They want to build these applications that have an impact, you know, on their customers or on their business or whoever they're supporting. And I think anything that gets in the way of that is an issue for them. And so, you know, we've moved to agile and now we're moving to dev ops. And the whole notion of being able to reduce the amount of time it takes to set up the infrastructure. As you talked about it, you know, doing maintenance or being involved in the security aspect of it. So I don't think there's resistance for developers to do those things. They just tend to want to develop. And I think, you know, there's a lot of good things happening with dev ops. And of course it was tongue in cheek in terms of whether dev ops has lost its luster, because it can be very important and shares a lot of values with what's happening with platform engineering as well. But I think the key is just to automate and provide self service is what developers are really looking for. How is the whole ecosystem making it easier for dev teams so they can continue to focus on building, you know, application that at business value and remove a lot of complexity that comes in the way? Yeah, I think it's a great question. And I think especially a lot of times what we see is as people move to the cloud or try to adopt cloud native technologies like you said, Kubernetes, then they do that kind of hand in hand with a dev ops implementation. And you know, our desire is to be able to have a single dev ops framework that works regardless of where your applications are running, what type of applications you're running, whether you're, you know, in the public cloud, hybrid cloud, whether you're managing applications on the edge, no edge devices point of sale. It's really using a single framework that we define or like to refer to as policy as code. So policy as code provides the benefits of human readable. So it helps people collaborate across different siloed teams, but also machine enforceable. So that's really the core of the automation. So that's, that's kind of what I think about in terms of, of how people are moving forward with relative, you know, relative to like cloud native and making that transition. If you look at organizations, how they are embracing these practices, like when we talk about dev ops or platform engineering, and these are like, there are tools also, but mostly these are practices, cultural movement. And we cannot just paint every organization with a broad, you know, stroke, depending on how big you are, depending on, there are a lot of early adopters, there are a lot of companies who are very, you know, beginning stage, they are still embracing it. But broadly, what kind of trend you're seeing how organizations are kind of embracing deploying dev ops and platform engineering principles, or they are still struggling. Hey, what is dev ops? What is platform engineering? When I look at kind of the foundation of each, you know, they're while dev ops, dev sec ops, I don't think there was a lot of vernacular around developer experience. It really was trying to improve the experience for everybody involved in the development side from dev to IT ops, and then to from security as well. I think automation is at the heart of all this as well. So automation in terms of automating configuration, checks, compliance checks, and then to auto remediate as well. And then we see that, you know, on the foundation of policy as code, which can be extended to what's happening with platform engineering, because, you know, we want to use smart automation to allow developers to kind of do the things that only they can do and automate the, you know, the routine, the redundant stuff that we need to do. And I think the other thing that ties the two movements together is really this notion of self-service, you know, which is going beyond kind of self-service for organizations, for developers to do code, test, and deploy, but also to bring in the security aspect as well. What happens to developer experience, you know, because that is also very important. How can organizations kind of maintain a balance between two, with all these things at the same time, kind of also maintain a developer experience? So they continue to do the kind of things they need to do. I think it's really, you know, getting the right set of tools and practices in place. Like you said, you know, DevOps is not just around technology, but a lot of this around process and culture. So I think kind of working together holistically to put together the right set of tools that constitute that platform versus thinking of it as a heavy weight platform, you know, you can even go to, you know, this notion of composable services. So, you know, it's kind of, I hate to go back to service oriented, but, you know, the more things change, the more things, the more they seem to stay the same. So services oriented component based is really important for that as well. These days, we all talk about generative AI, you know, gen AI. It can be seen in two ways. One is, of course, new workloads that are leveraging. At the same time, it may also move in developer pipeline where they will start leveraging it. And this is already happening, you know, generative AI, I mean, AI has been around for a long time, but generative AI can also become a very good tool to kind of, you know, it's like it's going to kind of augment their work, not like take it away. How do you see, it may be too early, that generative AI will also help these teams, DevOps team, developer teams, DevOps teams to further improve their processes. So once again, they can focus on higher level of stuff. From our perspective, being a chef, you know, DevOps vendor, obviously, when we get in and we're using our tool set to actually help organizations kind of speed development and productivity, we collect a lot of information, right? And of course, that's secure and it could be on premise. So it's not access to information that we're worried about, but it's the potential to mine that data to help in some ways get to automation. But even before you get to automation, being able to mine that information to do some of the things that you mentioned in terms of SRE and being able to kind of measure their efficiency and how fast that they are developing great experiences. So I think for us, I think it's let's walk before we run, let's not get overly hyped on a all things to AI, but let's think about more practically what we can do. So I think the first thing is a use the data that we have more effectively and analyze that with whatever algorithms are available to bring the most value out of that data. And then over time look for areas where we can automate processes either with or without AI. It's really kind of how do we automate, use the best technology to automate? Sometimes we jump on the AI machine, but there's a lot of automation that can be done even without AI. What kind of trends you're seeing in this space where you're like, you know, yes, Kubernetes has solved the problem, it has become not the next because you still need the Linux kernel there, but it has kind of become a stable piece of technology like kernel or you're looking at some other technology which are emerging, which you feel will be disruptive again in this space. You're right. And you alluded to this. First of all, you need to pick the right technology for what it is that you're trying to do. And sometimes an older technology is just perfectly fine. I mean, but you know, for us, organizations are really just trying to develop things faster, speed delivery, and, you know, and being able to get to the cloud and being able to leverage, you know, all the benefits of the cloud and, you know, with the right architecture. So I think really what's driving the success of Kubernetes is really the architecture. The architecture model, you know, is really efficient. It allows organizations to kind of build things, you know, and construct them together from components with it. But, you know, I think the thing that people struggle with the most is how do they manage that? And so I think, I think before Kubernetes really takes off, it's going to take, you know, a lot of work on each team's part to figure out how best to organize, you know, and to move forward with that. So, you know, I guess I'm not answering your question about what I think, you know, AI, of course, is out there. But I think, you know, it's not so much what's the latest technology, but what, how do you string together the right mix of technologies, which is really back to, you know, a lot of work that people do around the software development lifecycle, you know, they're thinking about, well, what should I do for CICD, what should I do for testing, what should I do for so on and so forth, which is the right thing. But they want to, should extend that to what needs to happen on the ITOPS side, you know, on and down the road, like observability and infrastructure management and even load balancing to make sure you've got the right security built in. So I think it's, I think I don't focus so much on what the bleeding technology is, it's how do we get the existing technologies together in a way that really drives the most productivity. What would be your advice, what would be the right approach for organizations to build internal culture, which will be about, of course, the whole devos, platform engineering, SREs, chaos engineering, so that irrespective of what kind of technologies come in, the organization is prepared, you know, one of the footage in like something stable, and they can still keep dipping their toes in the shiny object. No, that's a great question too. I mean, there's a lot of different ways to kind of get started, but, you know, and you're right, like, some people are resistant to change. And so I think it's almost starting small, right, get the right people involved in your dev ops or platform engineering efforts and design the right framework that they plan to use to propagate out to the rest of the organization and be very thoughtful about change management, you know, cultural issues and things like that. And I think at some point, you know, don't oversell what the end point is going to be. But I think, you know, if you see how hard it is for organizations to hire and retain people, the best people, I think the best people want to go to an organization that's thoughtful about these processes, is thoughtful about how best to structure the work, what tools to use that will allow them to really, you know, to be their best at work. So I think kind of focusing on the long game. And then there's no end, right? You don't put together a dev ops project plan and say, okay, we've achieved dev ops, it's continuous work that you need to do to keep on top of things. Like you said, swap in terms of new changes, new technologies, but we can always improve, right? We can always learn from what we've done in the past and make small incremental changes, which is another good thing about platform engineering. It's not in dev ops, it's not, you're just going to gain efficiency in one area. You have the potential to, you know, gain efficiency in everything that you do. And those maybe small efficiencies end up to be something significant for the business. Can you also talk a bit about the role that you see of progress chef in this space? How you folks are, once again, making it easier for teams to consume these latest technologies without having to worry about the complexity? That's a great question. I mean, as most of the viewers know, I mean, progress chef has, well, chef has been, you know, instrumental in terms of the dev ops movement, progress acquired chef a number of years ago. And we want to think very holistically about not only dev ops, but kind of infrastructure management. And so we complement what we do with chef. And, you know, we're way beyond just doing configuration management. In fact, our bigger focus in terms of what our customers are doing is all around compliance. So once you've got something configured correctly and it meets your policy, then continuous scans in terms of making sure that that configuration hasn't drifted, and then auto remediating that and then being able to use that same approach on cloud assets as well out to the edge. But I think kind of going forward, it's, it's, you know, looking beyond that to say, okay, what else do we need to do with network monitoring and observability application lifecycle management. And to kind of think about that holistically, just like you piece together the SDLC tools, think about how that infra ops or infrastructure management capability can be brought together. Because that's really how you're going to get layered security. That's how you're going to meet your, you know, zero trust requirements and to be able to move the organization forward by both delivering applications, but making sure they're secure and compliant. Mark, thank you so much for taking time out today to talk about this cultural shift and tech tools and everything else. And I would love to chat with you again soon. Thank you. That'd be awesome. Thanks so much.