►
From YouTube: Deploying to Kubernetes Thousands of Times Per/Day - Dan Garfield, Codefresh & William Denniss
Description
Deploying to Kubernetes Thousands of Times Per/Day - Dan Garfield, Codefresh & William Denniss, Google
Connecting all the pieces to make zero downtime continuous delivery happen at scale. We'll show real teams bring all the components come together to make high-velocity deployment to Kubernetes scale. Get a hands on view of the critical steps that go into making container management a scalable process that not only allows teams to delivery faster but with more confidence in the final result.
About William Denniss
William is a Product Manager at Google and works on Google Cloud and Kubernetes. He has a passion for open source and open standards, is the author of several IETF Internet-Drafts including OAuth 2.0 for Native Apps, and founded AppAuth, the leading open source OAuth client for native apps.
About Dan Garfield
Dan Garfield is a full-stack engineer, kubernaut, and raspberry pi enthusiast. He's contributed to a number of open source projects and has beat Super Mario Bros 3 without a warp whistle. He works at Codefresh, a container delivery platform designed around containers and Kubernetes. Ask him about his robotic chicken coop.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
We're
gonna
be
talking
to
you
today
about
deploying
thousands
of
times
per
day
and
that's
really
all
about
high
velocity.
So
the
first
thing
you
know
we're
both
engineers,
but
but
the
reason
that
we're
really
want
to
talk
about
this
today
is
because
we
work
with
a
lot
of
really
high
velocity
teams
from
code
fresh
I
work
with
companies
like
UNICEF
Steelcase
giffy.
If
you
like
cat
gifs,
you
know
and.
A
So
these
are
all
teams
that
are
doing
high
velocity
deployment
at
scale,
they're,
delivering
containers
into
production
every
day,
and
so
we've
been
working
with
these
teams
and
we've
gleaned
a
number
of
lessons
from
them.
The
commonality,
as
I
would
say
that
that
we
think
are
useful
to
the
community.
Now.
Some
of
these
things
that
we
talk
about
do
highlight
some
Google
cloud
stuff,
some
code
fresh
stuff,
but
really
these
are
all
things
that
you
can
take
and
use
and
and
implement
in
your
own
processes,
regardless
of
where
you're
hosting
it.
A
B
So
why
do
people
choose
communities
in
the
first
place?
They're
they're,
definitely
lot
of
reasons.
One
might
be
scalability
the
ability
to
take
an
application
and
make
it
sort
of
planetary
scale,
avoiding
downtime
through
the
the
operator
pattern,
not
getting
that
3:00
a.m.
wake-up
call
and
have
no
need
to
add,
like
reboot
a
server
reducing
costs
through
bin
packing,
increasing
developer
velocity
through
releasing
more
frequently
and,
of
course,
the
infrastructure
abstraction
not
being
tied
into
one
particular
cloud
or
one
particular
vendor.
B
So
it's
interesting
to
me
when
we
had
a
technical
advisory
board
a
few
months
back,
we
had
about
40
people
in
the
room
representing
some
fairly
big
companies,
and
we
did
a
just
an
informal
poll
of
like
what
was
like
the
most
important
feature.
What
is
the
most
important
reason
that
you
Peace
communities
and,
to
my
surprise,
actually
about
80%
of
people
put
their
hand
up
for
developer
velocity,
so
I
think
this
is
like
a
really
important
topic.
It's
an
important
point
of
why
people
are
actually
choosing
committees
to
begin
with.
Yeah.
A
It's
funny
because
we
talk
so
much
about
scalability,
so
much
about
redundancy,
but
at
the
end
of
the
day,
what
everybody
really
wants
is
they
just
want
to
be
an
effective
engineer
organization?
They
want
to
be
able
to
have
high
velocity,
be
able
to
make
changes
very
quickly,
and
so
it's
a
it
does
kind
of
standard
to
me
as
a
surprise,
80%
of
the
people
picked
developer,
velocities
their
reason
for
adopting
Carini's
and
by
the
way,
this
these
slides.
These
are
things
that
you
can
take.
A
B
You
can
observe
the
effects
and
if
you
have
to
rollback
you're,
only
rolling
back
a
little
bit.
You
know
kind
of
you
know.
Faced
with
that
horrible
situation,
where
you
know
you
had
to
deliver
a
feature
by
a
particular
date
and
then
there's
a
risk,
you
may
have
to
roll
it
back
because
of
some
unrelated
problem,
so
we
think
like
definitely
reducing
risk
by
deploying
for
it
frequently.
It
is
a
very
important
strategy.
Yeah.
A
I
think
my
dad
used
to
say
small
cuts
make
small
mistakes
right.
So
it's
the
same
thing
with
software
development.
You
do
reduce
the
risk
and,
with
those
big
sort
of
giant,
commits
those
quarterly
releases,
they're
very
cost
inefficient,
so
high
velocity
is
also
about
cost
efficiency,
so
think
about
it.
This
way,
when
you're
making
changes
to
code,
the
reason
that
you're
making
those
changes
is
because
those
changes
are
going
to
give
you
business
value
right,
you're,
delivering
something.
That's
gonna,
make
your
company
more
successful,
making
more
money.
A
If
those
changes
any
moment
after
those
changes
are
complete
and
they're
not
delivered
into
production,
you're,
basically
paying
money
to
store
those.
So
your
CFO
is
gonna
love
this
point.
Basically,
you
want
to
get
those
things
out
faster
because
they're
valuable
for
your
company
and
the
third
which
a
lot
of
people
don't
think
about
a
lot
of
people.
Think
of
high
velocity
lots
of
changes
sounds
like
a
security
risk.
Well,
it's
actually
the
opposite.
Being
high
velocity
means
that
you're
going
to
be
more
adaptable
to
change
and
security.
A
Isn't
a
game
where,
like
hey
I,
did
everything
right?
I,
don't
have
to
worry
about
it
anymore.
No
security
is
a
game
that
changes
all
the
time
right.
Ssl
had
a
bug
for
10
years.
No
one
knew
about
heartbleed
happened,
Internet
blew
up,
everybody
lost
their
minds
if
your
high
velocity
and
you
walk
in
and
there's
a
zero
day
you're
like
oh
I,
guess
we
have
to.
We
have
one
extra
release
to
do
today.
No
big
deal.
This
is
bacon
two-hour
process.
A
We
do
this
every
day,
so
it's
not
a
problem
for
us,
so
being
high.
Velocity
actually
also
makes
you
more
secure,
so
save
that
one
for
all
your
financial
industry
folks
take
that
back
to
the
team.
That's
that's
a
super
valuable
reason
to
adopt
high
velocity.
So
there
are
a
lot
of
you
know.
How
do
you
become
high
velocity?
There's
a
lot
of
common
or
highly
repeated
stuff
that
you'll
hear
agile
planning
is
super
important.
We're
not
going
to
beat
the
agile
drum
today.
I
think
you
guys
have
probably
got
it.
A
We're
not
gonna
beat
the
micro
service
architecture
drum.
You
guys
have
probably
heard
a
lot
of
that.
Hopefully,
everybody
has
drunk
the
kool-aid,
maybe
but-
and
everybody
obviously
already
knows
that
you
could
always
use
better
testing,
we're
going
to
talk
about
kind
of
five
core
lessons
that
we've
learned
from
from
working
with
all
these
different
companies.
So
here
is
number
one:
high
velocity
teams
Center
on
images.
I
can
explain
what
this
means.
I
have
a
quote
here
from
Daniel
stone.
He
says
our
entire
developed
test
stage
deploy
cycle
is
docker
native.
A
A
Well,
if
you
think
about
an
image,
images
are
the
star
of
the
show
and
in
your
release
process
in
your
development
process,
an
image
is
immutable
right,
so
it
when
it
when
the
image
is
created,
it
should
be
ready
to
launch
I
talked
to
someone
at
a
meet-up
recently
and
we're
talking
about
this
point,
and
they
said
you
mean
when
I
push
my
image
to
production,
it
shouldn't
download
a
war
file.
No,
don't
do
that.
Oh
my
gosh,
he
said
well,
it's
pretty
big.
A
It's
like
500,
Meg's
and
I
was
like
cut
put
it
in
your
image.
What
are
you
talking
about
yeah?
So
your
your
image
should
be
ready
to
go
right
and
by
doing
that,
your
image
becomes
a
point
of
validation
right
so
previous
to
working
with
containers,
you
might
validate
a
change
set,
but
change
sets
are
ephemeral,
they
don't
have
the
nc
is
associated
with
them.
They
don't
have
the
underlying
OS
associated
with
them.
They
don't
know
anything
about
infrastructure.
An
image
doesn't
have
that
problem.
A
You
baked
everything
in
so
you
can
move
an
image
and
we're
going
to
talk
about
that
in
a
second
now
having
an
image
as
a
start
of
the
show
means
that
it's
also
connected
to
the
entire
process.
So
if
you
have
a
JIRA
ticket
or
or
you
have
test
steps,
all
those
things
should
be
associated
with
an
image
right,
so
you're
gonna,
just
like
you
have
a
you
know,
maybe
a
commit
or
a
feature
branch
associate
with
an
image.
A
B
And
another
benefit
of
the
images.
I
was
talking
to
a
Japanese
startup
recently
they
were
in
the
process
of
adopting
kubernetes
and
they're.
Most
excited
about
this
idea
that
you
can
take
that
same
image
that
the
developer
built
on
their
machine
and
take
it
all
the
way
through
to
production,
three
staging
and
tests,
and
it
also
means
like
if
you
actually
encounter
a
bug
in
production.
You
can
potentially
pull
that
image
down,
connect
that
to
your
staging
environment
and
debug.
B
A
So
you
know
a
lot
of
us
think
about
the
latest
tag.
You
should
probably
forget
that
if
you're
deploying
a
thousand
times
a
day
latest
is
just
a
random
image,
it's,
like
you,
don't
even
know,
what's
in
latest
right
right,
so
that
means
you
can't
really
rely
on
that
as
as
your
strategy.
Instead,
you
need
to
have
those
things
living
on
their
image
and
be
aware
of
it
and
you'll
see
what
I
mean
here
a
little
bit.
One
of
the
things
you
should
build.
The
support
is
what
I
call
time
travel.
A
What
is
time
travel
well
time?
Travel
is
ability
to
say,
I
need
to
go
back
to
what
was
running
at
9:15
a.m.
last
Monday.
Now
of
all
you
people
in
the
city,
this
room,
think
how
fast
can
you
answer
that
question,
because
if
it's
within
30
seconds,
then
you're
in
a
good
spot
right,
so
you
want
to
build
the
support
time.
Travel
and
I'll
show
you
what
that
looks
like
in
a
few
minutes.
You
also
want
to
have
it
closely
coupled
with
get
so.
A
B
And
I
think
the
classic
use
case
right
is
that
you're
working
on
a
bug,
you're
trying
to
fix
something
and
you
have
a
patch
and
the
patch
may
be
fixed
it
or
maybe
didn't,
and
you
have
a
report
that
the
issue
is
still
occurring.
So
one
of
the
most
important
things,
of
course,
is
that
you
need
to
know:
did
the
patch
actually
reach
production,
or
are
you
getting
these
bug
reports
on
the
unpatched
version?
B
If
you
don't
know
what
code
is
actually
in
that
image,
it's
really
hard
to
answer
that
question,
and
so,
as
long
as
your
image
is
like
tied
to
the
git
commit,
you
can
go
back.
Look
at
the
history
see
whether
or
not
that
patch
made
it
and
then
decide.
Okay,
well,
the
patch
actually
didn't
work,
or
maybe
it
wasn't
deployed
and
I.
Think
that's
the
important
distinction
yeah.
B
And
I
think
that's
a
really
important
point,
because
we're
just
saying
that
you
need
to
know
what's
actually
running
in
production
if
you're
building
those
images
locally,
it's
possible
that
you
may
have
uncommitted
changes
in
them,
which
of
course
blows
up
that
traceability.
So
as
long
as
you're
using
an
automated
build
server,
then
you
can
feel
confident
that
it's
actually
reflecting
everything
that's
currently
in
git
and
if
you're
not
doing
that,
then
it
makes
the
previous
point
a
lot
harder.
Yeah.
A
Right,
yeah,
exactly
it
basically
just
bypasses
the
process,
so
you
can
do
that.
That's
kind
of
what
it
is
to
Center
on
images.
The
second
thing
that
we've
learned
from
high
velocity
teams
is
that
high
velocity
teams
shift
left.
So
what
does
it
mean
to
shift
left
I'll?
Give
you
a
quote
here
and
then
we'll
talk
a
little
bit
more
about
it.
This
quotes
from
daemon
circular.
He
says
when
our
engineers
commit
code
code
fresh
and
you
could
you
could
build
this
yourself
as
well.
A
Code
fresh,
runs
all
the
testing
we
need
and
spins
up
an
environment
just
for
the
feature
they
worked
on.
Our
QA
and
design
teams
can
access
this
unique
environment
and
do
a
level
of
testing
that
just
wasn't
possible
before
our
test
cycle
went
from
three
days
to
three
hours.
So
this
is
hopefully
you
get.
The
idea
of
this
is
a
big
benefit
to
shift
left.
What
does
it
mean
to
shift
left?
Well,
you're,
all
probably
familiar
with
this
diagram.
This
is
a
typical
dev
release
process.
A
You
make
a
feature
branch
you
make
a
commit
and
every
commit
you
run
unit
tests
and
then,
when
you're
ready,
you
wish
you
a
pull
request.
Someone
reviews
the
code,
and
then
you
push
it
into
staging.
Where
you
do
your
depot
deeper
level
of
testing
integration,
performance,
security,
testing,
licensing
scanning,
all
those
kinds
of
things
now,
typically,
you
can
only
do
that
once
you
reach
staging,
because
that's
the
only
place
where
your
application
can
access
all
of
its
associated
services,
its
back-end,
the
basically
the
full
application
stack.
A
The
result
of
this
is
that
your
staging
step
becomes
a
huge
bottleneck
and
it
becomes
a
cost
sink.
So
if
you
think
about
it,
what's
the
most
expensive
part
of
that
process
that
we
just
looked
at
it's
code,
review
code
review
is
very
expensive
because
your
time
is
the
most
expensive
time
paying
for
a
few
extra
few
extra
cycles
on
computer
yeah
compute,
it's
not
a
big
deal,
so
what
we
can
do
is
actually
we
can
eliminate
this
and
we
can
fix
it
by
shifting
left.
A
So
this
is
what
a
shifted
left
pipeline
looks
like
every
time
you
make
a
commit.
Instead
of
only
running
unit
tests,
you
should
be
able
to
app
you
can
you
should
be
able
to
access
the
service
you're
changing
along
with
all
of
its
dependent
services,
to
run
not
just
unit
tests,
but
also
integration
tests,
performance
tests,
security
tests,
even
user
acceptance
testing
before
you
do
the
pull
request?
So
what
does
that
mean?
Well,
it
means
that
if
you're
a
developer
and
you're
working,
you're
gonna
get
instant
feedback
on
everything
about
the
change
that
you've
made.
A
Not
just
if
it
passed
unit
tests,
you're
gonna
know
everything,
and
so
you
can.
You
can
make
all
the
changes.
So
when
you
do
issue
a
pull
request,
not
only
is
it
going
to
be
higher
quality
but
the
person
doing
that
pull
request.
They
already
know
that
it
works
right.
They
already
know
that
it
works.
We
already
seen
that
it
works
at
ru.
It
already
went
up
in
environment,
it's
already
been
validated.
A
They
have
all
the
proof
points
they
need
and
then,
when
they're
doing
that
pull
request
all
that
they're
looking
for
it
really
is
like.
Let's
make
sure
that
we
have
style
here.
Let's
make
sure
that
you
know
we're
following
you
know:
best
practices,
security,
those
things,
so
it
sort
of
really
means
to
shift
left.
B
Right
so
there's
really
hard
to
do
if
your
application
isn't
defined
well.
So
you
need
to
make
sure
that
you
have
like
very
clear
definition
of
the
environment
and
a
good
way
to
test.
This
is
to
look
at
your
mean
time
to
recovery.
So
having
a
low
mean
time
to
recovery
is
generally
a
good
thing
anyway
right,
but
it's
also
a
good
metric
to
see
like
yeah,
like
how
quick
can
you
actually
bring
this
environment?
B
How
quickly
can
you
create
that
ephemeral
branch,
if
you,
if
you
can't
do
that,
it
probably
means
that
you're
not
doing
this
very
well?
So
some
of
your
Google
that
we
do
is
this
disaster
recovery
test
and
kind
of?
Do
it
like
I,
think
about
twice
a
year
and
we'll
use
an
example
like
this.
You
know
the
media
like
hit
a
data
center
or
some
kind
of
crazy
example.
Aliens
have
invaded
or
something
just
just
sort
of
set
the
scene,
but
it's
in,
but
it's
important
to
do
that.
Disaster,
recovery
and
and.
A
So
we've
actually
code
press
we've
fully
embraced
helmet
charts
to
do
this
job
for
us,
if
you're
not
familiar
with
helm
charts.
Basically,
it
allows
you
to
define
your
full
application
stack
with
all
of
the
associated
services
which
images
are
running,
which
versions
they
are
how
the
networking
works
and
so
with
a
helmet
art.
A
A
Both
benefits
and
we've
actually
does
just
kind
of
a
side
note,
but
code.
For
this
week
we
launched
public
support
for
helmet
chun
charts.
We've
been
dogfooding
this
aggressively
internally
for
about
last
six
months
with
some
of
our
customers
and
we've
found
that
it's
been
really
really
effective.
It's
also
the
most
highly
requested
feature
as
support
for
health
charts.
So
we
announced
announced
that
right
here
at
code
con.
B
And
so
that's
actually
home
to
us,
even
if
I
could
bespoke
application
right,
like
a
lot
of
people
have
used
home
charts,
for
maybe
you
know,
they're
releasing
software
like
WordPress
that
you
expect
thousands
of
people
to
run,
but
you're
also
saying
that
people
are
actually
using
that
just
to
represent
the
full
state
of
their
application.
Yeah.
A
B
A
B
So
I've
talked
a
lot
about
having
these
like
ephemeral
instances
or
multiple
different
environments.
We
also
talked
about
the
benefits
of
being
a
take
an
image,
that's
running
in
production
and
actually
pull
that
down
locally
connected
to
a
staging
server
and
in
debugger,
of
course,
that
doesn't
work
if
you've
baked
configuration
in
images.
I
can
really
can't
make
this
point
enough.
I
think
the
test
here
is
that
you
need
to
be
able
to
run
that
same
image
in
tests
in
production.
If
you
can't
do
that,
it
generally
indicates
there.
B
You
have
some
something
baked
in
so
obviously
like
config
maps
and
secret
sink
ribbon,
80s
or
the
way
to
do
that,
but
yet
make
make
sure
that
you're
sort
of
passing
that
test
right.
Can
you
take
that
image
and
just
connect
it
to
any
random
environment
if
you
can
in
a
good
place,
I
think
for
for
a
high
velocity
environment,
yeah.
A
B
And
what
do
we
mean
by
this
so
I'm
not
saying
that
everyone
should
just
jump
onto
cloud,
although
that
would
be
fine
if
you
did,
but
we're
saying,
like
your
application,
developers
should
be
focusing
on
building
the
application
right.
So
kubernetes
is
fantastic
in
the
sense
that
you
can
even
run
in
multi
environments.
You
can
on-prem,
you
can
run
cloud,
you
run
multiple
clouds
and
whole
combination
of
all
of
the
above
right,
but
I.
B
Think
the
the
point
we're
trying
to
make
here
is
that
you,
you
probably
should
have
a
dedicated
team
focused
on
actually
providing
that
service
to
your
organization.
It
shouldn't
be
the
app
developers
that
are
like
manually
in
you
know,
creating
nodes
and
adding
like
using
QA
ATM,
and
things
like
that.
You
want
to
have
like
either
a
central
team
managing
that
or
you
want
to
be
using
a
cloud
poster
offering
yeah.
A
And
think
of
it
like
how
many
of
you
and
raise
your
hand,
how
many
of
you
are
managing
the
server
recs
and
replacing
broken
machines?
Okay,
three
of
you
that
are
on
the
ops
team.
You
probably
should
be
right.
Nobody
else
is
right.
Kubernetes
management
is
the
same
story
if
you're,
if
you're
getting
lost
in
that
rabbit,
hole
of
maintaining
kubernetes
like
you're
not
going
to
be
effective
as
a
team,
you
need
to
have
it
out
sourced
either
out
sourced
within
your
own
company
or
outsourced
to
a
cloud
provider
right
and.
B
Of
course
like
when
you're
choosing,
where
to
do
this,
always
consider
scalability
and
redundancy
as
well,
so
even
if
you're
doing
a
fairly
small
application,
you're
not
sure
how
successful
successful
it's
going
to
be.
Like
probably
one
of
the
reasons
you
peaked
communities
as
well
as
the
high
velocity
attributes,
is
the
fact
that
you
actually
can
scale
it
if
you're
successful
so
make
sure
you're
positioning
yourself
for
that
success
by
choosing
a
solution
that
can
actually
scale
what
you
need
to,
and
so
that
brings
us
to
open
standards
and
I.
B
Think
one
of
the
benefits
of
kubernetes
is
that
it
is
open
that
you
can
connect
up
multiple
different
clouds.
You
might
have
seen
at
the
keynote
this
morning,
I
think
down
analysis
like
40
different
vendors.
Now
that
are
certified
on
kubernetes,
so
you
can
actually
look
for
this
logo
certified
Capelli's
and
you
have
a
reasonable
degree
of
confidence
that
your
workload
is
portable,
but
it's
definitely
something
to
keep
in
mind
because
you
lose
that
open
benefit
if
you're
so
choosing,
locked-in
solutions,
yeah
and
just
to
emphasize.
B
A
Great
so
now
this
is
number
five
is
high.
Velocity
teams
have
to
connect
all
the
dots
all
the
stuff.
We've
talked
about
kind
of
backing
up
to
a
high
level,
really
what
it
boils
down
to
is
empowering
application
developers
to
make
changes
right,
and
if
people
can
access
these
clusters
they
can
spin
up
the
environments,
your
portability,
you're,
making
changes
left
and
right.
Maybe
you
have
dozens
of
changes
going
out
every
day
or
thousands.
A
If
you
don't
connect
all
the
dots.
That's
gonna
look
like
chaos,
and
so,
if
you
want
to
you
need
to
have
this
all
man
interesting
a
place
where
you
can
you
can
you
can
have
everything
visible,
I'm,
going
to
show
you
how
we
do
it,
but
you
you
really
need
to
have
that
order
available
to
you
in
order
to
make
all
those
things
happen.
So
I'll
show
you
how
we
do
it
at
code
fresh
and
you
can.
A
A
Mild
indifference,
okay,
so
this
is
a
view
of
I'm
sitting
inside
of
code
fresh
and
right
now,
I'm.
Looking
at
what's
running
on
my
kubernetes
cluster,
now
you
can
see
I'm
a
bunch
of
different
services
here.
Luckily,
they're
all
green
green
means
good
red
means.
Oh
no
yellow
is
maybe
you
know
so
they're.
All
green
I
can
see
for
all
my
different
namespaces.
Everything
is
in
the
green
right
now
and
if
I
wanted
to
understand,
you
know
what's
running
in
production.
Well,
first
of
all,
this
I
can
jump
over
to
my
application.
A
Where
the
end
point
is
sitting.
I
can
see
that
it's
up
and
running
that's
good,
but
I
can
also
see
what
image
is
actually
running
with
each
service.
So
I
can
I.
Can
click
on
this
and
see
immediately
what
image
is
running
and
not
only
that,
but
I
can
see
everything.
That's
happened,
the
entire
history.
So
here
you
can
see
all
the
different
changes
in
the
timeline
who's
contributed
to
it.
I
can
see
that
it
has
unit
test
coverage.
I
can
see
the
performance
latency
I
can
see.
A
There's
the
JIRA
ticket
that's
associated
with
this,
so
I
can
jump
straight
in
to
see
what
changes
were
being
made.
I
also
can
load
up
performance
reports.
We
performance
report
here,
I'm
using
blaze,
meter
and
I
have
a
quality
check
that
I've
added
here
now.
I
have
also
the
commit
shop.
So
if
I
jump
over
to
the
commit
Shah,
so
let's
say
I'm
running
this
in
production,
I
want
to
know
what
was
changed.
I
can
actually
jump
straight
to
commit
inside
of
github.
A
A
So
I
could
I,
could
jump
over
here
and
I
could
look
at
the
commit
history
associated
with
it.
So
I
could
see
those
changes,
I,
don't
think
any
of
us
have
ever
experienced
the
process
of
having
a
security
change
and
having
it
be
overwritten
by
a
change
like
a
day
later.
No
one
in
this
room
is
familiar
with
that.
There's
nothing
in
the
news
about
that.
Should
it
shouldn't
stand
out
to
you
at
all,
but
but
this
this
really
makes
it
powerful
right.
A
B
C
B
A
A
I
can
also
see
all
the
layers
associated
with
that
image
so
having
this
available
super
powerful
kind
of
a
superpower
that
you
can
have
now
if
I
wanted
to
commit
a
change
and
what
we'll
do
actually
I
debated
whether
or
not
we're
gonna
do
this
because
it
takes
a
few
minutes
but
we'll
kick
it
off
and
see
if
it
finishes
by
the
end.
I've
got
my
builds
view
here.
So
let's
make
a
change
to
this
really
quick.
It's
always
fun.
To
do
changes
right,
live
demos,
never
go
wrong.
A
A
A
A
Not
building
locally,
what
this
is
gonna
do
is
it's
gonna,
it's
gonna
create
a
one-off
environment
in
which
all
the
build
is
gonna
happen.
If
you
saw
a
talk
yesterday
on
building
scalable
architecture,
you
actually
got
a
little
bit
of
detail
about
how
this
is
all
how
the
back
end
of
it
all
this
works,
its
gonna
clone
all
the
code.
It's
gonna
build
the
image
you
can
see,
we've
actually
cached
all
the
layers
that
were
associated
with
the
image,
so
it's
only
making
changes
where
changes
are
needed.
A
So
that
means
my
build
time
is
going
to
be
roughly
24
seconds
23
seconds
now,
when
it
runs
these
unit
tests,
it's
actually
going
to
spin
up
a
whole
a
whole,
the
whole
application
stack
and
then
it's
going
to
associate
those
with
performance
tests.
Now
performance
tests
are
gonna,
take
about
four
minutes,
so
we'll
just
stand
here
awkwardly
for
the
next
four
minutes
and
wait
for
it
to
happen.
No
just
kidding
we'll
move
on
and
we'll
come
back
and
check
in
and
see
that
it's
completed
in
a
bit.
A
The
other
thing
I
wanted
to
show
you,
as
we
kind
of
walk
around
and
look
at
this
is
how
roll
backs
would
work.
So
I
mentioned
that
we've
adopted
we've
adopted
helm,
charts
pretty
aggressively,
so
I'm
gonna
show
you
kind
of
a
sneak
peek
behind
the
curtain
of
some
code.
Fresh
infrastructure
here
live
on,
live
on
the
stage.
If
I
jump
over
kubernetes
I
can
see
all
of
the
clusters
I
have
associated
now.
A
A
Project
so
yeah
we're
not
gonna
touch
stuff
too
much.
You
can
see
staging
where
there's
some
stuff
going
on
over
there
that's
exciting,
but
if
I
jump
over
to
release
is
you
can
actually
see
that
I
have
my
production
here?
I
can
see
that
it's
been
deployed
and
I
can
I,
can
click
and
open
this
and
I
can
actually
see
every
upgrade.
That's
happened
each
one
that
was
superseded
when
it
happened.
What
the
version
was
and
I
can
jump
immediately
to
one
and
roll
it
back.
A
So
this
gives
us
really
really
great
control
over
managing
releases
of
our
product,
and
you
can
see
from
the
from
the
time
stamps
on
this.
We
do
it
all
the
time
right
so
being
able
to.
This
is
our
kind
of
that
time.
Travel
thing
I
was
talking
about.
This
gives
us
that
ability
immediately
yeah
we're.
B
Talking
about
the
history
before
and
I
think
this
is
a
very
important
point
like
whoever
is
you
know,
whoever
you
choose
for
your
CI
CD.
You
need
to
make
sure
they
actually
have
features
like
this,
because
the
kubernetes
deployment
object
doesn't
necessarily
contain
all
that
history
and
the
ability
to
link
that
back
to
the
actual
code
that
you're
running
so
I
think
that's,
that's.
Definitely
something
I!
Look
for
and.
A
One
thing
that
I
would
mention
and
we'll
we'll
have
a
few
minutes
for
questions
here
at
the
end.
Is
that
code
fresh?
Actually,
this
the
the
ability
to
release
a
helmet
art
is
something
that
we've
baked
into
a
pipeline
image
step
and
we've
made
it
a
plugin
that
you
can
take
and
use
in
your
own
projects.
So
that's
available.
If
you
search
for
code,
fresh
plugins,
there's
a
github
repository,
we
have
a
whole
bunch
of
them.
We
have
tools
for
deploying
kubernetes
to
ezs.
We
have
tools
for
your
point
home
charts.
A
We
have
stuff
for
working
with
JIRA,
basically
they're
images
that
take
arguments
and
can
can
be
put
into
a
pipeline
even
with
Jenkins
or
other
tooling,
that
you
might
use
so
that's
free
for
everybody
enjoy
that
use.
It
contribute
we'd
love
to
see
that
program
grow.
So
this
gives
me
my
view
of
all
my
helmet
charts
stuff,
which
is
awesome.
I
can
and
I
can
manage
that
whole
process.
A
Yeah,
so
that,
actually,
this
is
a
really
good
question,
because
if
your
your
performance
tests
when
you're,
if
you
even
if
you
launch
your
whole
staff,
it's
you're
not
necessarily
going
to
have
like
a
million
nodes
dedicated
to
each
of
these.
The
benefit
of
this
in
is
basically
that
you
can
track
performance,
changes,
time
and
sort
of
the
small-scale
environment.
So
this
is
a.
A
So
that's
actually
a
really
valuable
feature
now
when
this
finishes-
and
it's
gonna
be
another
minute
and
a
half
so
we'll
probably
take
some
questions
in
the
meantime,
when
this
finish
is
what
it's
going
to
do
is
it'll
finish:
annotating
the
JIRA
ticket
it'll
finish,
adding
all
this
information
to
the
image
and
then
we'll
actually
do
a
rolling
update
of
into
into
the
indica
brunet
ease.
So
all
of
this
stuff,
why
do
we
do
all
this
stuff?
Why
do
we
talk
about
high
velocity?
Why
do
we
have
all
these
principles?
A
Well,
really
for
us,
we
want
you
to
be
successful
as
engineers
we're
successful
as
code
freshers,
Google
Cloud
we're
successful
when
you're
successful
when
you're
able
to
deploy
a
lot
when
you're
able
to
be
really
effective.
That's
when
we
win,
so
that's
what
we
want
to
contribute
to
everybody
today
is
these
principles
that
lead
to
high
velocity
to
help
you
do
that.
I
really
recommend
Google
cloud
platform
as
the
best
place
to
create
and
manage
clusters.
B
And,
of
course,
code
fresh
is
an
excellent
way
to
run
your
CI
C
pipelines,
particularly
I.
Think
you
do
the
deployment
really
well
a
lot
of
CI
systems,
I
ceiling,
kind
of
like
to
skip
the
deployment
bid,
or
it's
like
the
last
bit
yeah
so
I
mean
we
hope
that
all
these
principles
kind
of
broadly
applicable,
whoever
you
use.
Of
course,
you
know
this
is
awesome,
so
we're
a
little
biased,
but
we
heard
this
useful
and
probably
applicable
to
any
kind
of
environment.
What
that
you're
running
kubernetes?
Is
you
don't
ya.
A
Now,
to
help
you
try
everything
we've
talked
about,
you
can
actually
try
all
this
stuff
for
free
stop
by
our
booze
for
details.
We
actually
have
some
special
coupon
codes
that
we're
giving
away
at
our
booth
so
stop
by
and
chat
with,
we'll
give
you
those
codes
both
good
for
Google
cloud
platform
credits
and
for
code,
fresh
credits
so
stop
by
our
booth,
we're
just
downstairs,
and
then
we
can
look
back.
We
can
see
that
this
deployment
step
didn't
quite
finish
so
we'll
skip
out
on
that
right.
Any
questions,
question.
A
Yeah,
so
when
you,
if,
when
you're,
deploying
a
helmet
or
when
you're
deploying
a
home
chart
update,
it
doesn't
have
to
redeploy
images
that
are
already
existing
it
can
you
can
decide?
Basically
helmet
arts
lets
you
specify
and
say
I
want
you
to
always
pull
the
images
or
you
can
say,
I
only
want
you
to
update
the
ones
that
have
changed.
A
A
D
B
Definitely
you
want
the
liveliness
and
the
radius
probes
in
communities,
in
particular
the
the
radius.
Sorry,
the
liveliness
probe
will
actually
detect
that
crash
state
and
then,
if
you're
doing
a
rolling
update,
what
we'll
do
is
it
like
it'll
it'll,
replace
like
one
of
them
it'll
see
at
a
crash.
It'll
basically
pause
the
update
at
that
point,
so
you
so
you
want
to
kind
of
get
left
in
that
bad
state.
Yes,
I
highly
highly
recommend
readiness
and
liveliness,
so
yeah
yeah.
A
Yes,
code
fresh
is
cloud
agnostic,
obviously
I
I'm,
biased
towards
Google
cloud,
but
you
can
use
it
with
any
conformant
kubernetes
cluster.
So
if
it's
digitalocean,
if
it's
AWS,
if
it's
IBM
bluemix,
if
it's
the
ones
sitting
on
that
dudes
watches
yesterday,
I
don't
know
how
conformance
that
was.
But
if
it's
kubernetes
we
can
connect
to
it.
Yeah.
B
B
A
You
can
see
like
right
now
in
this
account.
I
have
an
IBM
bluemix
cluster
set
up.
I
have
two
clusters
on
google
cloud
platform.
I
could
add
them
for
AWS
or
just
any
custom
cluster.
I
can
add
a
custom
cluster
and
then
you
can
deploy
it
as
many
clusters
as
you
want,
or
you
could
do
multi
cloud
cluster.
You
know
that's
a
whole
nother
scenario,
but
yeah
definitely.
E
A
Kind
of
image
metadata
are
we
using
so
we
can
see,
do
roll
backs
yeah,
so
I'm,
not
sure
I,
understand
your
question.
Basically,
each
step
will
record
what
happened
and
then
code
fresh
has
a
built-in
registry
where
you
can
annotate
the
information
associated
with
it.
We
actually
use
a
standard
called
open
grief.
This
greet
open,
open,
grab
grass
there's
a
booth
for
it
downstairs.
We
just
announced
it
our
support
for
it
this
week,
so
you
can
Google.
B
Have
a
talk
about
this
tomorrow
yeah,
so
what
one
option
is
is
using
git,
obviously
for
the
configuration,
not
the
secrets
and
I,
don't
want
to
kind
of
spoil
the
talk,
but
there's
a
there's:
a
cool
project
I
forget
the
name
of
it
actually,
but
you
can
actually
set
up
like
a
private
and
a
public
key,
and
you
can
share
the
public
key
to
every
toy.
You
developers
and
the
private
key
remains
in
the
cluster,
so
you
have
like
a
single
secret
in
the
cluster
and
then
you're
acting.
B
Then
you
can
actually
encrypt
all
of
the
secrets
and
just
put
them
in
get
right,
because
no
one
can
actually
decrypt
them
unless
you
have
the
private
key.
So
so
it
basically
boils
down
to
use
get
for
everything.
Of
course,
you
don't
wanna
put
raw
secrets
in
gifts
to
then
you
want
to
Crypton,
but
to
avoid,
having
kind
of
like
you
know,
we
talked
about
mean
time
to
recovery
and
and
bring
up
a
new
environment
is
kind
of
a
pain.
A
A
A
A
B
B
I've
got
a
couple
otherwise,
well
you
know,
one
of
the
things
is
helm
has
a
certain
kind
of
authorization
model
so
sometimes
like.
If
you've
really
locked
down
your
cluster,
you
sort
of
have
to
think
about
the
the
tiller
in
helm,
because
what
you
don't
want
to
do
is
have
like
brilliantly
configured
acosta,
which
is
all
nice
and
secure,
and
they
just
open
this
sort
of
door
into
it.
I
mean
it's:
okay,
like
you
just
have
to.
You,
have
to
be
aware
of
what
you're
doing
and
kind
of
set
that
up
correctly.
A
Say
that
helmet
chart
is
by
no
means
perfect.
It's
under
very
active
development.
Right
now,
I
mean
I.
This
is
Cooper
day
he's
like
we
launched
1.8
a
month
ago.
1.9
is
about
to
drop,
so
it's
under
a
lot
of
active
development.
I
would
encourage
you
to
like
jump
into
that
that
working
group,
but
what
we've
seen
is
that
of
all
the
different
standard
ways
of
defining
an
application
for
kubernetes
helm
charts
is
the
most
comprehensive
and
it's
also
the
easiest
to
use.
A
A
Nami
now
has
launched
helm
apps,
so
I
think
most
I
think
the
kind
of
large
players
that
I
see
that
are
really
interested
in
application,
define
define,
meant
we're
kind
of
settling
on
held
charts.
Now
so
I
think
it's
gonna
be
the
standard,
obviously
to
change.
But
that's
I
think
that's
the
future
yeah.
B
B
A
B
A
B
A
Yeah,
so
there
are
two
different
places
that
you
think
about
secrets:
one
is
inside
of
a
cluster,
so
if
I
I
can
actually
work
with
my
configuration
maps
here,
so
I
can
create
I
can
create
admit,
config
map
for
a
specific
name
space
inside
of
code
fresh
and
manage
those
I
can
encrypt
those
and
then
also
secrets
associated
with
images.
I
can
do
the
same
thing.
So
if
I'm
looking
at
like
you
know,
pipeline
I
can
go
down
to
environmental
variables
and
I
can
create
and
encrypt.
A
A
A
Yeah
so
I
think
this
really.
This
really
encourages
microservices,
because
if
you
have
microservices,
you
can
basically
have
a
small
team
working
on
one
micro
service.
So
there's
not
like
a
million
changes
to
a
single
microservice
happening
every
day
and
that's
actually
where
you
are
more
likely
to
run
into
problems.
Your
services
should
maintain
interoperability
right.
Like
that's
the
whole
point
of
doing
you.
A
Yeah
they
should
be
able
to
lag
a
little
bit
and
it
shouldn't
be
a
huge
problem,
but
again
before
it
deploys
it's
actually
gonna
rerun
it
with
whatever
is
currently
the
thing
and
then
deploy
it.
So
you'll
always
get
that
smoke
test
and
you'll
always
be
testing
against
whatever
latest
is
so,
even
if
your
and
then,
if
you
run
into
issues,
you
can
pull
down
and
figure
out
what
went
wrong.
So
it
puts
you
in
a
good
position
to
manage.
B
A
B
A
You
scale
up
for
what
you
need
I
had
this
funny
experience.
I
was
at
a
very
large
company,
I
won't
name
their
name,
I
won't
name
them,
but
I
was
we're
getting
together
for
lunch.
So
walk
him
through
the
engineering
floor
and
there's
this
engineer
that
had
two
computers
on
his
desk
and
I
was
like
boy.
Those
do
got
two
computers.
These
are
that
good.
You
just
do
both
hands
at
once
and
they're
like
no.
No,
he
makes
a
change,
he
commits
it
builds
and
then
he
goes
to
the
other.
Computer
I
was
like.
A
A
Yeah,
so
we
have
a
customer
named
Steelcase
damon
circular
was
the
guy
I
quoted
in
this
presentation.
What
they
actually
do
is
they
use
live
data
when
they
do
their
tests.
They
actually
basically
pull
down,
live
data
and
load
it
into
images
that
they
put
as
part
of
their
test
pipeline.
So
that
that's
it's
kind
of
interesting
idea,
because
it's
you
think
of
it
as
a
database
as
being
a
staple
thing,
depending
on
the
changes.
A
B
G
A
F
B
A
You
missed,
we
have
two
options,
one
if
it's
like
my
sequel,
then
you're
like
okay
I,
can
create
an
image
with
my
sequel
data
and
use
that
if
it's
like
an
RDS
or
something
you're,
basically
I
want
to
duplicate
the
and
have
it
sitting
and
available
for
lots
of
different
test
things
to
hit
and
depending
what
your,
what
you're
testing
you?
Maybe
not.
You
may
be:
okay
with
it
being
a
shared
resource
right.
A
B
A
F
B
Like
Google
Cloud
does
so
it
was
GK
that
you
would
look
at
the
cluster
autoscaler.
So
there
are.
There
are
two
types
of
water
scaling
abilities.
There's
like
the
pod,
auto
scaling,
which
is
scaling
up
the
deployment
based
on
demand.
Then
there's
the
cluster
horas
going
so
that
that
takes
care
of
your
problem,
which
is
like
someone
just
scheduled
a
whole
bunch
of
containers,
and
there
aren't
enough
nodes.
The
cluster
water
scholar
says:
hey,
it
looks
like
you
need
a
bunch
of
extra
nodes
and
it'll
provision
them
with
incurring
about
45
seconds
yeah.
A
Is
very
good
at
this.
There
are
also
solutions
for
doing
it
on
Amazon,
but
basically,
auto
scaling
is
something
when
you're
looking
at
where
you're
gonna
host
your
kubernetes
nodes
scaling
is
super
critical
feature
to
have.
If
you
want
to
support
that
scalability
and
basically
code
Prussia's
infrastructure
is
entirely
elastic
right
so
like
we
have
15,000
users
and
we
don't
get
the
advance
notice
of
when
they're
gonna
be
heavily
using
the
platform,
so
we
basically
have
nodes
scaling
an
eight,
and
so
when,
when
kubernetes
isn't
able
to
schedule
a
new
pod,
gke
says
hey.
A
I
noticed
that
your
this
pod
won't
schedule
because
there's
not
enough
resources.
Let
me
add
some
notes
for
you.
Boom
everything
happens
and
then,
when
it's
when
it,
when
the
the
hi
times
have
died
down,
it's
smart
enough
to
say
it
looks
like
you're.
Not
using
these
nodes
will
pull
these
down
so
you're,
not
paying
for
these.
B
Actually,
hey
I
love
activities,
because
I
think
I
think
you
can
actually
save
a
lot
of
money.
Doing
that
too,
like
in
the
past,
you'd
have
to
like
provision
to
your
high
watermark
right
and
the
great
thing
about
cloud
in
general
and
communities
is
that
you
know
you
can
just
pay
for
it.
Using
google.
A
A
G
C
B
A
C
A
Yeah,
you
can
do
a
couple
of
things,
one
you
can,
you
can
use
chained
pipelines,
so
you
can
actually
have
a
pipeline
and
then
you
can
make
the
next
pipeline
available
to
it.
So
let's
say
you
have
a
pipeline,
that's
just
the
performance,
all
the
performance
steps
and
all
that
pipeline
needs
is
to
have
an
environment
pass
to
it.
So
you
say
you.
Basically
it's
almost
like
an
API
right.
You
say
this
pipeline
is
available.
You
can
plug
into
it.
It
will
do
all
its
work
and
it
will
pass
back
the
information
wherever
you
need.
A
You
just
need
to
pass
in
the
variables
ahead
it
into
that
pipeline.
So
you
can
use
you
can
kind
of
use,
centralized
pipelines
like
that.
The
other
thing
that
I've
mentioned
is
that
helm
charts
focuses
on
dependency
management
as
a
function
of
micro
services.
So
when
you
have
a
service
you
can
say
these
are
the
services
that
this
micro
services
depended
on
and
then
you're,
not
taking
necessarily
even
the
whole
stack
you're
only
taking
the
portion
of
it
that
you
need.
This
is
something
that
Google
is
actually
really
good.
A
At
Google
uses
a
single
git
repo
for
everything
get
bit
yeah.
Sorry
Google
uses
a
single
repo
for
everything.
This
is.
This
is
Chromebooks
Google,
Cloud
Gmail
everything,
it's
all
in
one
giant
repo,
the
way
that
they
do,
that
is,
they
have
really
good
dependency
management,
so
they
can.
So
if
I'm
working
on
a
change,
I
can
pull
down
just
the
stuff.
I
need
to
work
with,
and
not
the
47
terabytes
that
make
up
all
of
Google's
information
right
or
whatever
it.