 Hello and welcome back to theCUBE's coverage of KubeCon, CloudNativeCon 2021. I'm John Furrier, host of theCUBE with David Nicholson, our cloud host, analyst, and it's exciting to be back in person in an event. So we're back, it's been two years with KubeCon and Linus Foundation. So it's a great big hybrid event. And we have a great guest here, CUBE alum and Nick Durkin, field CTO of Harness and harness.io's, the URL, love the .io. Good to see you. Thank you guys for having me on. I genuinely appreciate it. Thanks for coming on. You were a part of our AWS startup showcase, which you guys were featured as a fast growing, mature company as cloud scales. You guys have been doing extremely well, so congratulations. But now we're in reality now, right? Okay, CloudNative has kind of like, okay, we don't have to sell it anymore. People buying into it and now operationalizing it with cloud operations, which means you're running stuff, applications, and infrastructure as code. And it costs money. Yeah, Martín Casada at the Antries and the Horses. Oh, repatriate from the cloud. So there's a lot of, there's some cost conversations starting to happen. This is what you guys are in the middle of. Yeah, absolutely. What's interesting is when you think about it today, when you want to shift left, when you want to empower all the engineers, when you want to empower people, we're not giving them the data they need, right? They get a call from the CFO 30 days later, as opposed to actually being able to look at what change I did and how it actually affected. And this is what we're bringing and allowing people to have is now really empowering. So throughout the whole software delivery lifecycle, from CI, continuous integration, continuous delivery, feature flagging, and now even bringing cost modeling and cloud cost management. And even then being able to shut down the services that you're not using. How much of that is waste? We talk about it at every single cloud conference, it's how much is waste. And so being able to actually turn those on, use those accordingly, and then take advantage of even the cheapest instances when you should, that's really what we're trying to provide. It's so funny, people almost trip over dollars to pick up pennies in the cloud business because they're so focused on innovation that they go, okay, we got to just innovate at all costs, but at some point, you can make it productive for the developers in process in the pipeline to actually manage this. That's exactly it. I mean, if you think about it, to me, in order to reach, say, continuous delivery, we have to automate everything. But that doesn't mean stop at just delivering to production. That means to customer, which means we've got to make them happy. But then ultimately, all of those resources in dev, in QA, in staging, in UAT, we have to take care of those as well. And if we're not being mindful of it, the costs are astronomical. And we've seen it time and time again with every company. You've seen every article about how they've blown through all their budgets. So bringing it to the people that can affect change, that's really the difference. Making it visible, looking at it in depth, not just at the cloud level and all the spend there, but also even at the, think about it at the Kubernetes level, down to the containers, the pods and understanding where are the resources even inside of the clusters and bringing that as an aggregate, not just for visibility and giving recommendations, but now more importantly, because it's part of a pipeline, start taking action. That's where it's interesting. It's not just about being able to see it and understand it and hope, right? Hope's not a strategy. Acting upon it is what makes it valuable and that's part of the automate everything piece. Yeah, well, at the dawn of the age of DevOps, there was a huge incentive for a developer just to get their job done to seize control of infrastructure. The idea of infrastructure as code, you know, when it was being born, it's fantastic. I've always wondered though, be careful what you wish for. Do you really want all of that responsibility? So we've got responsibility from a compliance and security perspective and of course cost. So where do we go from here? I guess is the question. Yeah, so when we look at building this all together, I think when we think about software delivery, everybody wants to go fast. We start with velocity, right? And everybody says, that's where I want to go. And to your point with governance, compliance, the next roadblock to hit is weight. In order to go fast, I have to do it appropriately. I've got governing bodies that tell me how this has to work. And that becomes a challenge. It slows it down too. It does. I mean, basically people are getting pissed off. This general sentiment is that developers are moving fast with their code and then they have to stop. Compliance has to give the green light, sometimes days. Correct. It used to be weeks, now it's days. It's still unacceptable. So there's like this always been that tension between the security groups or say IT or finance was like, slow down. And they actually want to go faster. So that has to be policy based something. Yep. What is your take on that? My take on this is pretty simple. When everybody's talking about people, process and technology, it's kind of bogus, right? It's all about confidence. If you're confident that your developers can deploy appropriately and they're not going to do something wrong, you'll let them deploy all the time. Well, that requires process. But if you have tooling that literally guarantees your governance, make sure that at no point in time can any of your developers actually do something wrong. Now you have something. That's the key. That's the key. Giving them a policy based guardrails to execute in their programming moment. And that's it. So now you can free up all those pieces. So all those bottlenecks, all those waiting all those time. And this is how all of our customers, they move from change advisory boards that approve deployments to change. Give us some customer anecdotal examples of this in action and kind of the love letters you get or the kudos. Yeah, the delighted customer. Sure. Take us through a use case of how it all plays out. So this is one of my favorites. So NCR, national cash register, if you slide a credit card at like a Chick-fil-A or a Safeway, right? Traditional technology. But what was interesting is they went from doing PCI audits, which would take seven days to go to a PCI audit, right now with Harness because every- And by the way, when you in the sixth day, the things that you did on day one changed. Exactly. Exactly. And so now because they're using Harness and everything's audited and all the changes are controlled to make sure that developers again can only do what they're allowed. They only get to progress to production if they've met all their security requirements, all their compliance requirements, all their quality checks. Now, because of that, they literally gave a read-only view of Harness to their auditor and in three hours it was over. And it's because now we're that evidence file from code commit through to production, it's their fault. Point of sale compliance. Right. So what's the benefits to them? What's the result? Saves them time, saves them money. What's the- Sure. They get to free up more times. Obviously they chopped it down, that's key. Yeah. That's actually something we didn't build in like our ROI calculators, which was we talked to their engineers and we gave them their nights and their weekends back, which I thought was amazing. But Thursday night when we're doing that deploy, they don't have to be up. Harness is actually managing and understanding, using machine learning to understand what normal looks like so they don't have to. They don't have to sit and look at the knock or sit in the war room and eat the free pizza. Yeah. Right. And then when those things break, same concept, right? So Harness gets up. So I got to ask you while I got you here. You know, as the software developer, delivery lifecycle is radically being overhauled right now, which people generally agree that that's the case. The old models are different. How do you see your vision around AI and automation playing into this? Because you could say, okay, we're going to have different kinds of coding styles. This batch has got an AI block here. It's very Lego block like. Yep. Okay, services and higher level services in the cloud. What's your reaction to how this impacts automation AI? Sure. So throughout our entire platform, we've designed our AI to take care of the worst parts of anyone's job. Ask any DevOps person if they love babysitting deployments. They don't. Harness handles that for them. Ask your engineers if they love sitting there waiting for their tests to run. Every time they build, they go get coffee, right? Because we're waiting for all of our tests to run. Why? Right, the reality is. And sometimes they have to wait days. And that's it. But like if I changed a gas cap on your car, would you expect me to check every light switch and every electronic piece? No. But why do we do that with code? And so our AI, our ML, is designed to remove all the things that people hate. It's not to remove people's jobs. It's actually to make their jobs much better. How do you guys feed the data? What's the training algorithm for that? How does that work? Yeah, actually it's interesting. A lot of people think it's going to take a ton of time to figure this out. The good news is we start seeing this on the second deployment, on the second build. We have to have a baseline of what good looks like. And that's where it starts. And it goes from there. And by the way, this isn't, a lot of people say AI and they say ML. I teach a class on this because ML is not standard deviation. It's not some checks. So we use a massive amount of machine learning. But we have neural networks to think about things like engineers do. Like if we looked at a log and I saw the same log with two different user IDs, you and I would know, well it's the same thing, it's just different users. But machine learning models don't. So we've got to build neural networks to actually think like humans so that we can provide it for them. So that's the whole expectation, maximization kind of concept that people talk about? Well that's it because at the end of the day, like I said, I'm not trying to take people's jobs. I want to make their jobs easier. Yeah, you want to do the crap work out of the way. And I add to other redundant heavy lifting that they have to do every single time. That's the cloud way. We built mechanical muscle in the early 1900s, right? And it made everyone's jobs easier. It allowed them to do more with their time. That's exactly what we're doing here. I mean we've seen the big old guys in the industry trying to evolve. You got the hot startups coming out. So you got, you know, adapter dies. Classic thing we've been seeing for many years, David on theCUBE, you know that. So it's like, this is a moment of truth. We're going to see who comes out the other side. How do you, Nick, what would you be your kind of guess of when that other side is? When are we going to know the winners and the losers? Truly in the sense of where we are now? So I think what I've found is that in this space, specifically, there's a constant shift. And this is something with software. And the problem is that we see them come and ebb and flows, right? And very few times are there businesses that actually carry the model. And what you find is that when they focus on one specific problem, it solves it now. If I was working on VMs a few years ago, great. But now we're here at KubeCon, right? And that's because it's eaten, eaten that side of the world. And so I think it's the companies that can actually grow the test of time and continue to expand to where the problems are. And that's one of the things that I traditionally think about harness when we've done it. We cover our customers where they were, like the old mainframes that we had to, where they were, where they are at their traditional, their VMs and where they're going. I mean, if you think about it, I think it's one of these things where it's like, that's such a common sense way to look at it, involves where the problems are, ride the right tech ways. But if you think about the high order bit here, it's just applications. I mean, at the end of the day, companies have applications that they want to write. Modern, the applications of their business is going to be codified. So that if you just work backwards from there, then you say, okay, what is the infrastructure as code working for me? That's an ethos of DevOps. And that's where we're at. So that's why I think the cloud need is kind of one already, but we still have the edge devices, more complexity. This is a huge next level conversation. At one point, we just put a hard and top on the complexity. When is that coming? Because the developers are clear, they want to go fast, they want to go shift left and have all that data, get the right analytics, the telemetry and the AI, but it's too complicated still. This is a big problem. It's too complicated. You're asking for a full stack developer to also know infrastructure, to also know edge computing. Like, it's impossible, right? And this is where tooling helps, right? Because if you can actually parameterize that and make it so the engineer doesn't have to care, they can do what they're best at. Hey, I'm great at turning code into artifact. Let them do that and have tooling take care of the rest. This is where our goal is. Again, allow people to do what they love. And this is kind of the new roles that are changing. Look at what SRE has done. Everyone talks about the SRE and some say it's just as the DevOps guy, but it's not just that. There's also different roles emerging. It's an architectural game at this point. You would say, would you say? I'd say a hundred percent. And this is where the decisions that you make on architecturally, if you don't know how to then roll them out, this is what we've seen time and time again. You go to these large companies, I've got these great architectures on plan and four years later, we haven't reached it. Because to that point, they've gone- They cut the process. The process killed them. Four different new tools throughout the process as well. So when do we hit peak Kubernetes? Peak Kubernetes. I think we have a bit to go in and I'm excited about the networking space and really what we're doing there and bringing that holistic portion of the network. When Istio was originally released, I thought that was one of the most amazing things to truly come to it. And I think there's a vast space in networking. And so I think in the next few years, we're going to see this turn into that a hundred percent utilized across the board. This will be that where everyone's workloads continue to exist, somewhat like VMs were in the past. And no fear of developers as code in the very near future. You're talking about automating the mundane. Correct. There have been stories recently about the three day work week. As a fan of utopian science fiction myself, as opposed to dystopian. Absolutely. I think that technology does have the opportunity to lift all boats. And it's nothing to be afraid of. The fact that I put my dishes in the dishwasher and they run by themselves for three hours, it's a good thing. It's a great thing. I don't need to deal with that. Agreed. No, I think that's, and that's what I said in the beginning, right? That's really where we can start empowering people. So allow them to do what they're good at, do what they're best at. And if you look at why do people quit, we demo up to people who are so hard to find. Yeah. Why? Because they're second target babysitting deployments and they're told everywhere they go they're not going to have to. That's the line. And that's the line. All right, we've got to break, but it's great insight to have you on the queue. One final question for you. I got to ask about the whole data as code. Something that I've been riffing on for a bunch of years now. And as infrastructure as code, we get that. But data is now the resource everyone needs. And everyone's trying, I had a control plane for this and that, but ultimately data cannot be siloed. This is a critical architectural element. How does that get resolved in the land of competitive advantage and lock in and whatnot? What's your take on that? So data is an interesting one because it has gravity. And this is the problem. And as we move, as I think you guys know, as you move to the edge, as we move at places, there's insights to be taken at the edge. There's insights to be taken as it moves through. And I think what you'll see honestly going forward is you'll see compute done differently. To your point, it needs to be aggregated. It needs to be able to be used together. But I think you'll see people computing it on its way through it. So now even in transport, you'll start seeing insights gained in real time before you can have the larger insights. And I see that happening more and more. And I think ultimately we just want to empower that. Nick, great to have you on CTO, Field CTO of Harness and harness.io's URL. Check it out. Thanks for the insight. Thank you so much. Great comment there. I genuinely appreciate it. A natural cube analyst right here, Nick. Of course, we've got our analysts right here. David Nicholson. Working me out of a job. You're good on your own. I'm John Furrier, you know me and the host. Thanks for watching. Stay with two more days of coverage. We'll be back after this short break.