[MUSIC PLAYING]
NIKHIL KAUL: Hey, Dale.
Thanks a lot for joining us today.
We are here to talk about "2019 Accelerate--
State of the DevOps" report.
Why don't you talk about what your role at Vendasta is
and what Vendasta really does as a company?
DALE HOPKINS: I'm the CTO at Vendasta,
so my job really encompasses supporting
our research and development organization, which
is 17 teams.
What Vendasta does is we provide a platform
for selling products and solutions to local businesses.
So there's over 2 million local businesses
that are in our platform.
They're using some form of software today.
There are over 10,000 partners of ours
that are selling solutions based on our technology every day
and millions of businesses that rely on it.
NIKHIL KAUL: Could you talk more about what that report is?
DALE HOPKINS: Yeah, no, it's pretty exciting.
I think there are something like 31,000 respondents and I think
six years' worth of data.
So it's actually got a lot of interesting insights
you can pull when you start to get a report this big.
And we found a lot of great stuff in there.
NIKHIL KAUL: Why did you decide on using the guidance which
the report provides?
DALE HOPKINS: We had already started the transition
into SRE.
And we'd actually built an SRE team at Vendasta
before the we had read the material from "Accelerate--
The State of DevOps."
Starting with the SRE material, we
had begun to measure deployment frequency,
and we had begun to measure mean time to resolution.
So from the "Accelerate--
The State of DevOps," we came up with the other two metrics
that were really valuable.
And the first one was lead time, which talks about how long
is it from when you first commit code until that code is
on production.
And so this was kind of the critical second step,
was rather than doing big batches quickly,
we ended up doing much smaller batches.
And as part of that, that changed fail percentage, so
not only how quickly can you recover,
but how often do you need to.
NIKHIL KAUL: Based upon "Accelerate--
State of the DevOps" report, you looked
at four matrices which helped with speed and stability.
Are there specific learnings from this process
which you can share with us?
DALE HOPKINS: As with a lot of these things,
it completely starts with measurement
and self-assessment, because it's pretty hard
to know where you need to improve if you don't really
know where you stand.
I think there's an online tool available that,
as part of the "Accelerate--
State of the DevOps," that you can
do a self-assessment on where you
stand on your current metrics.
And it'll help you understand what
that piece that you need to focus on
is, because rather than trying to do all four,
it's an understanding of which parts of your practice
you should start to work on--
AKA, your biggest constraint.
NIKHIL KAUL: So where did you actually start?
DALE HOPKINS: Yeah, so for us, looking at our organization,
we said that one of the biggest problems for us
was continuous integration.
And for a company that all of our software was in the cloud,
we had this one wart, which was our continuous integration
server was actually on prem.
We started with having this naive approach of let's take
what we currently have, and let's move that into the cloud.
And so that's where we took--
and we evaluated actually taking TeamCity and moving that
into the cloud.
But for a variety of reasons, what we ended up doing
was moving to Jenkins, which is a very similar CI system,
and we moved into Kubernetes on Google Cloud.
With Jenkins in the cloud, we could actually
provision more VMs as we grew and things like that.
But we were running our CI infrastructure
on the same Kubernetes cluster that we
are running our production infrastructure on.
And so as scaling happens, we actually
would have production workloads impacted by our Jenkins.
That's not the case in the world of Cloud Build.
NIKHIL KAUL: The use of cloud for continuous integration,
specifically Cloud Build--
were you something really surprised by?
DALE HOPKINS: Yeah, when we stopped
having static virtual machine definitions
and the teams could define their resource
requirements per build.
We actually found an 80% reduction
in some of our projects in the total time to run the build.
We've actually seen the number of deploys
across our organization increase by 30%.
So it means 30% more deploys every day by each developer
than we had before.
And that's a pretty big change, considering
that's just a change to CI.
NIKHIL KAUL: In your case, the biggest constraint
was continuous integration.
How have you expanded the CI process into other areas
to improve the speed and the velocity
with which you are delivering software to your customers?
DALE HOPKINS: I think there's a couple parts to this-- looking
throughout your process and end to end finding
opportunities for automating.
So CI/CD is obviously one of those.
But there's lots of parts of your organization
where you can find opportunities to automate.
And then I think one of the other things
that we talk about as a core concept of this
is going to be that shift left.
If you think about security at the beginning,
it's a lot easier and less costly to deal with it
at the beginning than it is to find a solution that's insecure
and then try and make it secure.
The last one is obviously probably the most important,
which is that culture, which is getting people
to buy into some of the changes you're doing,
and that this is a positive change for them.
And so rather than feeling like a mandate.
NIKHIL KAUL: Can you talk more about end-to-end automation?
DALE HOPKINS: Yeah.
So for our process, what we're doing
is on each commit, which is hitting
GitHub, that's triggering one of our cloud builds.
And so Cloud Build is then going ahead and running on that code
and producing artifacts.
And so those artifacts are then--
we're running as part of that, we're running lints,
we're running tests, we're running other things.
And when an artifact actually passes all of those tests,
then it goes ahead into Container Registry.
And this is where vulnerability scanning happens,
to check for problems with the underlying images
or things like that.
Known vulnerabilities.
And then what we're using is-- is before it gets deployed,
we're using Binary Authorization to say,
is this actually something from the correct repository
that we're going to deploy on your production infrastructure?
And then controlling what accounts
have access to do that kind of deployment.
And then that's where we've controlled
across the whole architecture, now infrastructure.
We've got end-to-end automation right
from commit until deployment to the infrastructure.
NIKHIL KAUL: So that covers end-to-end automation.
That covers shifting left.
Let's go to the third part, which is
implementing cultural change.
DALE HOPKINS: Well, the way it starts
is getting the business side of the organization, the product
side of the organization, to buy into the concept
of availability that is not 100%.
It's prohibitively expensive the closer you get to a true 100%.
I think that the metrics are when
you go from 99% availability to a 99.9% availability,
it's an exponential increase in cost for every nine
you want to add.
And the question becomes, is that worth
it to your customers?
And also, do your underlying systems actually
also offer that?
Because if you improve the availability of your system,
but not the underlying ones, it might
be that you're spending money on availability
that actually, your customers can't
see because essentially you're not
the longest pole in the tent.
NIKHIL KAUL: Can we pivot and talk about your journey
to cloud, and what guidance you can give to organizations
specifically who are in the process of moving to the cloud?
DALE HOPKINS: Maybe thinking about the cloud as not a step
or a discrete quanta that way.
It's going to be a process that takes a long time.
I like Nicole Forsgren's picture of it's like a gym membership.
It's not like you buy it and you're done.
NIKHIL KAUL: If getting cloud is like a gym membership,
what are the different activities
you can do in order to realize the potential of cloud fully?
DALE HOPKINS: So if you ask companies,
as the DORA report does, are you using cloud?
The answer is, of course.
Everybody's using cloud.
And so when we use the NIST definition
of cloud, of which there's five components, only 29%
of respondents are actually using all five
of those components of the cloud.
The first capability we're talking about is on demand.
And so this means you can provision
the capacity yourself.
You don't have to phone somebody.
The second one is broad network access,
which means that it's not behind a VPN,
only accessible from certain computers.
This means it's accessible worldwide.
The third one is resource pooling,
which means there's this multi-tenant platform that you
have access to more resources.
And the fourth one is rapid elasticity.
And so this means that you're able to quickly spin things up
when you need capacity and quickly spin them down when you
don't.
And the last one is measured service.
And so this is important that the cloud provider is actually
able to measure what you're using
and bill you only for what you use.
NIKHIL KAUL: Well, Dale, thank you
so much for joining us today.
DALE HOPKINS: Thanks for having me.
[MUSIC PLAYING]