►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Escaping the Jungle - Migration to Cloud Native CI/CD - Anton Weiss, Otomato Software
In the last 2 years Otomato has been helping a number of software companies to migrate their complex systems to Cloud Native infrastructure. This included rebuilding the CI/CD processes and tooling based on Cloud Native concepts and tooling. In this talk Anton will present the challenges organisations face when switching to modern approaches in software delivery. We will cover the topics of: - Providing unified kubernetes-based CI/CD infrastructure - Scalable CI/CD Pipelines and Environments - Component and Contract testing vs. End-to-End testing - Managing Deployments with Helm - Evaluating Service Meshes - Making the switch to GitOps
https://sched.co/Zesu
A
A
Well,
that's
probably
if
you're
as
old
as
I
am
well
for
us
at
automato
software
in
the
last
couple
of
years,
jungle
began
began
to
signify
a
certain
stage
in
a
life
cycle
of
an
iit
organization,
a
stage
that
any
successful
company
has
to
go
through
and
also
many
unsuccessful
ones.
But
who
wants
to
hear
these
sad
stories
right?
The
world
is
full
of
sad
stories
as
it
is
so
we'll
be
talking
about
the
successful
ones
and.
A
Well,
how
does
one
get
into
the
jungle?
The
thing?
Why
am
I
talking
about
this
right?
So
I
forgot
to
mention
I'm
a
consultant
and
we
as
a
consultancy
that
what
what
we
do
is
we
help
organizations
optimize
the
way
they
deliver
software
and
we
often
get
called
in
when
a
company
finds
itself
in
a
jungle.
A
So
let's
first
see
how
do
we
get
ourselves
into
a
jungle?
Well
as
any
great
adventure.
It
all
starts
on
on
still
waters
on
a
sunny
day,
we're
probably
a
startup
right
and
we've
succeeded
in
gathering
a
team
of
motivated
individuals,
and
we
want
to
move
fast
and
to
deliver
fast.
So
we
provide
our
engineers
with
autonomy
to
choose
their
stack,
to
make
their
engineering
and
architectural
decisions
to
move
fast
and
break
things,
and
so
we
have
autonomy
and
we
don't
even
need
to
build
any
agile
processes
because
we're
inherently
agile
right.
A
A
Everything
happens
so
fast
and
now
we're
in
the
jungle,
welcome
to
the
jungle
and
what
happens
in
the
jungle
we
look
around
and
we
suddenly
see
we
have
all
the
languages
and
all
the
frameworks
and
all
the
databases
and
all
the
message:
queues
and
dozens
of
cloud
services,
hundreds
of
ci
jobs
and
the
technical
debt
that
we
were
so
eagerly
accumulating
in
order
to
move
fast
is
now
piling
all
of
our
all
around
us.
So
why
is
being
in
the
jungle?
So
scary?
A
Well,
first
of
all,
it's
now
very
hard
to
do
the
next
thing,
because
each
time
we
want
to
choose
a
tool
or
a
process
to
do
something,
it's
very
hard
to
decide
because
everybody
wants
to
use
their
own
and
we
spend
weeks
discussing
these
decisions
and
they
all
this
indecision
causes
a
lot
of
waste
right
and,
of
course,
all
these
companies
that
we've
built
out
are
now
now
need
to
be
integrated,
and
this
integration
is
painful
and
well.
We
continue
hiring
because
the
money
is
on
the
table,
but
on
boarding
the
new
employees
is
hard.
A
A
A
Well,
the
way
to
escape
the
jungle
is
finding
what
charity
measures
calls
the
golden
path
by
the
way,
if
you
know
who
charity
measures
is,
send
a
c
to
the
session
chat,
and
if
you
don't
know
who
charity
majors
is,
then
do
yourself
a
favor
and
find
her
blog
and
follow
her
on
twitter.
Her
twitter
handle
is
right
there
and,
while
you're
at
it
follow
me
on
twitter
too.
My
twitter
handle
is
at
the
bottom
of
the
slide,
so
charity
has
this
great
post.
A
A
Well,
the
golden
path
is
that
way
that
makes
it
easy
for
the
engineers
and
organization
to
deliver
and
build
software
right.
The
golden
path
provides
the
answers
to
the
questions
of
how
we
do
things
at
the
organizations
how
to
build
test
package
version
deploy.
You
know
how
to
read
now
the
important
thing
to
understand
that
the
golden
path
isn't
the
only
path
and,
of
course
our
engineers
can
challenge
the
path
and
try
to
find
alternative
paths,
because
we
want
to
be
continuously
improving.
A
The
golden
path
does
make
it
easier
for
the
whole
organization
to
work
together.
So
how
do
we
create
the
golden
path,
the
golden
basically
the
grand
great
conceptual
construct,
but
where
does
it
get
implemented?
Well,
first
of
all,
we
need
to
define
our
delivery
toolkit
right,
so
we
need
to
get
an
agreement
of
what
two
links
we're
using
and
we'll
start
with.
You
know
defining
what
we
use
for
source
control
management.
Then
we
need
to
define
what
we
use
for
each
of
the
frameworks,
build
automation
and
then
what?
A
How
do
we
package
our
products
and
how
how
we
store
them?
What
kind
of
binary
repository
we're
using
for
the
distribution
and
we
need
to
define
what
continuous
integration
continuous
delivery
tooling
to
use?
And
then
we
need
to
unify
the
platform
for
the
deployment
and
maybe
decide
how
we
store
the
configuration
and
secrets
across
our
organization.
So
all
our
components
can
be
configured
in
the
same
way
and
then
we
want
to
talk
about.
A
Maybe
you
know,
starting
using
service
meshes
as
the
bleeding
edge
of
the
cloud
native
stack
and
now
after
we've
defined
all
the
tooling,
we
need
to
wire
them
all
together
and
that's
when
we
start
talking
about
the
pipeline
right.
So
here
it
is
the
proverbial
cicd
pipeline
that
takes
our
code
from
the
ideas
to
the
production
that
provides
the
tight
feedback
loops.
That
allow
us
to
create
flow
of
changes
throughout
organization.
A
A
So,
even
when
running
on
the
public
cloud,
they
mostly
used
the
cloud
as
just
you
know,
infrastructure
as
service
without
using
all
the
benefits
of
scalability
and
the
the
dynamic
qualities
of
the
the
cloud
provides,
or
maybe
they
did
use
a
platform
as
a
service,
something
like
a
heroku
look
alike,
but
since
then
they've
outgrown
its
capabilities
by
the
way
why
current
past
solutions
are
limited
in
their
abilities
and
how
and
if
serverless
will
be
able
to
solve.
This
is
a
topic
for
a
whole
another
talk,
but
let's
leave
that
aside.
A
A
So
if
we're
talking
about
cloud
native
ci
cd,
how
is
it
different
from
usual
csd?
Not
non-cloud
native
one
yeah?
That's
a
question
for
you.
I
have
my
own
answers,
but
I'd
love
to
hear
what
you
think
well
for
us
we're
saying
the
cloud
native
city
is
different
because,
first
of
all,
we
want
to
to
see
integrated
with
the
platform
that
we're
running
on,
namely
kubernetes,
and
we
want
to
see
it
utilizing
the
advantages
of
the
scalable
dynamic
platform
using
the
dynamic
agents
and
the
environments
for
build
test
deployment,
etc,
etc.
A
How
do
we
unify
a
modular
system
where
we
have
a
lot
of
frameworks
without
you
know,
breaking
the
autonomy
of
each
component,
we
standardize
on
an
api,
so
exactly
the
same
in
the
same
way
when
building
that
unified
pipeline
for
a
large
organization,
that's
in
the
jungle
right
now
we
want
to
to
build
a
standard
pipeline
api
and
that's
the
model
that
we've
seen
working
quite
well
for
us
in
the
last
couple
of
years.
We
call
it
an
agent
model
flow
pattern
or
an
amf
pattern
right.
So
what
am
I
talking
about?
A
A
Okay.
So
when
building
that
standard
pipeline
api
first
thing,
we
want
to
ensure
that
we
have
a
very
standard
and
simple
interface
for
each
of
our
services.
So
in
each
of
our
services
we
have
a
very
simple
jenkins
file.
This
jenkins
file
here
basically
just
tells
us
what
the
name
of
the
service
that
we're
building.
What?
How
do
we
tag
this
release?
A
And
here
we
start
defining
our
agent
right
here.
This
is
the
agent
definition,
and
then
we
define
our
model
right,
which
basically
is
tied
to
the
product
we're
building,
and
then
we
define
our
flow
and
that's
this
object
that
we're
calling
here
this
function
called
data
service
pipeline
which
receives
the
definition
of
the
agent
and
the
definition
of
the
model
and
the
definition
of
the
service
name
and
its
tag.
A
So
then
we
go
to
the
agent
definition
again.
We
are
using
the
jenkins
kubernetes
plug-in,
that's
very
powerful
here
that
allows
us
to
use
a
whole
kubernetes
pod
with
all
of
its
containers
as
our
environment
for
building
testing
and
deployment,
and
here
we
are
using
one
pod
that
allows
us
also
to
build
java
with
maven
and
deploy
it
the
result
to
kubernetes
with
helm.
A
A
Right
and
then
we
go
to
the
model
definition
we've
defined
our
agent
and
in
the
model
definition
we're
basically
defining
the
api.
That's
where
we
define
the
api,
we're
saying
this
product
defines
the
following
functions
and
that's
where
we
have
the
function
for
build
test
and
deploy
stage,
and
maybe
integration
test
stage.
A
So,
for
example,
here
we
see
that
for
data
products
we
have
this
build
stage
that
builds
java
with
with
the
maven
command
that
you
see,
and
then,
if
we
want
to
define
the
integration
testing
for
such
a
product,
we'll
use
maven
integration,
test
command
and
if
here's
another
product,
that's
a
no
js
product
node.js
service
and
for
it
the
build
function
will
look
differently.
But
again,
this
is
the
same
api
that
allows
for
clean
definitions
of
build
test,
deploy
and
other
delivery
stages
that
we
want
during
our
pipeline.
A
Okay.
So
that's
the
amf
pattern
for
you
now.
Let's
talk
a
little
bit
about
testing
you
see.
Have
you
have
you
heard
about
the
testing
pyramid
if
you've
heard
about
testing
pyramid,
send
a
t
to
the
session
chat
if
you
haven't
well,
basically,
that's
the
model
that
says
that
you
should
invest
the
most
of
effort
in
your
unit
test,
then
a
bit
of
less
effort
in
integration
and
even
less
effort
in
the
end-to-end
testing,
because
it
provides
the
least
value.
A
But
the
thing
is
that,
with
the
cloud
native
cicd,
you
should
probably
not
invest
in
end-to-end
testing
at
all.
From
what
we've
seen
we've
seen
many
teams
struggling
for
weeks
on
end
trying
to
make
their
end-to-end
testing
work
and
investing
a
lot
of
hours
in
maintaining
these
tests,
they're
always
very
brittle
and
provide
very
little
value.
So,
instead
we're
suggesting
an
approach
that
we've
seen
working
much
better,
which
is
replacing
the
end-to-end
testing
with
contract
testing.
If
you
haven't
heard
about
control,
testing
go
and
look
it
up.
A
Online
consumer-driven
contract
is
a
pattern
that
was
first
suggested
by
the
thoughtworks
consultant
and
then
further
implemented
in
such
frameworks
as
pact
and
spring
contract.
It
allows
testing
our
services
in
isolation,
but
still
ensuring
that
we're
not
breaking
contracts
between
them
and
they
do
continue
working
when
deployed
together
as
one
system
now.
Next
thing
after
we've
done
the
pipeline
and
we've
decided
on
our
testing
strategy,
we
need
to
talk
about
how
to
deploy
and
for
the
cloud
native
ecosystem.
Today
helm
provides
a
unified
package
management
experience.
A
If
maybe
a
year
ago,
it
was
still
not
maybe
an
answered,
closed
question
today.
It's
much
clearer
with
helm,
graduating
from
the
cncf
and
well
for
the
services
that
we're
putting
on
the
pipeline,
we're
now
defining
helm,
chart
templates,
so
each
development
team
building
a
new
service
can
scaffold
a
new
helm
chart
at
the
time
of
creating
that
service.
At
the
time
of
scaffolding,
the
service
skeleton
it
has
a
standard
structure.
A
It
defines
the
deployment
and
it
defines
the
configuration
of
the
database
connection,
the
monitoring
connections,
the
message
queue
connections
and
we
have
all
of
this
already
in
place.
It
allows
us
also
to
define
the
standards
of
what
our
services
should
include
like
instrumentation
and
database
and
manage
message
queues
connections
and
also
how
the
service
should
be
deployed
again
the
golden
path.
This
is
the
easiest
thing
to
do.
Of
course
it
can
be
modified,
but
it
doesn't
have
to
be
now.
A
Finally,
after
we've
decided
on
the
basics
on
how
to
build
a
paper
pipeline
on
how
to
test
our
code
on
how
to
deploy
our
code,
we
can
start
thinking
of
the
next
stage
and
that's
providing
those
stress-free
releases
providing
them,
maybe
with
the
service
mesh
capabilities
right.
We
all
know
that
cannery
releases
can
be
made
easier
if
we
use
the
smart
routing
capability
for
capabilities
of
istio
or
linker
d
or
console
of
the
all
of
these
enabled
with
the
service
mesh
interface
spec.
A
So
we
start
thinking
about
that
at
a
certain
point,
but
it
should
be
noted
that
service
mesh
brings
a
lot
more
complexity
into
our
stacks.
So
definitely
look
forward
to
that
start.
Defining
those
things
start
testing
service
meshes
and
make
sure
to
to
not
only
bring
them
in
for
for
the
canneries
and
blue
greens,
but
also
for
their
observability
and
smart
routing
capabilities
test
this
on
the
side.
A
If
you
really
want
a
nice
tool
that
would
allow
you
to
deploy
different
service
meshes
and
may
build
performance
benchmarks
between
them
check
out
meshary,
which
is
a
project
of
the
layer,
5
service
mesh
community
that
I'm
proud
to
be
part
of
and
well.
The
next
thing
is,
of
course,
something
that
you've
many
of
you
have
been
waiting
for.
Should
I
go
for
get
ups
at
this
stage
when
building
my
cloud
native,
ci,
cd
well,
git
ups
is
a
great
approach.
A
I
tend
to
think
it's
nothing
new.
It's
basically
saying
I'm
operating
my
infrastructure
based
on
what
git
says.
Git
is
my
single
source
of
truth
and
I
build
in
the
automation
to
make
sure
that
whatever
git
says
is
the
actual
reality
right.
So
it's
very
easy
to
say
it's
a
bit
harder
to
do
than
to
say-
and
we
do
have
tooling
for
that
today
and
the
tooling
keeps
developing,
especially
now,
with
the
argo
project
merging
with
the
flux
project
from
wework.
A
We
want
to
make
sure
that
while
we
build
the
golden
path,
we
also
build
in
the
map
that
will
show
us
where
to
go
next
and
that
map
will
be
allowed
by
building
in
inside
the
the
delivery
pipeline
building
the
the
metrics
right.
So,
if
we're
trying
to
improve
the
way
we
deliver
software,
we
need
to
be
able
to
measure
if
we're
actually
improving
anything.
So
we
need
to
start
with
measuring
you
know
the
four
metrics
that
the
accelerate
book
recommends
us
to
do,
which
is
lead
time.
A
The
jungle,
as
I
said,
is
always
calling
so
cloud
native
ci
cd
is
your
way
of
speaking
escaping
the
jungle.
It's
not
that
simple,
but
it's
doable.
There
is
a
path
that
you
can
build.
These
are
just
the
recommendations
that
we've
seen
working
and,
of
course
our
landscape
is
changing
all
the
time
and
the
jungle
is
always
lurking
around,
but
together
we'll
find
a
way.
A
A
A
A
A
Well,
tecton
is
actually
a
very
interesting
initiative.
I
call
it
the
the
whole
trend
of
converting
everything
to
custom
resources
in
kubernetes
and
then
writing
controllers.
For
that
I
usually
like
to
call
this.
The
total
searchation
of
our
industry,
but
well
it
is
go.
It
does
go
hand
in
hand
with
the
kubernetes
way
of
doing
things.
Of
course,
tecton
is
still
in
its
very
early
stage.
A
A
A
It's
it's
a
concept,
it's
an
approach
and
well
it's
imp,
implemented
by
a
framework
called
pact
and
in
java
world
there
is
also
spring
contract
library.
So
you
can
look
into
that
now.
Chang
hua
lim
is
asking
if
I've
tried
jenkins
x
and
how
it
compares
with
tecton.
No,
we
we
are
not
working
with
jenkins
x,
yet
jenkins,
x
and
tekton
are
different
from
the
approach
that
I've
described
in
the
presentation
in
that
they're,
fully
totally
integrated
with
kubernetes.
A
Now,
while
the
total
and
full
integration
is
important
for
most
of
organizations
currently
in
the
jungle,
what
we
find
ourselves
ourselves
dealing
with
is
a
hybrid
stack
right,
so
they
don't
have
everything
in
kubernetes.
So
there
is
usually
a
need
to
support
stuff,
that's
outside
of
kubernetes.
That's
why,
for
most
of
the
projects,
where
we've
envisioned
a
need
to
escape
the
jungle,
we
didn't
go
with
those
totally
integrated
tools.
A
A
A
Now
what
I
recommend.
Yes,
I
would
recommend
a
lot
of
other
ci
tools
if
you're
using
the
gitlab
stack
for
at
all
means
go
for
for
the
gitlab
ci
if
you're
already
on
github-
and
you
don't
want
to
introduce
jenkins,
yes
by
all
means,
go
with
the
github
workflows,
you
may
be
missing
some
of
the
stuff
that
jenkins
has
because
jenkins
up
until
now
is
still
the
most
evolved,
continuous
integration
server
out
there,
but
on
the
other
hand,
you
won't
have
many
of
the
much
of
the
legacy
that
jenkins
brings
with
it.
Now.
A
If
we
talk
about
cd
jenkins
is
definitely
not
a
cd
solution.
I
tend
to
think
that
our
industry
currently
lacks
a
mature
cd
solution
for
the
cloud
native
world.
Argo
city
and
flux,
and
probably
argo
rollouts
are
all
looking
in
in
a
very
important
and
right
direction,
but
we
still
have
a
lot
to
learn
about
how
cd
is
done
correctly
in
the
cloud
native
world
and
in
fact,
we've
been
working
on
building
such
a
solution.
A
So
in
line
with
that,
paulo
philippe
is
asking
if
tools
like
flagger
useful
in
my
opinion-
and
it
says
that
they
need
a
very
mature
team.
Exactly
right.
So
flagger
for
those
who
are
not
available
is
a
progressive
delivery
tool
based
on
service
mesh
functionality
based
on
the
smi
spec.
It
can
work
with
this
to
your
linker
d
or
console
connect,
and
it
does
provide
that
important
deployment
strategy.
A
What
do
you
see
as
the
cause
for
brittle
end-to-end
tests?
That's
the
question
that
comes
from
alexander
junger
or
junger,
I
suppose
so.
Well,
the
reason
is
very
simple:
we're
building
microservice
systems.
This
is
a
lot
of
services
they're
all
in
fluctuating
state
in
in
constant
flux,
and
it's
very
hard
to
arrive
at
a
stable
environment
right.
We
don't
have
a
stable
environment
in
our
production.
A
Our
production
is
never
stable
because
things
are
always
changing.
So
how
do
we
expect
to
arrive
at
a
stable,
understandable
environment
in
our
end-to-end
testing?
So
it's
either.
We
freeze
that
environment
and
it
doesn't
provide
any
indication
of
what
production
looks
like
or
what
normal
looks
like,
or
it
has
to
be
always
moving.
And
then
it's
very
hard
to
to
arrive
at
something
that
works
there
and
doesn't
break
with
every
new
commit.
A
So,
boss
van
der
bring
says
the
jungle
is
a
very
liable
environment,
but
we
structure
everything
in
jenkins,
libraries
and
processes.
How
do
we
ensure
that
we
still
have
room
for
incorporating
new
innovations
instead
of
walking
into
the
desert
from
far
from
what's
going
in
the
rest
of
the
world?
Okay,
that's
also
a
good
question.
That's
more
of
a
question
about
the
golden
pass.
As
I
said,
the
golden
path
is
not
the
only
path,
it's
a
path
to
be
challenged
and
much
in
line
with
the
the
sre
philosophy.
A
This
is
how
like
this
is
the
supported
the
easy
way
to
do
things
at
the
organization.
It
doesn't
doesn't
mean
that
it's
the
only
way,
we're
free
to
innovate,
we're
free
to
suggest
our
own
ways,
and
that
means
your
engineers.
Your
teams
can
actually
decide
that
they're,
not
using
the
the
pipeline
api
that
they're
building
and
delivering
things
their
own
way
right.
They
won't
get
the
support
of
a
central
team.