►
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.
Panel: End User Community Adoption of Cloud Native Principles & Lessons Learned - Ken Owens, Mastercard; Lee Mills, Spotify; Jennifer Strejevitch, Condé Nast; Kasper Nissen, Lunar; & Cheryl Hung, Cloud Native Computing Foundation
This panel brings together engineers from the CNCF End User Community to provide their insights on the journey their respective companies have undergone in their transformation to Cloud Native. Each End User member company will discuss their Cloud Native principles and what has worked along with what has not worked. Topics will include operational best practices, developer experience, CNCF projects evaluated and implemented, and vendor management along with the lessons learned along the journey.
https://sched.co/ZeqU
A
D
A
Awesome
so
jennifer
casper
ken
and
lee.
Thank
you
so
much
for
joining.
So
I'm
going
to
start
with
some
questions
and
we'll
just
have
a
chat,
we'll
just
discuss
what
your
thoughts
are.
So,
let's
start
with
which
cloud
native
principles
that
you
adopted
were
the
most
beneficial
and
which
ones
caused
the
most
concerns
for
your
organization
and
lee.
Do
you
want
to
kick
us
off.
E
Sure
so
I
guess
the
the
the
most
important
one
going
back.
A
few
years
ago,
I
was
working
at
a
company
called
frog
and
we
were
basically
migrating
from
on
prem
service
service
to
a
cloud
native
design
and
the
the
most
important
thing
I
think
for
us
was
designing
upfront
with
automation
in
mind,
so
that
allowed
us
to
to
like
improve
our
monitoring.
E
I
think
that
there
was
a
level
of
trust
that
we
had
to
gain
in
doing
that
migration.
So
people
were
used
to
kind
of
big
long
deployment
processes
allowing
us
to
do
like
lots
of
manual
testing
that
side
of
stuff.
So
there
was.
That
was
the
also
the
kind
of
the
concern.
If
you
will,
from
the
same
aspect.
C
Yeah,
I
can
definitely
relate
to
that.
So
back
when
I
joined
luna
in
2016,
we
were
called
dunaway
at
that
time.
We
had
a
concept
where
we
were
sort
of
starting
building
microservices
and
we
were
sort
of
forgetting
how
to
actually
do
the
infrastructure,
so
they
were
still
deploying
everything
as
one
big
yeah,
basically,
all
all
all
the
microservices
in
one
go,
so
we
got
none
of
the
benefits
and
all
the
complex
stuff.
D
Yeah
kind
of
a
scenario
there,
as
well
with
you,
know,
kind
of
looking
at
the
abstraction
of
these
services
and
how,
over
time,
the
simplification
of
of
those
abstractions
is
a
lot
of
us
really.
You
know
results
in
a
much
faster
and
more
agile
deployment
methodology,
and
I
think
some
of
the
concerns
that
you
know
we
ran
into
it.
Mastercard
had
a
lot
to
do
with
sort
of
up
leveling
our
skill
sets
and
helping
our
you
know.
D
Teams
were
not
really
thinking
in
abstract
ways
and
not
taking
advantage
of
the
microservices
concepts
you
know
like
you
were
talking
about
casper
as
well,
and
so
we
sort
of
had
to
kind
of
help.
You
know
train
up
the
different
teams
both
on
the
infrastructure
side,
but
also
on
the
development
side,
to
really
understand
how
to
do
this.
D
E
Think
just
a
short
question
for
for
casper
in
in
that
shift,
from
kind
of
people
being
used
to
deploying
like
big
monolithic
products.
If
you
will
and
switching
to
micro
services
did
you
have
to
do
any
kind
of
like
did
you
have
to
do
anything
special
to
to
help
build
up
the
trust
between
all
of
the
different
squads
that,
like
you,
know,
service
a
is
fine
to
deploy.
I
don't
know,
what's
any
kind
of
thing,
it's
that
other
team
over
there
or
was
it
fairly
straightforward
shift.
C
It
was
actually
fairly
straightforward.
We,
however,
counted
a
lot
of
concerns
when
sort
of
moving
a
lot
of
sort
of
the
shifting
left
in
the
sense
of
having
our
developers
do
a
lot
of
more
infrastructure.
So
we
basically
went
the
completely
sort
of
the
opposite
way
of
having
you
know
back
then
we
had
before
we
had
this
big
mono,
just
one
repo
everything
was
in
there
and
they
started
to
split
everything
up
and
now
we
sort
of
got
in
the
direction
of
now.
C
We
need
to
everything
needs
to
be
sort
of
centralized
in
their
own
repository.
All
each
service
needs
to
own
everything,
kubernetes
manifest
all
of
the
stuff,
which
was
a
big
concern
for
our
developers,
because
they
really
didn't
want
to
learn
all
of
all
of
these
things,
and
so
we
struggled
a
lot
finding
sort
of
the
right
abstraction,
as
ken
also
mentioned
that
it's
it
yeah.
B
B
They
can
change
the
versions
of
their
packages,
but
then
they
get
the
responsibility
to
secure
their
containers
in
our
case
and
security
scanning
things
like
that,
so
they
have
to
worry
about
those
things
that
they
didn't
worry
before.
So
that's
definitely
a
concern,
but
among
the
benefits
in
conde,
nast
case,
for
example.
Now
we
are
migrating
various
clusters
across
two
different
companies
that
are
emerging,
so
it's
massively
beneficial
to
have
infrastructure
as
code
and
running
on
containers
with
kubernetes.
A
B
Yes
well,
in
our
case,
one
example
that
I
can
refer
to
is
centralized
logging.
It
is
a
big
challenge
to
replicate
or
centralize
in
a
global
sense.
Your
logs,
and
that
is,
was
definitely
a
trade-off
that
we
had
to
do.
We
did
choose
to
remain
within
a
region
level,
and
the
reason
for
that
preference
is
that
our
localized,
our
websites,
are
more
localized
than
the
troubleshooting
and
in
the
majority
of
the
times,
is
done
within
a
region
level.
E
E
Across
regions
and
one
of
the
things
that
hit
us
was
basically
restrictions
or
licensing
around
certain
data
that
we
could
that
we
could
share
and
that's
everything
from
like
media
information,
if
you
will,
through
to
things
like
gdpr,
impacted
us
in
a
similar
way
and
and
prior
to
this
shift
out
kind
of
regionally
there
was,
it
was
easier
and
more
observable
to
kind
of
scan
across
all
of
those
all
of
our
data
sets.
But
then,
as
we
we
started
to
to
go
into
more
regions.
E
B
E
Yeah,
so
it's
basically
we
we
some
of
them
made
metadata.
We
have
elevated
up
and
created
a
centralized
tool
that,
basically,
you
could
go
to
one
place
and
then
basically
select
the
region
or
area
that
you
were
looking
into
and
then
that
would
then
go
and
pull
data
from
a
different
source
and
escalating
to
that
one
sort.
But
again
it
was
kind
of
similar
to
what
I
do
now
at
spotify.
It
was
kind
of
productivity
engineering.
If
you
will
so
it
was
providing
those
internal
tools
to
help
help
the
stakeholders
through
that.
A
C
Yeah,
just
for
our
case
at
luna,
we
we
are
very
focused
in
in
the
nordics,
so
we
are
not
running
multi-region
in
that
sense.
We
do,
however,
do
backups
and
stuff
to
other
regions,
but
but
that's
primarily
that
so
we
are
not
sort
of
sending
data
across
regions,
so
I
I
have
a
don't,
have
anything
sort
of
to
add
to
that.
D
Ken
yeah
so
and
you
know
at
mexico,
we
have
a
lot
of
multi-region
deployments
and
I
think
our
biggest
tradeoff
was
trying
to
manage
the
upgrade
process
across
the
multiple
different
regions
and
then
sort
of
the
the
rolling
updates
that
we
were
trying
to
accomplish
and
ensuring
that
all
of
the
different
dependent.
You
know,
micro
service
components,
were
able
to
support
the
rolling
upgrade
type
of
model,
and
that
was
that
was
a
challenge
in
and
of
itself
that
you
all
experienced.
A
C
Yeah
sure
so,
coming
back
to
what
I
was
talking
about
earlier
about.
So
when
you
go
micro
services,
don't
don't
forget
about
the
infrastructure
that
you
need
to
support
all
of
these
micro
services
and
think
that
in
from
the
beginning,
I
think
that
was
was
one
of
the
the
big
things
that
I
learned
at
lunar
when
I
joined
is
that
we
really
need
to
think
about
the
infrastructure
and
just
just
don't
go
hey
microservices.
C
C
Just
had
a
you
know,
just
a
lot
of
coordination
between
teams
needing
to
ensure
that
all
the
different
versions
of
these
microservices
were
sort
of
aligned
and
could
run
together
and,
and
then
just
you
know,
the
the
big
it
took
around
45
50
minutes
to
to
bake
a
new
sort
of
version
of
our
infrastructure,
and
that
was
just
a
pain.
So
I
really
like
that
quote.
C
If
it
hurts
do
it
often-
and
that
was
one
of
the
the
reasons
why
we
sort
of
ripped
that
thing
apart
and
adopted,
kubernetes
and-
and
that
was
primarily
the
main
reason
why
we
adopted
the
kubernetes
as
a
platform,
was
to
to
sort
of
find
a
way
for
us
to
to
get
independent,
deploy,
deployable
services.
Basically,.
B
B
B
There
was
an
issue
with
the
deployment,
but
we
couldn't
see
that
on
staging
because
of
these,
some
bits
were
not
cleaned
up
in
in
some
environments,
and
the
lesson
learned
here
is
that,
even
though
it
may
take
longer
comparatively
to
for
a
cleanup
task
to
be
done
via
doing
a
pull
request,
a
review
and
then
you
put
all
through
the
pipeline,
which
is
the
way
that
we
have
set
up
by
sticking
to
the
version
declarative
changes.
We
are
avoiding
this,
these
human
errors
that
are
normal.
B
E
Yes,
I
guess
the
the
the
thinking
back
to
the
question.
I
guess
the
the
one
that
springs
up
for
me
was.
I
I
once
managed
to
take
out
most
of
our
instances.
We
were
so
the
example
that
I
mentioned
up
at
the
top
around.
We
were
going
through
this
transition
from
kind
of
on-premise
to
to
cloud
native,
and
we
deployed
a
new
region.
E
We've
gone,
you
know
all
in
each
containerized
and
all
of
this
cool
stuff-
and
I
was
migrating
some
code
from
from
our
old
system
and
the
thing
that
springs
to
mind
is
is
managing
state
and
our
old
system.
There
was
parts
of
it
that
was
super
tied
to,
for
example,
the
box.
It
was
running
on
how
many
threads
were
available
and
all
of
this
stuff
and
moving
that
into
kind
of
the
cloud
native
setup
that
we've
got.
E
D
F
D
A
lot
of
the
the
different
you
know,
excitement
that
developers
have
and
some
of
the
processes
that
that
jennifer
mentioned
that,
were
you
know
in
the
culture
that
needed
to
kind
of
change.
Was
it
that
once
it
was
adopted,
some
of
the
old
habits
kept
back
in
right
like
hard
coding
to
services
and
not
understand
version.
You
know
the
the
service
team
that
developed
a
new
service
and
in
this
example
I'm
thinking
about
they
didn't.
D
You
know
quite
understand
how
to
kind
of
make
sure
that
they're
doing
release
management
with
the
version
you
correct
right.
So
you
can.
You
can
take
down
another
team's
set
of
services
by
not
you
know
correctly
doing
you
know
versioning
of
your
service,
and
so
I
think
I
would
give
lessons
to
make
sure
that
you
improve
and
understand.
You
know
how
to
do
release
management
and
virtually
as
you
roll
out.
You
know
the
new
services,
because
that
otherwise.
C
Yeah,
so
we
we,
we
adopted
a
git
ups
a
year
and
a
half
ago,
or
something
like
that
and
in
the
process
of
we
so
just
to
give
some
context.
Lunar
is
sort
of
a
fintech
transitioning
into
a
bank
and
all
of
the
requirements
coming
with
that
really
sort
of
required
us
to
to
be
very
declarative
and
and
just
see
all
the
changes
coming
into
our
environments
and
having
sort
of
a
concept
as
skid
ups,
where
you
declare
all
your
stuff,
you
have
some
reconciles
running
in
your
environments.
A
E
E
The
ways
that
we've
worked
internally,
we're
also
kind
of
trying
to
bring,
in
obviously
things
like
new
trainings
we're
trying
to
incorporate
more
and
more
of
kind
of
open
source
into
kind
of
recognition
internally.
For
for
people,
you
know
and
include
that
when
we
start
to
to
talk
about
progression
and
and
next
steps
and
things
like
that
and
basically
celebrate
people
taking
part
in
it,
I'd
be
super
interested
to
hear
what
other
people
are
doing
too.
B
Shall
I
okay
well
to
be.
I
echo
everything
that
lee
said
as
well,
and
I
add
that
also
being
a
member
and
attending
the
meetings
and
dealing
with
the
decisions
for
new
projects
also
help
people
who
are
interested
in
advancing
their
technical
leadership
skills
and
exercise
their
ability
to
look
ahead.
It's
important
for
the
organization
to
have
someone
that
comes
and
proposes
new
things
and
is
always
listening
to
the
community
out
out
there
and
comes
with
fresh
ideas
and
encourages
us
also
to
push
them
forward
in
our
organizations.
B
C
Of
course,
we
can
cannot
open
sources,
some
some
of
the
banking
stuff
and
some
of
the
more
sort
of
local
stuff
we
have
running,
but
well
all
of
our
infrastructure,
tooling
and
and
whatever
we
do
sort
of
in
that
area.
For
our
platform.
That's
something
that
we
we
try
to
to
to
publish
and
talk
about
as
much
as
possible,
because
I
think
there's
a
lot
of
value
in
sharing
our
experiences
and
and
just
hearing
other
people
talk
about
how
they
are
doing
it.
D
Yeah,
that's
really,
I
think,
important.
You
know
at
mastercard.
We
we
really
tied
into
that
end
user
community
and
the
engagement.
We
have
with
other
end
users
to
really
help
shape
and
form
what
we
kind
of
call
our
training
pathways,
or
you
know,
development
and
learning
pathways
for
cloud
native,
and
you
know
for
for
how
to
develop
and
kind
of
modify
development
for
a
more
cloud
native
model.
D
We
also
have
used
the
cncf
landscapes
a
lot.
So
as
we
look
at
filling
gaps
in
our
technology
portfolios,
we
bring
in
the
landscape
and
talk
about
the
different
projects,
not
just
the
ones
that
are
in
the
you
know:
cncf
sandbox
and
incubating
efforts,
but
also
you
know
the
ones
that
are
just
listed
as
a
project
that
may
be
of
interest
to
us
to
engage
in
and
that
kind
of
had
this
interesting
side
effect
of
a
lot
of
our
developers
getting
excited
about
these
different.
D
D
Providing
you
know,
contributions
back
to
the
community,
which
then
has
led
to
you
know
to
more
open
source.
You
know
methodology
it's
being
enforced
and
coming
into
the
organization
which
has
been
awesome
to
see
the
other
thing
we
do.
Is
we
also
like
to
do
a
lot
of
recruiting
at
kubecon,
and
you
know
so
we
you
know
we're
always
looking
for
great
full-time
employers
and
employees
and
internships,
and
we
are
hiring.
So
let
me
know
if
you're
interested
in
looking
at
me.
Okay,.
B
D
B
A
C
Yeah
yeah
sure
so
back
when
we
we
sort
of
started
this.
We
had
a
lot
of
discussion
around
what
what
is
the
right
abstraction
for
our
developers?
How
do
they
develop
these
microservices
locally?
How
do
they
build
their
containers?
Do
they
need
to
run
the
environments
on
their
machines?
In
the
beginning,
we
tried
out
with
running
in
the
beginning
six
microservices
in
mini
cube,
and
that
was
fine
and
we
had
20
services.
C
C
So,
and
I
don't
think
we
really
found
the
good
solution
yet
we
we
try
to
sort
of
minimize
the
time
it
takes
to
deploy
to
one
of
our
development
environments.
So
it's
for
developers
to
to
get
their
changes
out
there.
It's
about
three
minutes
or
something
like
that.
But
we
have
focused
a
lot
in
on
writing
tests
and
and
having
our
developers
testing
a
lot
more
locally
and
right
as
much
as
possible
that
they
can
do
locally
and
then
they
can,
of
course
push
to
a
development
environment
to
test
it
fairly
quickly.
E
So
I
can
talk
a
little
bit
about
what
we're
doing
right
now
at
spotify,
so
we've
had
we,
we
kind
of
have
that
we
we've
kind
of
built,
alongside,
as
we've
been
adopting
more
and
more
like
cloud
native
frameworks
and
platforms,
and
things
like
that.
We've
actually
been
trying
to
build
a
platform
alongside
of
it,
focusing
on
on
two.
E
I
think
in
in
like
developer
engagement
and
and
if
you
will
happiness
their
day-to-day
and
that's
what
we're
now
working
to
to
open
source
and
and
try
and
support
the
rest
of
the
community.
Doing
the
same
type
of
thing,
and
I
think
the
the
the
thing
that
that
kind
of
lines
up
alongside
that
is
adopting
like
cncf
technologies
or
looking
at
the
landscape
there,
it
gives
developers
a
common
language
if
you
will
so
rather
than
working
on
specific
frameworks
or
or
projects
to
spotify.
E
You
know,
working
on
kubernetes
is
as
an
example,
is
something
that,
like
other
engineers
and
other
companies,
can
relate
to
and
there's
a
bigger,
wider
community
there
that
they
can
engage
with
so
kind
of
the
adoption
of
those
and
then
trying
to
supplement
that
alongside
and
seems
to
have
really
improved
and
helped
the
developer.
Experience
for
us.
B
But
of
course
we
had
to.
We
are
still
collaborating
together
and
it's
meant
for
us
to
all
work
together
and
similarly
to
lee
building
tooling.
That
will
help
people
across
the
board,
not
individually
supporting
teams.
So
it's
thinking
ahead
of
accelerating
for
everybody
and
yes,
now,
the
teams
are
more
mature
after
about
three
years
that
the
project
started
and
appreciative
of
being
able
to
have
more
flexibility
with
their
application.
B
So
it's
been
very
positive
and
now,
with
the
merger
that
I
mentioned,
there
is
another
interesting
challenge,
because
the
other
organization
had
a
different
way
to
deploy
systems.
They
had
a
more
self-service
click
button
system
that
did
much
more.
So
we
are
looking
now
at
the
benefits
of
having
more
flexibility
and
having
less
ownership,
but
wanting
to
merge
and
having
giving
this
option.
A
Awesome,
thank
you
and
I
think
we
can
finish
up
now,
but
I'd
just
like
to
give
everyone
a
chance
to
say
any
last
thoughts.
So
for
me
I
found
this
a
really
interesting
conversation
and
I'm
really
happy
to
see
more
companies
are
incentivizing
their
engineers
to
work
with
the
open
source
community
jennifer.
B
C
Yeah
yeah,
and
for
me
it's,
I
think,
yeah
sharer
experiences.
It's
it's
really
valuable,
just
hearing
the
good,
the
bad,
whatever
you
can
share
with
the
community.
It's
it's
really
a
great
experience
to
learn
from
each
other
and
just
get
some
feedback,
so
I
would
really
encourage
people
to
to
whatever
they
have
out
there
open
source
or
just
write
a
blog
post
or
whatever
just
share
it
with
the
community,
because
we
all
learn
from
it.
E
Yeah
and
just
to
echo,
what
everyone
else
has
been
saying
like
the
community
is,
is
really
really
special:
you'll
you'll,
you
can
give
a
lot
and
you
can
learn
a
lot
from
from
the
community.
So
keep
up
that
communication
and-
and
I
think
as
well
keep
up
the
communication
internally
within
your
own
company-
bring
bring
everybody
else
along.
A
A
Much
hi
everyone
and
thank
you
for
joining
the
q
a
session
so
just
to
let
you
know
we're
going
to
continue
this
in
slack
afterwards
in
two
dash
cubecon
dash
case
studies.
So
let
me
start
with
one
of
the
questions
we've
got
from
daniel
houston.
So
how
have
you
felt
your
team
structures
and
communications
have
changed
as
you've
gone
towards
cloud
native
casper?
Do
you
want
to
go
first.
F
A
E
I
think
communications
is
still
key,
but
the
type
of
kind
of
shifts
a
little
bit
more
kind
of
like
information
blast,
more
keepings
stakeholders
up
to
date
that
maybe
you've
got
dependencies
or
streams
that
are
based
off
your
your
services
and
systems.
So
you
can
be
a
little
more
targeted
with
those
comps.
D
B
Yeah,
well
we
ain't
towards
breaking
those
silos
and
sometimes
it's
it's
difficult.
People
see
it
as
I
still
another
team,
like
let's
say
the
cloud
platform,
infrastructure,
team
and
the
developers,
but
we
are
trying
to
make
like
into
one
community.
We
we
attend
the
same
meetings.
We
are
the
engineering
teams,
but
there
are
still
lots
of
challenges
to
make.
It
seem
like
a
single
practice
that
the
same
goal,
but
yes
like
it,
has
improved
a
lot.
We
are
supported
we
pair
with
them.
B
E
Sure
any
cultural
resistance
to
going
with
cloud
native,
I
think
I
think
maybe
it's
not
necessarily
specific
to
to
going
cloud
native,
but
I
think
the
biggest
thing
was
kind
of
just
change
and
risk
of
that
change
in
the
in
the
like
the
core
product.
That
was
that
was
out
there
so
kind
of
being
able
to
take
that
in
stages
and
take
it
in
in
smaller
steps
and
then
related
to
that.
F
A
B
I
guess
a
similar
thing:
it's
a
bit
scary
to
have
from
one
point.
You
are
just
focused
on
thinking
of
the
feature
you
have
to
deliver
and
then
you
are
suddenly
responsible.
If
you
can't,
if
you
come
from
what
you
you
need
to
monitor
your
application,
you
need
to
secure,
you
are
responsible
for
it
and
there
is
sometimes
an
assumption
that,
oh
you
will.
B
An
infrastructure
team
will
build
the
dashboards
they
will
and
then
you
are
like
well-
and
I
have
to
have
this
conversation
of
like
cooperation
as
in
and
sell
the
idea
that
it's
better,
that
they
have
the
whole
power
because
they
then
don't
depend
on
another
team
and
the
there
is,
and
it's
more
like
a
collaborative
thing.
Yeah.
These
are
challenges.
It's
like.
I
said
before
the
teams
are
more
mature
now
and
we
are
more
used
to
this
communication,
but
it's
still,
especially
with
merging
and
going
with
different
teams.
B
This
is
happening
and
you
will
keep
coming
across
that
with
new
teams
and
but
but
I
I
think
it's
for
better
now
and
I
think
they
appreciate
after
after
they,
they
get
to
learn
more
and
see
that
they
are
like
now
understand
much
more
and
for
their
careers
as
well,
like
the
knowledge
of
the
whole
life
cycle
and
supporting
monitoring.
Your
applications
is
really
good.