>> Welcome to The Cube Startup Showcase made possible by AWS. In this session, we're going to dig into how organizations can improve governance and use AI to increase confidence and trust in their software delivery process. My name is Dave Vellante and joining me is Nick Durkin, who's the field CTO of Harness IO. Nick, thanks for joining. >> Thank you so much for having having me on here. I appreciate it. >> Give us the overview of the company, let's, let's start with what you guys are all about. >> Yeah, I think when you look at Harness specifically, it started as continuous delivery as a service. And we really have grown from that and become a true modern software delivery platform. And with everything that we deliver, we do this with artificial intelligence and machine learning in mind, to remove all of the tasks that we hate. No one wants to babysit deployments. No one wants to sit there and watch tests run that we don't need to run. And so really taking an artificial intelligence approach to software delivery. >> Great. Let's talk about software delivery and maybe we can dig in to some of the trends that you're seeing, maybe the drivers that are leading people to new approaches, you know, some of the challenges that customers face which are also opportunities. >> Absolutely. You know, it's interesting. We look at everyone on their journey for software delivery and traditionally velocity is actually what brings people into to either deploying faster or we need to get and modernize our platforms quicker. And so velocity is the driver traditionally to bringing new tools and new technology. And what's interesting is that governance while equally, if not more important, that's often second fiddle. And so what we find is that customers go on a journey where they use their CI tool and they expand it. They use their open source offerings that they have from modern technologies to create velocity and go fast. But then what they quickly find out is they have to govern this. And whether that's for regulatory purposes or whether that's for just internal processes, right? This becomes the hard part. And a lot of people have to script it. And if someone's actually able to achieve say velocity and governance, this is where now we're reaching, you know, speeds now that we actually wanted. So we're now deploying end times end faster, our monoliths are turning into microservices and we're actually deploying infinitely quicker. And now this becomes a problem because we don't know what broke what. And so if you can achieve velocity in governance, the next problem that people have is traditionally quality. >> Yeah, so you know, that lack of governance, that's a real challenge because you're now seeing even more stress as data becomes prone to those same processes, DevOps for data, if you will. So now you got the whole privacy and governance slamming together, and people want to automate it as fast as they possibly can. So this puts even more stress on developers. And I think your point is they've got to go faster, but that's antithetical to quality. So therein lies the conundrum, but the answer is automation, machine intelligence. Maybe you could double click on that. >> Yeah, sure. No, that's exactly it. If you think about it, there's not enough people at these companies to sit there and look at the knock and understand what normal looks like. There's not enough people to look at every line of log to understand what's going on and what broke. And this is where you can start leveraging artificial intelligence to understand what does normal look like. And when you think about it, they are traditionally opposing forces, velocity and governance. But the reality is when we talk about software delivery, oftentimes people will say and bring in tools, people, processes, and tools are people process and technology. And the reality is it's all entirely about confidence in your people. And whether it's a tool or whether it's a process that provides that confidence, if that's what they're looking for is confidence that their developers can deploy when they want to as needed. And if something goes wrong, it will be taken care of. And so back to your point, Dave, specifically, when we think about software delivery, we think about continuous delivery we really mean automate everything. Right? From start to finish. And that means with all of the guard rails and all the rules that you need for governance, so that you can meet those security requirements, you meet those regulatory requirements while still empowering developers. >> You know one of the other things that obviously has changed in the last 10 years is cloud and cloud adoption, and cloud costs, everybody looks at their bill at the end of the month. They go, okay, I love it because of driving new business models, but hey, can we figure out how to control these costs a little bit? What is the role of developers in terms of controlling cloud costs? How can they impact that? >> Sure. No. If you think about this whole shift left paradigm, and we're now empowering developers to do more and more, what we're not giving them is the inputs that they need to effectively do their job. If you want engineers to care about costs, it's something they need visibility to. If you want, if you want the administrators to function out of, you know, a cost mindset, it needs to be something that's part of their daily information that they have. And today that's not how it works. Today a CFO will call down and say, hey, we're spending way too much money. You know, I just got one. We spent over $35,000 on some test clusters and I got a phone call from our CFO. Just like everyone else does. And then we had to go fix it. Instead of giving people who honestly would do no wrong if they had the information in front of them, giving them that information. So if you solve velocity with governance and now even solve for quality, the next thing that you have coming is cost. You're now going to be deploying infinitely faster to the cloud with so many changes that you can't keep, can't keep track of it. And you need that same auditability that you'd have with a governance platform to show you what you're changing in cost. So now what you want to do is empower the same engineers to know what changed they made, what it modified, how it affected it, but also how it affected costs. And if you give that to the engineers and the people that can affect change, it's amazing what happens. >> I want to come back to this notion of data challenges, because applications are increasingly more data centric. You put your data in the cloud, great, but then people realize, oh, the clouds expanding is going out to the edge. And so data by its very nature is, is distributed. People want more control of the data, the lines of business, the domain experts that it's self service that creates a new problem around governance. And when I talk to practitioners, what I'm hearing is as they embark on this journey, because everything used to be, you know, shoved in one place, a big monolith, and that's a limiter to scale. What they'll do is they'll phase it. They'll say, okay, phase zero, we're kind of process builders. We've got to figure out, okay, how is governance is going to work? And then as fast as they possibly can, they'll codify that so that they can automate it. Do you see that evolution in, in governance? How is it playing out in your world? >> Absolutely, I think, you know, you made mention of data and really data has gravity. But to your point, what we find is that people want choice. Right? What drives where they place their data, where they place their applications. It's on choice, it's on a lot of different things. And one of the things that we found is that to that point, if you can't define those processes, those policies, those procedures, to meet your governance in any of the clouds, this becomes now a burden on your employees. If they only have it for one specific location, whether it be on premise or whether it be in the cloud. Now you have to move to another cloud, or to another place. Now it's just all that much more rework. And the reality is the tooling that you have should allow you, or allow your engineers to deploy wherever is needed, whether it's on Amazon or Azure or, or, you know, primarily when we think about it all over the different Amazon and pieces, when we want to go and I want to deploy to say Amazon EKS or EKS anywhere, and I want to have them physically on the data center, or if I want to have them, you know, up in the cloud, this shouldn't be something that our engineers have to care about. Whether I'm putting on an ECS or on, on EC2 instances. Those are things that our engineers shouldn't have to care about, and the governance should allow you to do it to the appropriate locations when required. So what should happen, ultimately, if you, if you craft this accordingly, this should be designed so that at any point in time, your engineers can't make that mistake. They can't put data in the wrong place. They can't put applications in the wrong place because the governance will hold them to it. And you'll know why, so that you can fix it. And if you create that type of behavior, then there are no mistakes, right? Allow people the freedom to deploy. And as long as they do it within the rules, it'll work. >> I wonder if we could bring up that previous slide again and talk about the velocity of the governance, the quality and efficiency, which, which is most important when you talk to customers? >> Yeah, absolutely. I think depending on where they're at in the journey, velocity might be the thing that's hurting them right now. We have to solve for it. In which case let's go grab a whole bunch of open source tools and let's go grab all the things that we have and start scripting things. And what we find is that oftentimes customers come to us when they realize I've got all this, but now I need to make sure it's governed. And this is where it's hard. And that's where people will actually, you know, if you will, phone a friend, and look for some help, because this is complex and it's not something you want to do on your own, especially if you've been doing it for the last nine years, you don't want to do it again for a new technology or a new space. And then when we think about it, if you've actually achieved governance, which a lot of say, like regulatory, you know, based customers have, quality becomes their part, where they need help. And so really it depends on where the customer's at in their journey, but I can guarantee you, everyone's looking for one of these four pieces and that's, what's their bottleneck right now. And it's really being able to provide the resolution to any of those bottlenecks out of the gate. Right? You want to make sure that if you have that coming, you're, you're prepared for it. And you have a tool that can help you as you're going to progress in those phases. >> If I understand it, your strategies, that will help customers optimize wherever they are in that journey. You know, they might be in a cloud migration. It's like, hey, we got to go fast, let's go. And then their attention is going to shift to governance. And then eventually as they get more mature, it's going to be okay, hey, we've got this down. Now we're going to lower our cost and be more efficient. So let's talk about how you do this, here's a graphic that really speaks to your platform. Nick, why don't you walk us through this? >> Yeah, sure. I think when you think about software delivery, we traditionally will think about CI and CD. And so I think that's where we can start, but there's a lot more to software delivery. And so that's what we'll offer different pieces. One of the benefits of the Harness Platform, it is not, you're not locked into every single part and piece. You already have different technologies that you want to use by all means, use them, but we do offer you those technologies if they can help. And every one of these is designed around that idea and understanding of AI and machine learning at its core. So if you think about it, we started life as continuous delivery as a service. So taking what we would consider artifact to customer. And that's really what we think about when you think about continuous delivery. And in there, we want to think about all of the things that happen after delivery, the same way your best engineers would. So we're going to look at your performance metrics and the business metrics that you have. And we're going to think about them the same way, your best engineers would, but we're also going to look at those logs and understand exactly the same way that yep, that's fine, that's fine. Hey, what's, what's that over there? And this is where we use AI and ML not to do what people love doing, but to do what people hate doing, which is babysitting deployments. When you think about CI, we traditionally think about code two artifacts. So that's the first part and there, Harness, we acquired Drone, the most loved open source CI tool on the planet. And I can't make that up because, you know, you can go to GitHub and actually look it up. So people comment on this and we decided to invest in it, quadruple the team, and then add all of those security governance quality pieces to it. And then even one step further, add some more of that artificial intelligence. Dave, I'll ask you a direct question. If you were to change to the gas cap on your car, would you, after you change that, would you go check every single electrical device and electrical switch on your car to make sure it works? >> I hope not. (laughter) >> You hope not, right? But the funny thing, and the interesting thing is that when we do tests today in our CI tools today, if you make one change, our customers, or actually every customer, is testing everything every single time, instead of being more intelligent about it and only testing those things that matter. And so again, bringing those costs down, bringing that effort down and bringing that toil down across the board, this stands true for feature flags. If you want to get into more granular things and say complex deployments, you want to do this with feature flagging, to allow different customers, to be able to turn on and off different features for different regions or different reasons. Now, this is built into the same tooling where you can apply it to a pipeline and then have that verification after. So you really get that opportunity and that ability to use AI, to do what people are manually calling customers and determining whether it looks okay or are waiting and looking at, you know, output on a screen, now you can have machine learning, handle it for you. And really this is where it's designed to, as you move through that and any type of change that you wanted to do, whether it be in databases or in different network topology and using that same machine learning and verification. And then last thing that cost piece, a lot of people will say that a cloud cost tool does not belong in software delivery. And if you believe in shift left and you believe in giving people all the inputs, and I think you'd probably disagree, you'd actually fight yourself on that and say, it does probably live here. And that's what we want to bring that data, and not only visibility, we want to bring recommendations on how to fix it and bring actionability. So actually start taking action right away to bring costs down. >> Yeah but see you're not just making software delivery better. You're rethinking the approach. You're not just paving the cow path, sometimes I say, you're not doing that. You're reinventing, you know, to use an AWS term. >> Well, we actually did that specifically. When we said we wanted to build continuous delivery. We wanted to do it in a way and in a shape that wasn't copying the way that other CI tools had done it with expanding CI. We said, you shouldn't have to know what, how to write complex deployments. You shouldn't have to care whether you're on an EKS cluster, that's on premise or, or up in the cloud, your engineers shouldn't have to care and we should extract that from them. Right? And that's what we did there. And so to your point with all of these pieces, yes, we're rethinking them. We're not going ahead and just taking and paving that same path, like you said, we're truly trying to make it usable and viable for those that can use it. >> What do people buy from you? Is this a subscription? Is it a consumption-based model? How does that all work? >> Yeah, great question. So it is, it's a subscription and ultimately we're a software delivery company, but we're continuous delivery company. So unlike other people that will talk to you about, you know, updates and new versions and new pieces, we deploy a new version of our software at least once a day, we practice what we preach. And if you're going to continue to deliver software with somebody who doesn't do it themselves, you should probably ask yourself how, if they can't trust themselves to do it, are you going to? But the reality is depending on what you need, you only have to pay for what you need. So it's not like other platforms where you have pay for everything and only only use a part and piece of it. So for every aspect that you want and, or need, you're more than welcome to use it. And, I'll say something that my sales people probably don't like, but you know, we've never lost a deal on cost, right? We're here to show you value and ultimately make sure that it can help you and your customers, and that's what we do. >> Well this is clearly the trend in software pricing. We're seeing it's true cloud pricing, it's consumption pricing, it's you, you seem to have got it right in a, in a hot area that's why the investors are getting behind you. Nick Durkin of Harness IO. Excellent, thanks so much for your time, thanks for your insights. Really appreciate it. >> I appreciate it. Thank you so much, Dave. Thank you for having me on. >> You're welcome. Okay you're watching The Cube's Startup Showcase made possible by AWS, new breakthroughs in dev ops data analytics and cloud management tools. Keep it right there. (soft music)