>>Oh, welcome back to the cubes coverage of coop con cloud native con 2021. I'm John is the Cuba, David Nicholson, our cloud host analyst, and it's exciting to be back in person in event. So we're back. It's been two years with the cube con and Linux foundation. So scrape, it was a hybrid event and we have a great guest here, Cuban London, Nick Dirk, and CT field CTO of harness and harness.io. 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, uh, as cloud scales, you guys have been doing extremely well. So congratulations. But now we're in reality now, right? So, okay. Cloud native has kind of like, okay, we don't have to sell it anymore. People buying into it. Um, and now operationalizing it with cloud operations, which means you're running stuff, applications and infrastructure is code and it costs money. Yeah. Martine Casada at Andreessen Horowitz. Oh, repatriated 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, we want to shift left. When you want to empower all the engineers, we 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 in. Allowing people to have is now really empowering. So throughout the whole software delivery life cycle from CGI continuous integration, continuous delivery feature flagging, and even bringing cost modeling and in cloud cost management. And even then being able to shut down, shut down the services that you're not using, how much of that is waste. We talk about it. 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 >>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 think, okay, we've 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 that. >>That's exactly it. I mean, if you think about it to me in order to breach state continuous delivery, we have to automate everything. Right. But that doesn't mean stop at just delivering, you know, to production. That means to customer, which means we've got to make them happy, but then ultimately all of those resources in dev and QA and staging and UAT, we've sticker those as well. And if we're not being mindful of it, the costs are astronomical, right. And we've seen it time and time again with every company you see, you've seen every article about how they've blown through all their budgets. So bring 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, uh, thinking about it, 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, and giving recommendations, but now more importantly, because 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 is not a strategy acting upon it is what makes it valuable. And that's part of the automate everything. >>Yeah. We'll let that at the Dawn of the age of DevOps, uh, 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, and it's, it's, you know, w when it was being born, it's a fantastic, I've always wondered though, you know, 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, so where do we, 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? 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 doesn't, I mean, basically people are getting pissed off, right? This is, this general sentiment is, 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? Uh, it used to be weeks now. It's days, it's still unacceptable. So there's like this always been that tension to 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. This is the future. What is your take on that? >>Take on, this is pretty simple. When everybody talks 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 to play 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, >>That's the key. That's the key. That's the key because you're giving them a policy-based guardrails to execute in their programs >>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, you know, change advisory boards that approve deployments. >>Can you give us some, give us some, give us some, uh, customer anecdotal examples of this inaction and kind of the love letters you get, or, or the customer you take us through a use case of how it all. >>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? Um, traditional technology. But what was interesting is they went from doing PCI audit, which would take seven days to go to a PCI audit right now with harness, because, >>And by the way, when you and the seventh, six day, the things that you did on day one change. >>Exactly, exactly. And so now, because of using harness and everything's audited, and all the changes are, are controlled to make sure that developers again, can only do what they're allowed. They only get to broadcast two per production. If they've met all their security requirements, all their compliance, permits, all their quality checks. Now, because of that, they literally gave a re 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. Yeah. It's there for point of sale compliant. >>So what is the benefits to them? What's the result saves them time, saves the money. What's the good, the free up more times. I'll see the chops it down. That's the key. >>Yeah. It'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 rates aren't as good. So >>I got to ask you, I got you here. You know, as the software development delivery lifecycle is radically being overhauled right now, which people generally agree that that's the case, the old models are, 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 and >>Sure. So throughout our entire platform, we've designed our AI to take care of the worst parts of anyone's job as Guinea dev ops person. If they love babysitting deployments, they don't harness handles that for them, ask your engineers that 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. Y yeah. Right. The reality >>Is sometimes they have to wait days and >>That's it. But like, if I change the gas cap on, uh, on your car, would you expect me to check every light switch and every electronic piece? No. Well, 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 bill, 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 this AML, 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, >>So that's the whole expectation maximization kind of concept of people talk about, >>Well, and that's it because at the end of the day, we're like I said, I'm not trying to take people's jobs. I want to meet. >>Yeah. You want to do the crap work out of the way. And I had to do other redundant, heavy lifting that they have to do every single time we use the cloud way. We've >>Built mechanical muscle in, in the early 19 hundreds. Right. And it made everyone's jobs easier, 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, adapt or die as classic thing. We've been saying for many years, David on the cube, 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, your kind of guess of when that other side is, when are we gonna 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, is that we see them come in ebbs 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, we're here at coop con, right? And that's because it's eaten, uh, 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. Right. And that's one of the things that I traditionally think about harness and we've done it. We cover our customers where they were, I think the old mainframes, if you had to, where they were, where they are at their traditional, their VM. >>I mean, if you think about it, Nick, it's one of those things where it's like, that's such a common sense way to look at it evolves with a problem. So I ride the right with tech ways. But if you think about the high order bit, here is just applications. We ended the day. Companies have applications that they want to write modern. The applications of their business is going to be codified so that you just work backwards from there. Then you say, okay, what is the infrastructure as code working for me? That's an ethos of dev ops. And that's where we're at. So that's why I think that 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 is that 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. That is a big problem. >>It's too complicated. You ask 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 to the engineers and have to care, they can do what they're best at. Hey, I'm great at turning code in artifact, let them do that and have tooling take care of the rest. This is where our goal is. Again, allow people >>We'll do what they love. And this is kind of the new roles that are changing. What SRE has done. Everyone talks about the SRE and some states just as he had dev ops guy, but it's not just that there's also, uh, different roles emerging. It's, it's an architectural game. At this point, we would say, >>I'd say a hundred percent. And this is where the decisions that you make on are 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 planning four years later, we haven't reached it because to that point process, >>The process killed them four >>Different new tools throughout the process. Well, yeah. >>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, and bringing that holistic portion of the network, like when Istio was originally released, I thought that was one of the most amazing things, uh, to truly come to it. And I think there's a vast space in networking. Um, and, and so I think in the next few years, we're going to see this, you know, turn into that a hundred percent utilized across the board. This will be that where everyone's workloads continue to exist. Um, somewhat like VMs we're in >>And, and, and no, no fear of developers as code in the very near future. You're talking about automating the mundane. Correct. Uh, there have been stories recently about the three-day workweek, you know, as a, as a fan of, um, utopian science fiction, myself, as opposed to dystopian. Absolutely. I think that, you know, technology does have the opportunity to lift all boats and, uh, and it's, it's not nothing to be afraid of. You know, 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. Yeah, I agree. 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 and do what they're best at. And if you look at why do people quit? We don't have to go so hard to find. Yeah. Why? Because they're secondary to babysit and implement and they're told everywhere they go, they're not going to have to >>That's the line. And that's all right. We got a break, but it's great insight to have you on the Q one final question for you. Um, 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 infrastructures could we get that, but data is now the resource everyone needs, and everyone's trying to, okay, I have the 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 the competitive advantage and lock in and whatnot? What's your take on that? >>So data's an interesting one because it has, 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 remove, move it 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. Um, and I think ultimately we just want to empower that >>Nick, great to have you on CTO of field CTO of harness and harness.io is a URL. Check it out. Thanks for the insight. Thank you so much. Great comments. Appreciate it. Natural cube analysts right here, Nick, of course, we've got our, our analysts right here, David Nicholson. You're good on your own. I'm John for a, you know, we have the host. Thanks for watching. Stay with two more days of coverage. We'll be back after this short break.

>> 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)