►
From YouTube: From Cloud Naive to Cloud Native – Avoiding Mistakes Everyone Does - Max Körbächer, Liquid Reply
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
From Cloud Naive to Cloud Native – Avoiding Mistakes Everyone Does - Max Körbächer, Liquid Reply
“Cloud native” is nowadays a very brought word, used for everything from projects going to the cloud, open source solutions or in architecture terminology. This misleads initiatives and corporate decisions on cloud-first projects as well as their promised savings, improvements or speed gain. In this talk, we will have a look at common mistakes, how corporations place them elf into a twister and why you first need to really understand Netflix, Spotify and co, so that you can understand that you are very much different. Because migrating to the cloud, doesn’t make you native. Feel the passive-aggressive vibes? Good, now we can talk! Let us seriously discuss about architectural patterns, what really matters in your cloud provider, leading decision processes on a technical level and finally what are the steps to become cloud native and not cloud naive.
A
All
right,
good
morning,
everyone
welcome
to
my
talk
from
cloud
native
to
cloud
native.
My
name
is
max
kerbacher
and
I'm
co-founder
of
a
company
called
liquid
reply,
we're
based
in
germany
and
actually
help
our
customers
to
implement
kubernetes
platforms
actually
everywhere.
So
we
have
edge
use
cases
running
in
distributed
environments,
going
all
the
way
up
to
cloud
providers
and
even
scale
them
throughout
the
globe
so
running
on
multiple
continents,
in
multiple
different
regions
and
so
on.
A
So
in
my
daily
work,
I
most
of
the
time
are
more
giving
some
consultancy
and
advisory
and
try
to
answer
questions
from
the
customer.
What
is
the
right
way
to
do
my
kubernetes?
How
I
need
to
configure
it
correctly,
how
I
bring
my
teams
to
kubernetes
and
how
I
make
them
actually
use
of
it
and
so
on,
and
I
need
to
give
you
a
little
warning
for
today,
because
it's
like
not
like
there's
one
technical
problem
and
there's
a
technical
solution
for
it
or
we're
talking
about
processes.
A
A
So
the
thing
is
nowadays
it's
super
easy
to
go
to
a
cloud.
You
just
need
a
credit
card,
it
doesn't
matter
if
you're
an
enterprise,
a
small
company,
a
person
startup,
the
entry
boundary
is
very
low
and
it
is
also
fairly
easy
to
use.
You
can
just
click
your
things
somehow,
together
or
if
you
get
more
tacky,
you
can
build
your
pipelines.
A
A
A
Maybe
some
engineers
between
you
will
say
like
hey,
but
what
is
with
the
infrastructure-
and
we
come
to
that
later,
but
the
foundation
for
a
cloud
native
transformation
for
a
cloud
native
journey
doesn't
lie
in
the
first
step
in
the
technology
itself.
It
is
all
about
how
you
are
thinking
about
it,
and
what
do
you
want
to
achieve
with
it
and
how
much
you
are
interested
in
it,
because
the
cloud
native
space
is
moving
so
fast
if
you're
not
interested
in
it.
What
you
will
learn
today
is
outdated
tomorrow.
A
This
is
something
where
you
need
to
stay
with
your
mind
and
be
ready
to
to
keep
along
with
and
then
another
part
is
the
internal
developer
platform.
This
is
what
we
often
put
together.
It's
most
of
the
time
based
on
kubernetes.
It
allows
us
a
lot
of
automation,
but
it
is
more
about
the
extensions
which
are
implemented
around
which
helps
the
development
team
from
the
pure
software
development
perspective,
to
speed
up
and
show
integrity
of
the
system
and
show
the
security
that
everything
is
fine.
All
the
way
into
the
production.
A
A
Not
every
business
requirement
is
a
reason
for
developing
a
software
which
is
cloud
native
and
sometimes
it
would
be
even
more
expensive
to
go
this
way,
but
it's
often
a
good
option
and
you
should
be
aware
of
evaluated
and
take
a
look
for
some
points
where
you
was
like.
Well,
maybe
we
can
support
hereable
business
with
building
something
based
on
microservices,
which
is
fast,
which
can
be
stateless
and
so
on
and
so
forth
and
last
we
have
the
infrastructure
and
the
infrastructure
is
very
interesting
because
from
a
customer
perspective
the
pyramid
looks
like
this.
A
The
infrastructure
is
a
big
enemy
in
the
end,
it's
something
where
all
the
complexity
lays
and
all
the
costs
are
somehow
hidden
and
it's
maybe
scales
up
and
down
and
do
weird
things,
and
then
you
have
hundreds
of
regions
and
hundreds
of
services
and
so
on
and
so
forth,
but
that's
not
the
biggest
problem.
Nowadays,
you
can
define
and
describe
everything
human
readable
and
you
can
automate
everything
of
it.
A
Yes,
we
need
to
learn
about
it,
but
well.
We
also
learned
how
to
walk.
We
learned
how
to
speak.
We
learn
how
to
cook
so
as
an
engineer
as
a
technician
you
for
sure
are
very
fast
able
to
catch
up.
What's
going
on
in
cloud
provider,
what
you're
able
to
do
with
it
our
perspective
of
the
story,
consulting
major
enterprises
is
it's
all
about
the
mindset,
it's
all
about
how
the
teams
and
the
people
think
about
to
implement
cloud
native
and
how
really
to
yeah
succeed
in
their
journey.
A
A
A
It
is
something
which
helps
to
build
your
own
platform
or,
if
you
want
to
add
one
another
platform,
you
can
say
it's
a
platform
to
build
cross-platform
platforms.
What
it
means
like
you
can
build
with
one
solution,
something
which
runs
the
same
way
on
your
virtualized
infrastructure,
on
your
bare
metal
and
in
the
cloud
provider
giving
your
developers
in
the
end
the
same
experience.
A
It
helps
you
to
manage
your
resource
and
extensions
of
the
resources
which
you
can
use
it's
enriched
in
which
this
actually
and
it
runs
your
application,
but
do
not
misunderstand
running
here
as
like
a
hypervisor
I
get
running
just
means
it
takes
care
about
all
the
complexity
around
about
security,
about
networking,
about
authorization,
all
those
heavy
liftings
where
you
normally
have
already
a
year-long
project
for
it.
If
you
want
to
set
it
up
in
a
classical
infrastructure.
A
And
what
you
also
see
kubernetes
is
often
treated
as
a
one-time
implementation,
and
this
is
no
joke.
We
have
seriously
some
customers
where
we've
re-implemented
same
kind
of
platform
in
different
shapes
on
different
cloud
providers,
but
where
you
really
should
take
a
look
on
and
where
you
should
think
about
it.
A
A
A
When
you
take
a
look
on
the
cloud
native
survey,
it's
quite
interesting
because,
for
example,
in
europe
it
says
like
something
between
17
80
of
the
companies
and
major
enterprises
using
containers
and
kubernetes,
but
the
other
way
around.
When
you
take
a
look
in
the
cloud
native
developer
report,
there's
only
27
of
the
people
who
are
answered
telling
that
they
use
actually
kubernetes
in
their
everyday
life,
and
there
is
a
very
big
gap
in
between
for
sure.
A
A
A
A
So
you
need
to
be
very
precise.
You
need
to
find
the
people
in
your
corporate
who
are
already
interested,
who
have
this
drive
this
motivation,
this
interest-
it's
maybe
the
young
guys
and
girls
which
are
here
today
which
are
convincing
their
bosses,
their
leaders
to
say,
like
I
need
to
go
to
this
conference.
I
need
to
understand
what
they
are
doing.
I
need
to
talk
with
the
people,
and
these
are
the
people
you
need
to
find
within
your
companies,
bring
them
together
and
give
them
a
new
playground.
A
A
So
start
by
zero
is
a
very
important
factor,
and
I
know
companies
do
not
like
to
hear
it,
but
the
truth
is,
if
you're,
an
expert
in
chemistry,
the
chance
that
you
will
be
a
digital
expert
in
chemistry
is
quite
unrealistic,
because
this
is
not
your
expertise,
your
expertise
is
somewhere
else.
It
works
in
the
past.
It
will
work
in
the
future.
What
you
can
do
with
digital
services
is
to
enrich
your
capabilities.
A
You
can
make
your
product
better,
faster,
more
transparent,
but
it's
not
100
cloud
native
and
that's
why
it
also
sometimes
doesn't
make
sense
to
compare
a
major
engineering
company
with
something
like
a
netflix
or
spotify,
because
they
have
a
totally
different
past.
The
one
is
cloud
born.
They
started
with
this
with
digital
services.
A
Strategic-Wise
customers
also
often
choose
cloud
provider
by
money
and
from
an
economical
perspective.
I
can
fully
understand
if
I
can
save
30
million
on
the
one
to
comparable
to
the
other
one
where
I'm
currently
running
it's
maybe
very
attractive,
but
often
it
doesn't
make
sense,
for
example,
to
migrate
from
the
one
cloud
provider
to
the
other
cloud
provider,
for
which
reason
you
want
to
save
30
million
euro,
but
you
need
five
years
to
migrate.
All
of
your
workload
which
you
have
before
build
up
already.
A
If
you
want
to
implement
something
and
the
cloud
provider
doesn't
provide
it
to
you,
you
have
to
wait,
or
you
have
to
wait
to
build
it
by
your
own,
and
we
see
this
quite
often
as
one
of
the
reasons
like
okay,
we
are
going
there
and
there
it
seems
like
it's
a
cheap
but
good
resource
for
us.
They
can
do
on
the
paper.
What
the
all
club
other
club
providers
also
can
do.
A
A
A
So
when
we're
moving
a
little
bit
more
to
the
perspective
of
developers
like
the
people
who
needs
to
build
something,
what
we
experience
is
that,
quite
often,
suddenly
nothing
works.
The
cicd
fails.
The
git
repository
is
not
available.
We
cannot
push
something,
we
cannot
document
something,
and
this
is
because
resources
are
often
saved
on
the
development
side.
A
A
So
the
infrastructure
which
we
use
for
implementing
is
getting
very,
very
critical
and
it
needs
to
be
treated
like
this.
It's
the
same
like
I
do
not
want
to
say
your
major
application,
which
brings
you
all
the
money,
but
it's
very
much
comparable
to
it,
because
if
all
the
development
tools
fails,
it's
getting
very
difficult
to
fix,
something
which
is
maybe
running
in
production.
A
A
This
is
how
most
of
the
projects
are
working,
and
this
is
normally
fine
if
you
build
something
which
afterwards
is
not
going
to
be
changed
so
much,
but
this
doesn't
work
with
your
internal
developer
platforms,
for
example,
based
on
open
source
or
kubernetes,
because
we
have
major
releases
every
three
months
and
if
you
have
just
a
default
stack
on
kubernetes
running,
you
actually
needs
to
do
every
day.
For
example,
an
upgrade
sure
you
can
model
it
and
do
it
maybe
once
a
week
or
every
few
weeks.
But
in
the
end
it's
a
few
hundred
updates.
A
You
maybe
have
discovered
this
week
a
lot
of
new
technologies,
a
lot
of
new
projects,
a
lot
of
new
products
which
you
want
to
use,
which
you
want
to
integrate.
Who
should
do
it?
If
you
just
give
your
existing
cluster
to
an
operations
team
who
is
busy
and
most
of
the
time
do
not
have
enough
people
to
keep
your
cluster
alive?
And
then
you
come
like
look.
Here's
a
cool
product.
A
This
will
not
work
because
internal
developer
platforms,
when
they
build
right,
are
the
foundation
where
all
of
your
future
projects
are
running
on,
and
then
this
is
something
where
you
continuously
have
to
work
on,
where
you
continuously
have
to
adopt
it.
Implement
new
features,
extend
it
and
it's
getting
very
critical
for
you.
A
So
you
need
to
treat
it
like
a
lifelong
living
product,
it's
nothing
which
you
just
build
and
put
into
the
corner
and
give
it
from
time
to
time
some
water,
it's
not
a
cactus
or
something
like
that,
which
just
well
needs
a
little
bit
water
and
love
from
time
to
time,
and
last
but
not
least,
and
again,
please
don't
read
all
of
these.
It's
just
to
show
you
that
there's
a
lot
of
patterns,
for
example
in
the
cloud
native
environment.
A
These
patterns
must
be
understood
and
you
need
to
train
your
developers,
but
you
need
to
train
also
your
platform
engineering
teams
to
know
exactly
when
to
use
which
pattern
and
these
patterns
are
often
old,
but
gold.
They
once
got
asked
from
from
a
engineer
like
you.
Come
this
pattern.
How
old
are
you?
A
A
A
It's
just
don't
happen,
but
if
the
expectation
is
that
it's
somehow
between
a
full
week
of
deployments
and
fixing
some
stuff
and
maybe
get
an
error
done
in
the
production
stage
to
find
then,
for
example,
time
like
today
on
a
cube
cone
or
this
whole
week
on
a
kubecon
is
not
possible.
If
you
don't
actively
push
it.
If
you
do
not
make
the
room
available
for
your
teams
to
take
this
time
to
understand
and
to
learn.
A
We
just
a
few
weeks
ago
finished
a
project
where
we
had
to
re-implement
all
the
security
mechanisms
and
it's
a
hell
load
of
a
work
and
it's
nearly
impossible
because
your
output
is
like
well.
If
I
activate
now
this
around
120
micro
servers
are
just
going
to
die
within
one
second,
and
it's
such
a
amount
of
work
to
fix
this.
A
But
if
you
have
already
the
right
processes
around
it
for
arbuck
and
security
and
for
network
policies
in
the
beginning
of
your
implementations,
you
will
have,
in
the
long
run,
never
ever
a
problem,
because
people
understand
how
it
works,
and
the
fun
thing
is
that
security
with
kubernetes
is
super
easy.
It's
not
like
in
the
past.
You
need
to
start
fiddling
around,
make
some
profiles
and
harden
somewhere.
Your
server
for
sure
platform
team
needs
to
harden
the
server,
but
from
a
development
perspective.
A
You
don't
have
to
do
this
and
if
you
mess
it
up,
then
in
the
long
run
you
will
get
some
pains
with
it
before
you
go
into
production.
This
is
what
we
often
see
development
phase.
All
good
testing
phase,
also
everything
fine
and
then
it
hits
production,
nothing
works
and
not
because
it's
production,
but
because
suddenly
you
have
security
and
network
and
role-based
access
control
which
prevents
that
your
services
execute,
like
you
have
done
it
before.
A
The
fun
thing
is:
if
you
have
this
implemented,
it
is
the
only
thing
which
guarantees
that
kubernetes
will
fight
you
so
hard
to
shut
down
any
kind
of
services.
So
it's
super
important.
If
you
want
to
build
a
software
which
is
reliable
and
highly
available,
and
in
the
past
you
also
call
it
self-healing,
but
if
you
do
not
have
it
in
place,
cubones
will
just
raise
their
hand
and
say
goodbye
to
your
service.
A
And
finally,
we
come
to
the
master
discipline,
multi-cluster
single
cluster,
one
cluster
for
everything.
One
cluster
per
application
actually
does
not
matter
so
much
which
way
you
go.
You
should
not
choose
one
of
the
extreme,
not
one
cluster
for
everything,
but
also
not
one
cluster
per
application,
but
everything
in
the
middle
is
somewhere
right.
You
can
cluster
your
applications
based
on,
for
example,
departments
everything.
What
does
sales
everything?
What
is
for
your
production
line,
for
example,
or
for
criticality?
A
Maybe
it's
not
the
best
thing
to
put
everything.
What
is
highly
critical
on
the
same
cluster?
So
this?
Maybe
you
should
split,
but
for
everything
else
you
can
layer
it
a
little
bit
up
and
as
long
as
you
have
a
good
automation
in
place-
and
you
take
care
about
that
everything
runs
smoothly.
The
approach
is
absolutely
unimportant.
A
A
good
thumb
rule
for
it
is
the
less
scripts
you
have
implemented
in
your
cicd
pipelines,
the
better.
It
is
because
every
script
is
a
single
point
of
failure.
Every
script
is
basically
calling
that
you
maybe
do
not
handle
any
exceptions
and
that
your
whole
pipeline
will
break
in
the
state
which
you
do
not
want
to
have
stored
somewhere.
A
We
have
seen
companies
which
built
their
whole
own
operators
to
do
something.
While
there
was
another
operator
available,
if
you're
unhappy
with
one
of
these
solutions,
you
can
go
and
contribute.
For
example,
it
is
way
more
easier
and
companies
in
this
point
are
often
a
little
bit.
Yeah
worry
about
their
intellectual
property.
A
Keep
the
thing
simple.
I
said
the
over
engineering
is
sometimes
killing
projects
from
the
inside
because
you
increase
the
dependencies
and
nothing
works
anymore
and
everything's
lost.
You
want
to
bring
in
new
people,
but
they
need
months
to
get
onboarded.
They
need
months
to
understand
what
you
have
built,
and
then
you
hinder
yourself
to
move
forward.