(uplifting music)
>> Hello, welcome back to theCUBE's coverage
of KubeCon + CloudNativeCon 2021.
I'm John Furrier, (indistinct) theCUBE with
David Nicholson, our cloud host analyst,
and it's exciting to be back in person in events.
So we're back, it's been two years with KubeCon
and Linux Foundation.
(indistinct) event
and we have a great guest here,
(indistinct) Nick Durkin,
field CTO of Harness
and harness.io is the URL.
Love the .io. Good to see you.
>> Thank you guys for having me on.
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, right?
Cloud native 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.
Martin Casado at Andreessen Horowitz,
"Oh, we repatriate from the cloud."
So 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 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 life cycle,
from CI, continuous integration,
continuous delivery, feature flagging,
and now even bringing cost modeling
and then 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 every single cloud conference,
how much is waste?
And so being able to actually turn those and 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'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 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, right?
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 and UAT,
we have to take care of 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'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 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 is not a strategy.
Acting upon it is what makes it valuable
and that's part of the automate everything piece.
>> Yeah. Well, at the 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,
when it was being born, 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.
>> When we look at building this all together,
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.
>> John: It slows it down too. >> It does.
>> I mean, basically people are getting pissed off, right?
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. >> Used to be weeks
now it's days, it's still unacceptable.
There's always been that tension between the security groups
or IT or finance was like, "Slow down."
And they actually want to go faster.
That has to be policy-based something.
>> Yep. >> This is the future.
What is your take on that?
>> My 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 something- >> That's the key.
>> That's the key. >> That's the key.
Because you're giving them a policy-based guardrails.
>> Nick: Correct.
>> 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-
>> Give us some customer anecdotal examples of this in action
and kind of the love letters you get or-
>> Yeah, the delighted customer.
>> 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.
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-
>> John: And by the way, in the sixth day
the things that you did on day one change?
>> Exactly, exactly. (John laughs)
And so now, because of using Harness
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 with that evidence file,
from code commit through to production, it's therefore.
>> David: Point of sale compliance.
>> So what is the benefits to them? What's the result?
Saves them time? Saves the money?
They get to the free up more time?
Obviously it chops it down, that's key.
>> 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.
So 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 that 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.
And then when those things break, same concept.
>> So, I got to ask you while I got you here,
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 different.
How do you see your vision around AI
and automation playing into this?
Because you can say
we're going to have different kinds of coding styles.
This batch has got an AI block here.
It's very Lego block like.
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?
The reality is-
>> John: And sometimes they have to wait days.
>> And that's it, but if I change the gas cap 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 RML 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 that 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, a lot of people say AI and SAML,
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-
>> 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 we're...
Like I said, I'm not trying to take people's jobs
I want to make their jobs easier.
>> Yeah. You want to get the crap work out of the way
and other redundant heavy lifting that they have to do
every single time, that's the cloud way.
>> We've built mechanical muscle in the early 1900s
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, adapt or die
is classic thing we've been saying
for many years David on theCUBE, you know that.
It's like, this is a moment of truth.
We're going to see who comes out the other side.
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 in ebbs and flows.
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 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 and we've done it.
We cover our customers where they were,
like the old mainframes if you had to,
where they were or where they are,
at their traditional VMs,
and where they're going.
>> I mean, if you think about it Nick,
it's one of those things where it's such a
common sense way to look at it,
evolves with a problem so I ride the right tech ways.
But if you think about the high order bit here
it's just applications.
At the end of the day
companies have applications that they want to write.
The applications of their business is going to be codified.
So you just work backwards from there then you say,
okay, what is the infrastructure as code working for me?
That's the ethos of DevOps and that's where we're at.
So is 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 of 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 ask them
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 not to care,
they can do what they're best at.
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.
What SRE has done.
Everyone talks about the SRE
and some say it's just a DevOps guy
but it's not just that, there's also
different roles emerging.
It's an architectural game at this point, would you say?
>> I'd say a hundred percent and this is where
the decisions that you make architecturally.
If you don't know how to roll them out,
this is what we've seen time and time again,
you go these large companies, they've got these
great architectures on plan and four years later
we haven't reached it
because to that point they've gone-
>> John: 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
and I'm excited about the networking space
and really what we're doing there
and bringing that holistic portion of the network.
Like when STL 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
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.
>> Nick: Correct.
>> There've been stories recently
about the three-day workweek.
As a fan of utopian science fiction myself,
as opposed to dystopian.
>> Nick: Absolutely.
>> I think that technology
does have the opportunity to lift all boats
and it's not 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.
>> Yeah, agreed.
And that's what I said in the beginning,
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...
DevOps people are so hard to find.
Why?
Because they're sick and tired of babysitting deployments.
They're told everywhere they go
they're not going to have to. (John laughs)
>> 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 theCUBE.
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.
As infrastructures could we get that but...
Data is now the resource everyone needs
and everyone's trying, "Oh, I have 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 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 the 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 them.
>> Nick, great to have you on.
Field CTO of Harness, and harness.io is the URL.
Check it out. Thanks for the insight.
>> Thank you so much. Genuinely appreciate it.
>> A natural CUBE analyst right here, Nick.
Of course, we got our analysts right here, David Nicholson-
>> (indistinct) out of a job.
>> You're good on your own.
I'm John Furrier, (indistinct) host. Thanks for watching.
Still two more days of coverage.
We'll be back after this short break.
(uplifting music)