►
Description
Cloud-native applications—that is, applications that have been developed specifically for cloud platforms—are the future of software development. Container packaged, dynamically managed, and micro service-oriented, cloud-native systems give developers greater flexibility and empower them with the speed and velocity needed to deploy efficiently. How can you transition to this new, cloud-computing paradigm to meet the vision of cloud-native?
In this webinar, we will cover some of the advantages and elements of a cloud-native approach, and how GitLab is making it simpler to deploy cloud-native applications to production using Kubernetes.
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
Alright,
the
numbers
seem
to
be
stabilizing
out
so
I'm
gonna
go
ahead
and
get
started.
Welcome.
So
this
the
ninth
I
think
CN
CF
webinar.
My
name
is
Mark
Coleman
I'm,
the
CN
CF
marketing
committee
chairperson
today
we're
very
pleased
to
have
Josh
mark
and
Camille
from
gitlab
with
us
to
talk
about
getting
cloud
native
applications
from
development
and
to
to
production.
A
So
before
we
get
into
it
a
couple
of
life
guidelines,
please
don't
leave
all
your
questions
to
the
end,
because
this
works
a
lot
better
when
it's
interactive
and
you'll
probably
really
know
this,
but
you
cannot
speak
during
the
webinar.
So
if
you
do
have
questions
put
them
in
either
the
QA
Q&A
window
or
the
chat
window
and
I
will
find
opportune
moments
to
ask
the
presenters
those
questions.
B
All
right
so
today
you
have
myself
Joshua
Lambert
product
manager
here
at
lab,
along
with
Mark
penstock,
who
is
our
head
of
product
and
then
Camille
after
Lucy,
who
is
our
CI
of
leave.
I
like
it
lab
so
I
was
doing
most
the
presentation
duties,
but
we
have
Mark
and
Camille
available
for
all
three
questions.
So,
as
Mark
mentioned
earlier,
please
toss
them
in
chat
or
in
QA
and
we'll
get
to
them
throughout
the
session
today
will
be
a
little
high
level
in
the
slide
content.
B
Just
because
we
can
possibly
have
a
pretty
broad
range
of
the
audience.
They
have
detailed
questions
or
technical
questions.
Please
again
ask
them
and
we'll
certainly
address
them
as
we
go
along
here
to
help
keep
it
interactive
and
make
sure
we're
giving
your
content
that
you're
looking
for
here.
So
as
far
as
what
we're
gonna
cover
we'll
first
pick
off
with
again
just
a
high-level
kind
of
baseline
setting,
introduction
to
cloud
native.
B
What
it
is
we'll,
then
go
into
lies
from
Koren's
and
why
it's
important
for
your
businesses,
your
organization's
I'll,
talk
about
some
challenges
you
might
bump
into
on
the
way
to
embracing
or
moving
towards
a
cognitive
architecture.
Well,
then,
get
into
some
getting
started
recommendations
and
then
also
a
demonstration
of
how
you
can
potentially
automate
your
applications
from
development
to
production
as
well.
B
So
now
what
are
is
a
container
well.
The
doctor
team
defines
it
as
a
lightweight
standalone
executive
package
that
includes
everything
needed
to
run
that
piece
of
software,
and
that
sounds
great,
but
was
it
kind
of
mean,
especially
in
particular,
to
sort
of
the
previous
computing
models
of
the
past?
Well,
you
know
way
back
in
the
early
days,
you
had
bare
metal
where
you
essentially
had
your
machine,
an
operating
system
running
on
it
and
you
install
applications
kind
of
commingled
all
in
the
same
machine.
B
This
was
great,
it
was
efficient,
but
their
problems
around
dependency
management
applications
could
impact
each
other
and
trying
to
reliably
deploy.
Software,
especially
at
scale,
was
a
big
challenge
so
entering
virtualization.
We
could
essentially
have
a
computer
kind
of
purpose
dedicated
for
a
particular
application,
and
you
could
run
multiple
of
these
on
a
single
piece
of
hardware.
This
allows
you
to
have
portability
isolation
between
virtual
machines
and
also
be
able
to
more
rival,
Eve,
run
your
software
and
deploy
your
software
with
containers.
B
You
kind
of
get
a
lot
of
the
benefits
of
the
virtual
machine,
but
you
can
see
that
we're
actually
dropping
that
whole
West
layer
right
we're
not
trying
to
virtualize
an
entire
operating
system
for
each
to
the
individual,
VMs
and
so
the
benefit
here.
Is
you
get
sort
of
the
isolation
and
security
benefits,
but
what
thats
makes
show
overhead
right?
So
that's
kind
of
the
main
difference
there
between
containers
and
some
earlier
models,
and
so
the
key
benefits
really
are.
B
They
still
maintain
the
isolation
and
security
features
predominantly
of
the
VM
model,
but
they're
far
more
efficient
right,
so
they
use
less
CPU
use
less
RAM
and
they
can
start
and
stop
much
much
more
quickly,
right
in
this
case,
in
the
seconds,
as
opposed
to
having
a
good
up
entire
operating
system
and
then
vacation
start
after
that
happens.
They
also
maintain
the
ability
to
be
really
repeatable
right,
so
they're
broaching
controlled,
they're
hashed
and
you
can
reliably
deploy,
though
the
application
the
same
way
every
single
time-
and
this
is
really
important
to
caution.
B
You're
talking
about
deploying
and
running
software
at
scale,
as
well
as
having
an
automated
process
to
make
this
work
reliably
and
efficiently
for
you
to
do
it
time
and
time
again,
very,
very
quickly.
So
that's
a
brief
introduction
to
containers
so
I'll
sweep
on
the
point
number
two
here
which
is
getting
into
kind
of
what
comes
next
right.
B
So
you
can
imagine
what
container
is
kind
of
give
us
a
model
to
you
know
say:
have
your
stuff
hardware
or
a
boat,
you
can
stack
on
a
whole
bunch
of
containers
on
top
of
that
and
you
can
set
it
off
into
the
world.
Let
it
do
its
job
and
it
will
go
ahead
and
you
know
if
those
containers
would
need
to
be
and
compute
a
function
properly
right.
But
what
happens?
You
have
say
a
whole
bunch
of
containers
right,
hundreds
or
thousands,
and
you
have
a
whole
bunch
of
ships
right.
B
How
do
you
coordinate
you
know
what
containers
go
on,
what
ships,
where
that
ship
should
go,
what
they
should
be
doing,
and
for
this
you
need
some
high-level
constructs
than
just
the
actual
container
system
itself,
and
so
this
is
where
orchestrators
come
in
and
can
help
solve
this
problem
right.
So
their
key
advantage
is
that
as
a
developer
or
an
organization,
you
can
simply
provide
em
a
description
of
an
application
for
a
service
right.
You
can
say:
I
have
application
that
requires
these
containers.
B
You
can
deploy
your
application
without
you
worrying
about
you
know
what
hardware
is
running
on
or
the
underlying
details,
and
you
can
do
this
very
very
quickly
right,
so
we
can
go
ahead,
deploy
your
application
use,
containers
that
come
up
quickly.
It
can
then
scale
them.
You
can
update
them
and
then
also
stop
them
as
needed.
You
can
even
perform
maintenance
tasks
here
as
well.
B
So,
for
example,
if
your
or
appreciator,
like
kubernetes
notices
that
one
of
your
particular
nodes
or
pods
is
unhealthy,
they
can
actually
stop
it
automatically
spin
up
a
new
copy
and
restart
it
and
kind
of
have
some
self-healing
properties
without
your
users
experiencing
potentially
any
issues.
So
it
kind
of
provides
that
additional
layer
of
that
infrastructure
lends
itself
extremely
well
to
automation
and
programmatic
interaction,
which
makes
this
really
great
to
work
with
again
at
scale
and
within
your
pipelines.
B
You
also
aren't
trying
to
stamp
out,
say
a
monolith
and
number
of
times
where
you
only
needed
to
actually
scale,
and
particular
proportion
are
part
of
that
model
element.
So
it
gets
more
efficient
there
as
well.
You
have
the
same
isolation
between
services,
so
it
allows
you
to
actually
have
reduced
testing
surface
area
as
well.
So
if
they're
wrapping
a
micro
service,
for
example,
you
can
accompany
for
not
touching
anything
broader
than
the
actual
the
whole
product
you're
not
deploying
the
whole
thing
anyways.
B
It's
your
only
deploying
and
revving
in
the
individual
component,
and
you
guys
that
course
just
make
sure
it
that
that
one
continues
to
work
with
the
surrounding
services,
and
this
all
boils
up
to
allowing
you
to
having
the
ability
to
more
quickly
iterate
on
each
individual
component
by
being
able
to
deploy
it
selectively
scale
individually
and
also
have
a
reduced
testing
surface
area
there
as
well.
So
that's
a
really
quick
introduction
to
some
of
the
key
tenants
there
of
cognitive
computing
and
with
that,
let's
get
into
why
it's
so
important
right.
B
So
why
should
you
go
down
the
path
and
micro
services?
Why
should
you
and
have
embraced,
kubernetes,
perhaps
and
go
on
and
build
doctor
container
applications
so
outside
the
benefits
earlier
well,
this
case
for
sure
went
through
and
did
a
comprehensive
development
survey
in
2017.
So
this
year,
right
and
the
top
four
priorities
that
came
up
from
their
survey
for
the
following
items
developers
wanted
to
increase
automation
of
your
SDLC
process.
They
wanted
to
use
more
cloud
based
development
environments.
B
They
wanted,
to
course
improve
the
customer
experience
and
the
metrics
therein,
and
also,
of
course,
to
improve
and
speed
up
their
cycle
time
for
the
right
that
they
can
actually
iterate
on
their
software.
So
these
are
all
pretty
important
tasks,
but
they're
all
fairly
interrelated
as
well,
and
they
also
have
a
lot
to
do
with
cloud
native
and
its
goals
as
well
here.
So
let's
talk
about
these
in
more
detail
here.
B
The
first
and
kind
of
most
important
to
your
business,
of
course,
is
improving
the
customer
experience
right,
because
every
company
these
days
is
either
a
software
company
or
going
to
become
a
software
company.
That's
because
more
and
more
the
customer
experience
is
in
fact
digital
handled
by
software.
For
example,
you
know
how
many
folks
to
go
to
the
bank
and
actually
say
cash.
A
check
someone's
really
by
walking
in
almost
no
one
does
anymore
to
take
a
picture
on
your
phone
deposit
electronically
has
a
much
better
experience
right.
B
So
that's
just
one
example,
but
you
know
if
you
weren't,
trying
to
take
this
seriously.
If
you
were
having
two
little
presents
that
you're
actually
competing
on,
you
know
so
I
also
come
in
and
do
it
or
a
startup
will
and
your
business
will
be
in
trouble
right.
So
this
is
really
important
to
try
and
make
sure
you're
living
a
great
customer
experience.
B
B
If
I
increase
in
the
cycle
time
and
iterating
more
quickly,
you
can
deliver
smaller
features
and
actually
learn
for
them.
Right
so,
instead
of
perhaps
having
this
big
type
of
zigzag
approaches,
you
can
more
finely
tune
the
software
delivering
based
on
feedback.
You
can
also
adapt.
Liana
can
make
kind
of
changing
market
conditions
as
well
much
much
more
quickly
right,
and
so
you
can
arrive
at
the
optimal
solution,
much
more
quickly,
much
more
efficiently
with
less
waste.
B
If
it
had
took
this
longer
cycle
times
where
it
would
take
you
perhaps
months
or
weeks,
for
example,
to
just
get
initial
revisions
out
to
your
customers,
so
that's
like
I,
see
a
really
important
way
to
make
sure
you're
putting
the
right
things
for
your
customers
at
the
right
time.
So
then,
how
do
you
actually
speed
up
the
cycle
time
right?
How
do
you
achieve
this?
Well,
of
course,
a
key
component
is
to
automate
the
entire
SPLC
process
or
as
much
as
you
possibly
can
a
few
humans
evolve
and
the
release
or
the
deployment
process.
B
You
know
it
can
take
a
long
time,
you're
wasting
effort
by
having
people
doing
this.
It's
also
error-prone
right.
So
if
you
actually
want
to
be
able
to
achieve
the
ability
to
deploy
every
day
every
hour,
maybe
even
every
week,
you
really
want
to
make
sure
you
had
their
type
of
automated,
so
it's
reliable
as
hands-free,
and
you
can,
of
course
again
continue
to
increase
that
cycle
time
and
ship
additional
content
more
quickly
and
smaller
pieces,
and
so
I
know.
How
do
you
automate
this?
B
B
B
If
it
gets
sick,
you
know
people
are
crying,
it's
a
problem
and
the
better
model
is
to
make
sure
that
you
can
actually
have
resiliency
built
in
and
you
can
deploy
fixes
and
perhaps
even
necessary
rollback
much
more
quickly,
kinda,
like
a
herd
model
rate,
so
poor
cat.
Alright,
you
take
a
quart
of
kettle.
If
one
gets
sick
doesn't
really
matter
all
that
much
you
have
many
many
more.
They
can
take
a
place
and
maybe
that
one
goes
off
nights.
B
We
had
McDonald's
or
something
like
that
right,
but
the
the
show
goes
on
and
it's
not
that
much
of
an
issue.
So
this
is
the
model
you
want
to
go
to
know,
make
sure
you
have
resiliency
and
a
lot
of
dick
and
the
cloud
native
architecture
and
components
can
help
you
achieve
that
with
the
micro
services,
the
resiliency
they're
in,
and
also
the
ability
for
corpus
traders
to
kind
of
deploy
software
automatically
as
you're
defining
it
for
their
organization.
B
So
that's
some
of
the
benefits
there
of
cloud
native,
and
so
let's
talk
a
little
bit
about
some
challenges
you
might
encounter
along
the
way
here.
So
one
of
them,
of
course,
is
DevOps
right.
So,
as
you
have
your
developers,
who
are
now
responsible,
with
perhaps
building
docker
containers
and
responsible
for
kind
of
controlling
how
much
resources
they
require,
what
network
ports
are
required
within
the
orchestrator.
B
The
media
involved
inherently
more
on
the
operational
side
of
things,
and
so
you
need
to
have
a
healthy
and
matured
device
organization
to
have
that
collaboration
and
the
lines
of
communication
open
between.
Perhaps
your
production
team,
or
how
they
look
in
their
organization
in
your
dog's
team
and
ideally
have
them
functioning
as
one
inclusive
whole,
because
then
I
blame
together,
more
and
more
as
time
goes
on
so
depending
on
where
your
company
is
and
that
maturity
cycle.
B
You
know
this
could
potentially
be
a
relatively
large
hurdle
depending
on
how
sort
of
a
set
in
your
wager
branch,
your
company
is
from
a
culture
standpoint
similar
to
the
kind
of
culture
is
the
technology
right.
So
if
you
are
still
sort
of
in
the
virtual
machine
era
and
running
things
that
way,
it
might
be
more
of
a
transition
to
move
on
to
containers
and
to
orchestrators
into
some
of
the
cloud
providers.
Other
services
you
can
use
Java,
you
know
kind
of
embrace
that
cloud
native
model.
B
Perhaps-
and
you
used
to
maybe
with
a
mounting
application,
trying
to
figure
out
what
happened.
Kushal
request
that
generated
an
error
might
involve.
You
know
a
handful
of
different
micro
service
calls
and
tracing
that
and
figuring
out
where
the
issue
was
again
perhaps
could
require
some
new
tooling
from
the
organization,
and
so
you
want
to
make
sure
you're
set
up
for
that
and
I'm
able
to
handle
it
has
that
occurred.
B
B
Second,
trying
to
identify
a
good
candidate
application
or
service
trend
or
not
right,
so
find
one.
That's
low
risk
relatively
small
and
you
can
go
ahead
and
you
know
kind
of
try
things
out
and
learn
how
to
run
these
things
at
scale
with
customers
kind
of
in
the
real
world
right,
and
so
you
know,
don't
pick
the
most
sensitive
high-risk
project
right
so
choose
one!
B
Next,
of
course,
to
make
sure
you
have
a
conducive
Delmon
tool
chain,
so
perhaps
some
a
tool
that
you're
using
in
the
past
might
not
be
so
relevant
in
this
model
right,
you
may
have
some
new
challenges,
for
example,
on
troubleshooting
or
monitoring,
and
things
like
that,
and
so
you
know
kind
of
keeping
the
eye
on
things
in
that
regard.
As
far
as
you
know,
Israel
and
chain
is
still
supporting
you.
As
you
move
towards
a
cloud
native
architecture.
B
Finally
courses,
then
just
start.
Actually,
you
know
automating
your
pipeline
right,
so
you
want
to
make
sure
you
can
go
ahead
and
build
your
backup
files
automatically
and
then
take
those
deploy
them
to
perhaps
some
dynamic
environments
to
have
your
developers
to
see
the
code
live,
interact
with
it
and
make
sure
it
looks.
B
Good
doesn't
just
look
on
a
paper
on
the
merger
quest
page,
but
also
actually
interacts
and
looks
correct
if
you're
actually
looking
at
from
the
perspective
of
the
user
and
then
also
we
should
continue
to
automate
the
deployment
process
all
the
way
through
to
ideally
production
as
well.
All
the
perhaps
you
know
again,
there
might
be
some
gates
there
from
manual
intervention
as
you
kind
of
progress
down
that
path
and
then
once
we've
had
your
pipe
go
animated.
Of
course,
then
you
want
to
ship
iterate
and
learn
right,
so
get
it
out.
B
There
figure
out
what
happens,
figure
out
kind
of
issues
running
into
you
and
how
you
can
troubleshoot
them.
What
tools
have
gone
the
way,
they'll
document
all
that
process
and
really
kind
of
share
that
knowledge,
then
with
the
next
team
right.
So
we've
seen
that
effectively
where
you
can't
take
that
one
small
application,
you
establish
some
best
practices.
What
works
for
your
organization,
your
culture
and
then
you
can
then
use
those
and
also
perhaps
seed
some
of
the
next
team
with
those
same
people.
B
B
We
used
to
run
a
web
scale,
multi
thing
that
SAS
platform
is
also
the
ones
that
give
to
our
customers
so
pushed
and
run,
and
so
they
can
kind
of
offer
the
same
monthly,
don't
scrape
abilities
to
their
own
internal
customers,
and
we
deliver
this
primarily
as
what
we
call
our
omnibus
package
as
our
foundation
right
and
what
this
is.
It's
really
a
package
that
has
a
whole
bunch
of
stuff
in
it
right,
so
we
have
multiple
parts
that
get
labs.
B
Those
are
all
baked
in
there,
but
we
also
have
all
of
our
dependencies
and
all
of
the
other
attendant
kind
of
intelligence
and
deployment
tools.
Also
baked
in
as
well
so,
for
example,
that
one
package
contains
Postgres
reddits,
nginx
matter
modes,
the
container
registry,
Prometheus
and
even
more
right
so
includes
everything
you
need
to
have
a
completely
full-blown
get
let
deployment
all
in
one
place
right.
So
you
have
mobile
processes,
multiple
services,
multiple
ports,
always
going
to
software
all
living
in
the
same
place.
B
Now
that's
pretty
complicated,
but
it
has
been
absolutely
fantastic
for
the
traditional
self
host
installations
right,
the
beautiful
VM
or
instead
of
VMs.
You
can
install
this
with
a
simple
app
get
install
command
and
you
get
all
that
complexity,
but
it's
all
been
distilled
with
a
kind
of
our
chef
scripts
to
become
very,
very
easy.
You
simply
run
install
you
want
to
configure.
B
You
now
have
operational
D
live
instance
and
we'd
kind
of
hidden,
all
of
that
complexity
behind
our
kind
of
packaging
scripts,
and
so
it's
been
very,
very
helpful,
not
just
installations,
but
also
for
updates.
But
you
can
imagine
kind
of
come
to
move
this
toward
another
cloud
native
architecture.
There
has
been
some
challenges
right,
so
the
first
iteration
of
our
docker
image
is
based
on
our
newest
package.
B
We
also
have
a
helmet
charts
as
well
that
are
available,
but
they
still
depend
upon
that
same
docker
image
right,
and
so
we
started
to
bump
into
not
just
a
classic
model
of
problems,
but
also
some
additional
problems
with
all
those
extra
services
that
we
are
bundling
in,
and
so
we
had
some
challenges
around
scaling
and
complex
deployments,
again
kind
of
some
of
the
model.
If
right
so,
for
example,
and
trying
to
run
argue
letter
comm
service,
we
had
a
scale
out
on.
B
You
know
some
different
nodes
up
to
ten
twenty
types
of
notes,
and
you
know
we
had
the
same
package
that
are
and
everything
right.
So
we
had
these
scripts
that
deployed
it,
but
then
turned
off
certain
parts
of
the
package.
So
we
weren't
scaling
out
the
entire
thing
to
these
different
services
and
only
scaling
up
the
parts
that
we
actually
needed
to
write
and
so
there's
complexity
there.
B
B
Some
things
down
turn
some
things
on,
and
it
all
took
time
to
complete,
and
so
the
net
result
was
that
you
know
there
wasn't
really
an
easy,
zero
downtime
solution
and
the
cloud
native
kind
of
model,
and
nor
was
there
an
easier
identity
solution.
You
could
kind
of
work
running
this
a
day
and
customers
certainly
did
it,
but
it
wasn't
again
kind
of
meeting
that
cloud
native
architecture
and
it
wasn't
as
easy
or
as
automated
as
we
prefer
in
our
Haunter.
B
So
that's
kind
of
you
know
where
we're
at
right,
but
we're
aggressively
moving
towards
a
more
cloud
native
architecture.
Here
we
that
active
product
underway
to
help
accomplish
this
everything
as
quickly
as
you
possibly
can
here.
So
our
goal
is
to
again
move
towards
a
more
cloud
made,
a
friendly
architecture,
we're
going
to
go
ahead
and
actually
kind
of
offer,
a
smaller
set
of
cloud
native
containers
and
charts
right,
so
we'll
use
a
single
container
for
each
of
our
services
right.
B
So
what
any
ins
forget
lab
we'll
have
our
good
lab
workhorse
our
rails
instance
sidekick
and
other
components.
All
separated
well,
then,
also
have
separate
charts
and
containers
for
the
different
components
like
sidekick
and
unicorn
and
mater
modes,
and
things
like
that
right
so
we'll
have
a
whole
kind
of
collection
of
these
all
individually
available.
B
But
of
course
you
don't
have
to
have
customer
exposed
to
all
that
complexity,
and
so
we'll
still
have
a
sort
of
a
top
level
let
Helms
chart
which
would
be
available
to
deploy
stitch
all
these
together
and
then
have
a
single
place
you
can
pass
configuration
into,
which
would
then,
of
course
pass
that
down
to
the
sub
charts
and
then
they
would
then
of
course,
spin
these
things
up
as
needed.
You
can
figure
them
accordingly.
B
So
that's
how
our
tackling
is
sort
of
the
packaging
and
the
bundling
of
our
service
and
trying
to
split
it
up
and
make
it
more
consumable
and
scalable
and
cloud
native.
But
of
course
that
wasn't
the
only
challenge
you
ran
into
right.
So
we
also
had
some
architectural
challenges
as
well.
So
one
example
is
that
our
get
layer
currently
requires,
like
a
shared
storage
layer,
to
actually
operate
in
a
highly
available
or
a
scalable
way
across
multiple
nodes,
and
that
wasn't
great
because
of
course
became
much
like
a
pet
right.
B
We've
also,
of
course,
found
some
areas
of
our
product
that
you
know,
while
we
thought
were
relatively
split
up
actually
still
had
some
dependencies
right.
We
found,
for
example,
we
can
get
layer
and
we
can
our
rails
layer.
There
were
some
assumptions
made
that
they
were
communicating,
like
you
know,
with
local
files
and
obviously,
once
you
start
to
move
towards
more
of
a
micro
service
model
that
doesn't
work
anymore
because
you
have
to
have
that
network
layer
in
between
and
so
we're
going
through.
B
Finding
these
looking
at
them
and
we're
gonna
solve
them
to
help
again
kind
of
achieve
that
isolation
and
the
cognitive
micro
service
architecture
that
we're
looking
to
achieve
there.
So
that's
some
of
the
challenges
that
we've
run
into
here
at
git,
lab,
I'm,
sure
a
bump
Lacombe
or
as
it
makes
sort
of
moral
progress
here,
but
that's
kind
of
what
our
journey
has
been
and
where
we're
going.
But
again
you
think
it's
totally
worth
it
and
we're
grassley
pursuing
this
and
trying
to
get
those
thousand
as
quickly
as
we
possibly
can.
B
A
What
you're
doing
that
packs
I
can
jump
into
the
question,
so
the
it
appears
that
the
benefits
going
coordinator
are
pretty
obvious,
but
you
mentioned
some
of
the
challenges
and
one
of
the
things
I'm
interested
in
is
a
skew.
It
introduced
all
these
extra
moving
parts.
How
does
that
affect
your
testing
strategy
from
new
software
they're
pushing
out.
B
And
so,
as
we
go
down,
this
path
of
you
know
kind
of
splitting
these
out
we'll
be
making
sure
that
we
course
have
test
covers
across
the
board,
because
a
unit
test
level,
but
also
we
have
the
ability
to
go
ahead
and
deploy
the
full
helmet
chart
and
the
show
that
we
can
actually
set
up
an
environment
and
then
have
an
integration
test
running
against
that
complete
sort
of
deployment
on
kubernetes
right.
So
we're
actually
going
through
that
right
now
and
having
a
pipeline
filled.
So
we'll
go
ahead
and
build
all
the
docker
images.
B
We
can
still
go
ahead
and
after
the
pet
test
pass,
but
that
individual
say
you
know
microservice.
We
can
then
go
ahead
and
actually
kick
off
a
downstream
CI
test
as
well
to
ensure
those
continue
to
pass
and
kind
of
at
that
integration.
Step
I
mentioned
earlier.
Just
got
you
one
of
those
stages
as
well.
So
that's
kind
of
how
we're
looking
to
structure
this
and
I'm
gonna
build
a
pipeline
to
make
sure
that
we
can
of
course,
builder
assets,
but
also
make
sure
they
still
test
and
pass
when
we're
getting
ready
to
release
them.
C
I
just
gonna
add
to
that
that,
on
the
one
hand,
it's
a
little
more
complicated
because
we
have
multiple
targets
now,
and
so
you
know
we
still
have
a
lot
of
customers
using
our
VMs
and
we
definitely
need
to
continue
supporting
that.
And
so
we
have
a
more
complicated
test
strategy
because
we
have
two
targets
but
on
the
other
hand,
going
in
cloud
native
actually
is
a
lot
easier
to
be
able
to
test
these
things
and
cuz.
C
We
can
spin
up
entire
virgin
clusters
to
do
installs
and
we
can
automate
all
of
that,
whereas
I
mean
you
can
do
that
with
VMs.
But
it's
a
lot
harder.
You
know
it's
so
much
easier,
just
doing
it,
but
you
know
spinning
up
a
community
cluster
and
we
can
do
all
that
by
api's
and
even
do
that
in
our
own
CI.
B
Thanks
mark
definitely
keep
putting
up
those
questions
as
we
get
them
in
here.
So
this
is
our
archetype
interface.
I
just
have
a
pretty
comma
and
since
I
actually
deployed
on
kubernetes
here
just
earlier
today.
So
this
is
kind
of
brand
new
here
I'll
go
ahead
and
make
a
new
project
and
we'll
use
a
git
repo
to
make
things
a
little
more
quick,
so
have
a
minimal
Ruby
application.
You
can
use
as
our
soar
testbed
here
when
they
get
public,
because
why
not
I'm
going
to
a
quick
little
repo
import
here?
B
It's
a
couple
of
handful
of
files,
as
you
can
see
down
below,
we've
got
a
docker
file,
so
gem
files
or
su
cuz,
your
typical
ruby
stuff,
and
then
we
have
a
rake
file
on
our
tests
and
then
also
our
basic
Ruby
source
code
here.
But
let's
take
a
look
at
what
else
we
have
going
on
as
far
as
our
sentence,
so
I
can
jump
into
our
CIS
deep
pipeline
settings
and
I
can
go
ahead
and
enable
a
feature
we
call
Auto
DevOps.
B
What
this
does
is
it
actually
sort
of
has
a
pipe
or
has
a
pipeline
definition
built
into
it,
which
can
identify
and
detect
your
code
and
go
ahead
and
build
it.
Translate
it
into
a
document
file.
If
you
don't
have
one
automatic
are
already
included
in
a
repo.
You
can
then
take
that
conductor
container
and
then
deploy
it
into
kubernetes
using
a
helmet
right
that
we
have
by
default.
B
If
you
have
a
helmet
chart,
it'll
actually
already
use
that
as
well,
and
so
it
can
go
ahead
and
kind
of
take
advantage
of
what
you
have
and
if
you
don't
have
something
like
it's
like
our
file,
a
chart
it'll
go
ahead
and
try
and
generate
one
for
you
based
on
weight,
condos,
but
you're
your
repository,
and
so
this
can
make
it
really
easy
to
go
ahead
and
kind
of
start
to
flowing
into
kubernetes
with
your
software
here.
So
we're
go
ahead
and
save
this
and
I
think
I
mentioned
I
click
there.
There.
B
That's
not
turned
on
right,
so
we
have
kind
of
an
automatic
pipeline.
We
can
then
take
a
look
at
what
runners
we
have
available
for
us.
In
this
case
we
have
a
runner
already
set
up.
If
you
take
advantage
of
our
kubernetes
installation
method
or
a
helmet
chart,
you
get
a
runner
automatic
you
configured
for
you.
If
you
don't
have
a
runner,
you
can
of
course
go
ahead
and
configure
your
own.
This
is
kind
of
what
powers
our
CI
you
will.
B
We
also
have
some
integrations
that
come
out
of
the
box
here
as
well
when
you're
deploying
on
the
kubernetes.
Of
course,
you
they're
kubernetes
cluster
information.
Again
this
comes
out
of
metaphase
configured
for
you.
If
you
install
on
kubernetes.
If
not,
you
simply
enter
this
manually
for
your
own
cluster
and
then
we
also
have
Prometheus,
which
is
an
open-source
monitoring
solution
which
is
also
great
for
cutting
applications,
and
we
can
use
this
to
go
ahead
and
get
metrics
on
the
applications
that
we
actually
do
deploy
into
kubernetes.
And
so
that's
we've
got
going
on
here.
B
Mm-Hmm
so
we'll
go
ahead
and
take
a
look
at
our
Surrey
serve
it
up.
Rb
file.
Little
unlike
a
quick
change
will
say
you
know
hello,
brave
new
world
here,
Lucia
commit
right
back
into
master
and
you
can
see.
We
now
have
a
pipeline
now
run
it
right.
So
in
this
case
we're
going
to
go
ahead
and
take
that
sucker
file,
which
is
in
a
repository,
build
it
right.
So
we
got
duck
a
container.
We
can
then
use
that
to
go
ahead
and
run
tests
against
and
then
we'll
go
ahead
and
I'll.
B
She
then
deploy
it
into
production
in
this
case
directly,
because
we
committed
in
this
case
directly
into
master.
So
that's
pretty
cool
with
a
pipeline
are
a
learning
for
us
deploying
our
first
version
out
into
the
world.
Let's
go
ahead
and
do
a
kind
of
more
typical
update
here
you
can
see.
We
have
a
to
do
that
was
sort
of
waiting
for
us,
so
we
can
go
ahead
and
remove
that
and
add
this
so
we'll
say
we'll
add
HTML
right
so
I'll
say
HTML,
hello,.
B
Can
type
we'll
be
all
set
there?
We
go
that
looks
good,
so
we'll
go
ahead
and
commit
that
we'll
make
a
new
branch,
because
we
want
review
and
make
sure
we
get
the
HTML
correct,
for
example-
and
this
is
course
the
best
breakfast
here
not
to
just
be
coming
directly
in
a
master,
so
we'll
go
ahead
and
create
a
merge
request.
So
you
can
review
our
changes,
and
here
we
go
and
of
course
now
have
a
new
merger
cuts
running
here.
B
Our
new
pipeline
running
you
can
see,
we've
got
our
billow
stage,
which
is
our
already
running
as
well.
We
also
have
our
test
stage
so
go
ahead
and
when
I
study
analysis
report
of
our
code
repository,
so
we
can
see
if
it's
any
kind
of
our
abilities
or
things
when
we
build
we're.
Oh
we
run
our
tests
in
this
case
run
rake
because
it's
Ruby
so
can
automatic
and
get
that
running
and
they'll
also
create
a
movie
application.
B
So,
let's
take
a
look
at
what
this
looks
like
here
in
these
bill
box,
so
you
can
see
in
this
case
we
went
ahead
and
are
building
our
docker
file
based
application.
Again,
if
you
didn't
have
a
docker
up
a
diaper
file,
we
would
suck
your
code
and
go
ahead
and
actually
build
a
car
file
for
you,
based
on
what
we
find.
So
that's
already
complete
and
you've
uploaded
it
to
our
registry.
So
that's
great!
You
can
see.
We
also
have
our
tests
running
here.
They
just
passed
as
you
can
see.
B
In
this
case
we
detected
that
your
Ruby
application,
and
so
we
wouldn't
had
executed
just
simply
been
rake
tests
and
that
also
passed
so
that's
great
to
see
so
going
back.
We're
gonna
have
our
second
analysis
run,
which
completed,
and
then
we
had
our
AV
application.
So
review
ups
are
pretty
cool
in
this
sense
because
we
have
the
orchestrator
and
we
have
our
containers.
It
becomes
us
mark
mentioned
earlier,
really
easy
to
go
ahead
and
simply
stand
up.
B
Temporary
dynamic
environments
right
the
benefit
here
is
that
your
course
would
go
in,
and
you
can
see
the
code
changes
which
look
pretty
simple,
but
you
know,
the
real
kind
of
test
course
is
to
actually
look
at
this
running
live
on
an
environment.
As
you
can
see,
we
have
a
link
right
here.
I
can
click
on
and
I
can
take
a
look
at
that
change.
I
just
made
running
on
a
real
environment,
real
containers
running
on
kubernetes
and
make
sure
that
it
looks
good.
So
that's
pretty
cool.
It
looks
great.
B
The
other
neat
thing
that
you
can
see
here
is
that,
with
the
static
analysis
run,
you
can
see
we've
actually
improved
our
code
quality
right.
So
what
happened
here
is
that
we
actually
ran
this
that
analysis
job.
We
collected
the
results
we
actually
compared
the
results
that
we
got
back
to
our
master
branch,
which
is
where
I'm
merging
into-
and
you
can
see
in
this
case
that
we're
simply
telling
you
you
know
what
you
actually
cleaned
up
and
addressed
that
to
do
for
him,
and
so
you
fix
that
problem,
and
so
that's
pretty
cool.
B
It
doesn't
give
you
the
whole
report
of
all
the
findings,
just
the
Delta
between
these
two
branches,
which
other
reviewer
is
what
you
particularly
care
about.
So
now
this
looks
great
right.
The
code
changes
look
good,
the
analysis
looks
good
and
a
review
application
look
exactly
the
way
we
wanted
it.
So
we
can
go
ahead
and
hit
merge.
B
This
will
continue
on
to
tearing
down
a
review
in
Ramat
to
save
some
resources
and
then
kicking
off
another
pipeline
here
to
deploy
back
into
production
for
our
new
version
of
code.
So
let's
take
a
look
at
production
here,
so
here's
our
production
environment,
we
can
click
down
and
we'll
see
that
we
have
a
representation
of
our
deployment
right.
So
this
is
actually
a
pod
by
pod
view.
Pods
and
kubernetes
speak
is
sort
of
like
a
node
or
the
instance
of
the
container
that
is
running
and
you
can
see.
B
We
have
one
instance
here
which
is
running
and
it's
healthy
all
right.
So
that's
great
thinking
in
this
case,
if
it
wasn't
healthy,
kubernetes
could
kick
in
and
actually
go
ahead
and
try
to
restart
it
if
necessary,
to
fix
some
problems.
We
also
can
simply
pop
open
our
monitoring
dashboard
and
take
a
look
at
that.
But
first,
let's
take
a
look
at
our
environment.
You
can
see
in
this
case
wrists
are
running
our
previous
old
version
right,
so
our
hello
will
brave
new
world
in
this
case,
because
our
pipeline
hasn't
quite
finished
just
yet.
B
B
You
can
pull
that
error
rate
latency
and
the
throughput
I
think-
and
this
is
all
coming
from
the
metrics
that
get
built
in
to
nginx
ingress
and
the
community
side,
and
also
on
the
q
and
a's
nodes,
which
report
back
things
like
CPU
and
memory
right,
so
you
kind
of
get
built
in
metrics
with
kubernetes,
which
is
fantastic
all
right.
So
actually
this
case,
you
can
see
that
we
just
went
ahead
and
deployed
our
latest
version
of
code.
Mr.
Scott
get
it
about
a
minute
ago.
Let
me
pop
back
open
here.
B
You
can
see
we
have
our
new,
updated
version
already
deployed,
which
was
great,
and
you
can
see
how
easy
it
is
to
go
ahead
and
deploy
into,
for
example,
at
Keuka
days
and
automating
your
pipeline
here,
and
it
gets
also
even
easier
right,
so
I
mentioned
before
how
kubernetes
can
easily
scale
your
application.
So
if
we
pop
in
here,
for
example,
I'm
gonna
see
I
see
settings,
we
can
actually
tell
our
script
to
increase
the
number
of
replicas
that
we
want
the
number
of
pods
or
nodes.
B
B
We
redeployed
and
in
a
couple
of
seconds
here
we'll
go
from
one
pot
to
five
as
we
rerun
that
job
and
not
get
an
example
of
again
how
easy
it
is
the
scale
you
can
do
it
coordinates
on.
Like
you
see
here,
you
also
can
set
up
auto
scaling
routines
on
current
itself,
the
handles
automatically
for
you.
This
is
a
bunch
of
options
there
for
handling
sort
of
how
elastic
you
want.
B
But
in
this
case
you
can
see,
for
example,
that
we
have
now
a
five
total
one
of
course
is
currently
running
and
we're
now
spinning
up
the
rest
of
the
four
here
automatically.
As
you
can
see
so
pretty
awesome
there
around
how
easy
again
it
is
to
work
with
kubernetes
and
scale
up
scale
down
update
as
well.
B
So
we've
been
using
here
sort
of
that
kind
of
auto
devops
ii
pipeline,
but
you
can
actually
take
a
look
at
that
pipeline
in
our
template
library
right.
So
we
have
a
great
library
of
a
bunch
of
samples
for
a
variety
of
languages,
but
in
this
case
let's
take
a
look
at
our
DevOps
template
and
you
can
see
exactly
all
of
the
logic
that
we
use
to
build
this.
So
you
can
see
we
have
a
filled
stage,
art,
sjh
review
and
some
additional
stages.
You
might
have
have
a
scene
before
like
staging
and
canary.
B
B
And
if
it
is,
you
can
continue
that
the
rest
of
the
voice
across
the
rest
of
your
fleet
safely
within
begin
with
reduce
risk
right.
So,
as
you
kind
of
consider,
your
iteration
cycle
know
some
Advanced
Diploma
strategies
like
Canaries
here
can
really
help
to
reduce
risk
maintain
velocity,
and
this
is
just
one
example
of
how
easy
it
is
with
okay
leveraging
cloud
notifications
like
kubernetes
here.
B
B
So
if
you're
familiar
with
secrets,
are
sort
of
like
configuration,
settings
in
Canaries,
land
and
it'll
go
through
and
create
deployments
and
services,
and
also
the
storage
or
a
PVC,
as
you
can
see
how
that
works
here
as
far
as
the
output
and
then
again,
the
actual
job
is
available
in
our
template.
What's
the
full
details,
so
I
think
we'll
pause
there
for
any
kind
of
questions
or
you
might
people
might
have
on
this
particular
verse
with
example.
Our
demonstration
here.
A
Hey
thanks
for
that
Josh
I,
don't
know
if
everyone's
feeling
very
shy,
but
we've
had
no
questions
so
far,
which
I
think
means
that
you're
just
you're
just
nailing
it
so
much
we've.
You
know,
there's
no
actual
information
required,
but
I'd
say
just
just
keep
going
around
and
maybe
they'll
pop
up
at
the
end.
B
Okay,
so
we
can
do
we
can
go
ahead
and
actually
do
a
quick
deploy
of
Canaries.
So
let's
go
through
and
take
a
look
at
our
pipeline
here
but
see
what
that
would
look
like.
So
we
can
go
through
find
our
canary
job
here,
uncomment
that
go
to
our
production
job
and
make
this
manual.
And
this
way
you
can
have
a
manual
sort
of
trigger
to
go
through
and
complete
that
the
clément
will
commit
this
back
in
the
master
and
you
can
see
we'll
have
a
new
piping.
B
That's
now
running
and
we'll
have
a
new
job,
that's
available,
which
is
now
our
canary
job.
So
it's
like
a
couple
seconds
to
go
through
and
rebuild
our
container
and
complete
our
test,
but
then
you
can
see,
for
example,
in
this
case
illustration,
what
I
can
you
know
canary
looks
like
here?
It's
not
gonna
have
a
different
sort
of
UI
since
we're
leveraging
the
same
sort
of
code
base,
but
you
don't
see
the
stage
pop
up
here
as
well.
B
So
you
take
a
look
at
the
build
stage
that
actually
complete
it.
If
they
can
look
code
quality
here
as
well,
can
see
you're
pulling
the
container
down
to
go
ahead
and
run
the
code,
quality
analysis
and
once
we're
done
with
that,
we'll
persist
the
JSON
output
and
then
use
that
for
comparison
to
the
sort
of
destination
brands
in
this
case
running
on
master.
B
So
thank
you
a
couple
of
seconds
here
we're
spinning
up
our
runner,
a
runner
actually
by
the
way,
which
is
what
processes
the
CI
jobs
can
elastically
scale
itself
to
handle
your
queue
depth,
and
so
it
only
consumes
much
resources
as
required
to
process
your
CI
job,
and
so
in
this
case
you
can
see
just
completed
the
deployment
we
went
through
insured
killer
ones.
There
we
go
through
and
deployed
our
canary.
So
now
they
pop
back
over
to
our
environment.
B
B
This
is
the
same
code
base
in
this
case,
but
normally
you'd
have
say
four
sample
at
different
revision
running
in
the
canary,
and
so
in
this
case,
one
out
of
every
sixth
request
would
get
fed
automatically
to
the
canary
and
when
you
can
have
again
that
limited
testbed,
for
example,
and
then
once
you're
happy
with
it,
you
can
simply
go
ahead
and
complete
the
deploy
to
production.
So
we
should
spend
down
the
canary
and
take
the
container
and
deploy
it
out
across
the
rest
of
the
deployment
here.
B
A
Thanks
for
that
Josh-
and
it
turns
out
that
actually
I
want
to
apologize
for
those
people
who
are
asking
questions
due
to
some
quirk
in
the
UI
here.
I
couldn't
see
them,
but
from
the
other
panelists
could
so.
There
have
been
a
couple
of
questions
coming
through,
and
the
first
one
is
from
Mark
Bell
who
asks
in
terms
of
cloud
native
adoption
within
the
enterprise
space.
How
far
along
is
the
market?
Five
cent
25%
more.
C
That
is
a
great
question.
I
wish
I
had
hard
numbers
on
this.
All
I
can
go
by
here
is
sort
of
you
know
our
segment
of
folks
that
you
know
our
customers
run
on
or
what
we're
seeing
you
know,
sort
of
anecdotally.
My
gut
is
that
it's
you
know
somewhere
between
the
five
and
twenty
five
percent
part
I
know
that
a
lot
of
enterprises
are
toying
with
cognitive
or
more
specific
eyes
like
playing
with
comedians.
C
You
know
like
everybody's,
doing
something
with
docker
and
usually
you
know,
you'll
start
with
docker
in
a
test
environment
like
maybe
you're,
using
it
literally
in
front
of
your
CI,
or
something
like
that
or
you
make
a
bunch
of
docker
images
for
a
whole
bunch
of
stages
except
deployment
into
production,
and
then,
when
people
get
into
production,
cooking
users,
it's
clear
the
top
thing
that's
on
their
mind,
but
most
enterprises
are
still
just
still
playing
with
it.
They're
still
trying
to
figure
it
out.
C
A
Thanks
mark
there's
another
question
here
which
actually
Camille
had
to
post
through
it's
worth,
pointing
out
that
if
you
are
now
putting
questions
into
the
Q&A,
don't
do
that
so
I
can't
see
them
drop
them
into
the
chat
instead.
I'm,
sorry
that
I,
don't
know
your
name,
but
whoever
it
was
to
ask
the
following
question.
Thank
you
for
that
question
is
with
security
being
a
big
concern
within
the
enterprise,
and
underlying
infrastructure
is
typically
behind
corporate
proxies
and
firewalls.
A
D
Yes,
this
is
a
very
good
question
because,
like
I
get
up,
we
always
put
a
lot
of
emphasis
on
the
security
among
Enterprise
Solution.
So
I
would
say
that
the
key
fob
is
basically
this
kind
of
solution
that
tries
to
figure
out
the
best
practices,
the
best
tools
that
could
be
using
enterprise
and
tries
to
integrate
them
into
the
product
that
actually
makes
it
very
grounded
in
your
infrastructure
that
is
behind
the
corporate
firewall.
D
One
of
these
example
races
exactly
container
registry,
something
that
is,
if
you
try
to
do
it
manually
kind
of
complicated
to
set
up,
but
with
the
way
how
they
get
up
basically
beats
that
time
interacts
with
that.
It
just
becomes
the
breeze
to
use
that
another
example
is
the
integration
with
chrome.
It
use
its
yet
another
we're
good
integration
that
the
kid
lab
is
proposing.
A
B
If
you
get
a
couple
more
slides,
we
can
just
go
through
while
we're
waiting
for
our
questions
here,
but
basically
we're
pretty
much
essentially
done
here,
just
be
complete
data.
Basically,
this
is
sort
of
what
we're
going
through
here
and
also
what
we're
trying
to
help
enable
folks
with
get
web
to
be
able
to
have
a
sort
of
complete
process
from
planning
creation,
the
package
or
leaves
configure,
deploy
and
monitor
and
then
can
take
those
learnings
and
funnel
it
back
into
the
system.
So
this
is
kind
of
like
our
goal
and
our
vision.
B
We
announced
it
here
actually
for
our
2018
plan,
so
link
at
the
bottom
for
curious,
I'm
checking
out
of
more
detail
where
we're
going.
What
we
really
want
trying
to
make
sure
we
do
is,
you
know,
enable
more
folks
to
embrace
clinical
applications
and
we
can
make
it
as
easy
as
possible
as
sort
of
what
Camille
mentioned
Florence
and
the
work
on
the
container
registry
that
we
can
serve
them.
They
get
turnkey
where
otherwise,
it
might
be
a
little
more
work
to
get
up
and
stand
up
in
your
own
environment.
A
A
A
A
Thank
you
mark,
if
you,
if
you,
if
you
have
watched
this
and
either
were
brave
enough
or
couldn't
think
of
the
question
at
the
time,
we
can
provide
contact,
details
which
speaks
later
and
we'll
do
I'll
provide
the
link
at
the
end,
so
you
can
see
where
to
go
for
that
kind
of
stuff.
All
this
left
me
to
do
is
thank
Josh,
mark
and
Camille
for
a
fantastic
webinar
and
to
thank
you
all
for
coming
along
and
supporting
coming
up
with
the
questions
today.
A
C
A
My
pleasure
thanks
again
Oh,
actually
one
thing
I'll
do
is
I
put
this
link
here
in
the
in
the
chat.
If
this
is
your
first
CN
CF
webinar,
you
can
go
there
and
see
all
the
ones
that
we
have
coming
up.
We
were
initially
running
them
monthly,
but
now
we're
going
to
bi-weekly
and
there's
lots
and
lots
of
good
content
like
this
coming
through.
So
it's
worth
keeping
me
on
there
and
signing
up
in
advance.
That's
it
for
now.
Thank
you.
Everyone
and
goodbye.