►
From YouTube: Panel Discussion: Avoiding the Weeds in the Cloud Native Landscape – Moderated by Priyanka Sharma
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Panel Discussion: Avoiding the Weeds in the Cloud Native Landscape – Moderated by Priyanka Sharma, GitLab
The CNCF is one of the seminal technology organizations of our time and has come to house a plethora of projects and technologies that are relevant to the ecosystem it has created. In this heyday of technical innovation, it can be hard for organizations to decide what tooling and workflows to use as they move to cloud native. There is the tension between best of breed point solutions and what you need across the organization. This panel brings together practitioners who have made infrastructure and tooling decisions for large-scale companies and businesses and offers their perspective. The questions we will cover are: * What are the main categories of tooling when someone moves cloud native? * How do you choose tools - best of breed or integrated solutions? * Share a horror story about a tool/solution your company chose. * Share a success story about a tool/solution your company chose.
To learn more: https://sched.co/GrSS
A
All
right,
hi
everybody
last
session
of
coop
cut
Seattle.
You
made
it
you're
here
appreciate
your
dedication.
Thank
you
for
coming,
excuse
my
voice.
Please
I
have
bit
under
the
weather
all
week,
and
this
is
the
best
because
I
slept
till
1:30
to
make
this
happen
just
FYI,
but
anyway,
I
am
the
least
important
voices
right
here
today.
I
have
amazing
panelists,
who
are
all
practitioners
in
large
companies
who
are
going
to
talk
about
their
experiences
with
us.
A
So
I'll
just
kick
us
off
really
quickly
with
a
brief
intro
to
our
topic
and
then
we'll
start
with
introductions
and
questions.
If
you
have
questions
I
highly
encourage
you
to
ask
them
in
the
last
10
minutes
of
the
session,
which
will
be
open
to
anybody
if
people
want
to
scoot
over
to
the
front,
that's
also
cool,
since
we
have
space
but
no
pressure.
This
is
a
this
is
a
decent
showing
for
the
last
I
should
have
really
happy
actually
all
right.
So,
let's
begin
so.
A
So
just
going
to
the
the
sponsor
floor,
you
see
so
many
different
vendors
and
every
year,
I
see
so
many
new
HUD
sort
of
like
a
hairline.
It's
like
you're,
constantly
learning
and
that's
great,
but
that
also
means
that
you
combine
all
these
various
tools.
All
the
new
problems
we
face
with
the
smaller
size
of
Teebs,
because
micro
services
enable
smaller
project
teams,
etc
and
people
choosing
their
own.
A
And
suddenly
you
have
tens,
if
not
20s
hundreds
of
tools
in
each
company,
so
I
started
thinking
about
this
problem,
but
we
had
get
lab,
which
is
wherever
see
this
often
in
large-scale
companies
that
at
some
point
there's
a
there's,
a
tipping
point
right
and
at
which
enterprises
have
to
start
thinking
through
an
organized
way
of
to
lay
across
the
company.
So
my
experience
I
see
it
every
day.
A
I,
wanna
and
so
I
brought
together
these
IDI
and
practitioners
to
tell
us
their
perspective,
and
so
we
can
all
learn
and
make
the
best
tooling
choices
for
all
of
our
companies.
So
that's
the
topic.
Now,
let's
get
started
as
I
mentioned,
I
work
at
github
of
the
director
of
cloud
native
alliances.
There
I
spend
a
lot
of
my
time
working
on
just
the
cloud
native
ecosystem.
I
support
a
lot
of
projects,
I'm
a
contributor
to
the
open
tracing
project
about
Twitter
on
pretty
agha.
A
A
E
A
Thank
you.
So,
let's
begin
panelists
I,
let's
make
sure
that
we're
all
yeah
to
to
per
Mike,
so
just
to
make
sure
all
our
definitions-
and
you
know,
company
stages-
are
allied
and
we
know
where
people
are
at
I'd
love
to
hear
from
each
of
you,
your
definition
of
cloud
native
and
you
vary.
Our
company
is
in
their
journey
towards
that
sure.
C
Yeah,
so
just
to
add
to
that
I'd
also
think
that
cloud
native
gets
us
back
to
the
developer.
Team
is
the
central
kind
of
front.
So
Ops
has
always
been
this.
You
know
redheaded
stepchild.
If
you
will
we're
always
bad.
We
always
hold
people
up
and
by
switching
to
this
it's
really
forced
us
to
look
at.
How
do
we
embrace
our
developer
community
and
help
them
actually
get
there
and
take
our
advice
to
them?
More
often,
so
that's
awesome.
Yeah.
E
A
A
B
People
want
to
try
every
one
of
them
want
to
buy
every
one
of
them
and
no
one
can
really
settle
on
what
is
the
best
of
anything
in
most
cases,
so
I
would
say
you
know
tooling,
plays
a
huge
part
of
it,
because
it
really
affects
everything
that
you're
doing
the
same
time
to
ins
a
means
it
means
to
an
end.
You
don't
see
Wall
Street
Journal
articles
about
the
great
tool
stack.
Some
companies
put
out
there.
It's
not
it's
not
relevant
to
anyone,
but
the
company
itself.
It
doesn't
generate
value
in
and
of
itself.
B
A
C
Also
agree,
I
mean
there's
a
tool
under
the
Sun
for
everything,
any
problem
that
you
can
imagine
one
of
the
challenges
that
I
think
that
we
have
is,
if
you
have
a
bad
piece
of
code
or
a
bad
application,
and
you
think
a
tool
is
gonna
fix
it.
You
are
so
wrong
because
that
bad
application
is
just
gonna,
be
bad
in
a
new
tool
on.
C
D
So
we're
fairly
new
in
our
cloud
native
journey,
so
we're
still
discovering
and
learning
new
things,
so
I
would
just
say
we
have
to
try.
If
you
don't
try
like
we're,
what
are
you
doing?
You
have
to
make
sure
you're
trying
new
things,
listen
to
the
people
that
are
actually
using
the
tools
and
that's
what
we're
trying
to
do
making
sure
that
those
mature
teams
that
are
out
there
in
our
I-team
Enterprise
we're
listening
to
them.
What
are
they
doing
today
so
that
way,
we
can,
you
know,
have
it
across
the
enterprise
use
it
at.
E
B
E
F
E
A
That
you
specifically
have
a
very
unique
journey
right,
so
I
I
know,
you've
seen
had
been
part
of
lift
figuring
out
its
infrastructure
and
abstracting
it
as
much
as
possible
and
you've
built
a
lot
of
that
at
Ardmore
has
now
taken
its
old
life,
and
it's
also
amazing
I
mean
how
many
people
here
read
to
onto
icon
or
one
of
the
Envoy
sessions,
look
flick.
They
yeah
exactly
yeah.
It's
awesome
right,
so
I'd
love
to
hear
a
little
bit
on
about
that
journey.
So
we
can
all
compare
notes.
A
E
F
E
You
know,
I
mean
all
the
all
the
common
things
and
I
think
that
you
know
I
mean
like
every
other
company,
we've
tried
to
take
an
iterative
approach
and
that's
really
what
I,
what
I
recommend
to
everyone
on
their
journey
is
to
really
think
about
what
problems
are
being
faced
and
try
to
do
them
incrementally,
like
there's,
no
Big
Bang
solution,
kubernetes
is
not
going
to
save
you
or,
like
some
tool,
is
not
gonna
save
you.
It's
like
to
me.
E
It's
about
incremental
problem-solving,
so
I
mean
I'll,
stop
there,
because
I
could
talk
forever
about
this,
but
I
think
that
lyft
has
gone
through
a
very
incremental
journey
of
like
one
database
too
many
and
solving
particular
problems
or
implementing
on
velay
to
solve
particular
problems
or
other
tools
and
I.
Think
that's!
That's
all
that
we
can.
A
Do
right
that
makes
a
lot
of
sense
and
so
for
for
everyone
here,
I
think
it's
like
solve
incremental
II,
don't
boil
the
ocean
and
there's
too
many
tools
out
there,
like
that's
pretty
we're
all
in
consensus.
So
how
are
you
head
like
that,
for
your
companies
like
right
now,
there's
31
projects
in
CNC
F
to
use
all
of
them?
How
do
you
figure?
How
do
you
decide
what
to
do
so.
C
For
us,
it's
honestly,
it's
well
I
mean
we
don't
boil
the
ocean,
so
it
was
one
problem
at
a
time
right,
I
mean
all
of
you
know
what
CVS
receipts
look
like.
So
you
know
to
try
to
tackle
that.
Fantastic
challenge
was
a
perfect
solution
right,
so
why
who
uses
it?
Who
doesn't
and
how
do
we
digitize
them?
So
that
was
one
place.
C
A
C
What
is
that
perfect
it
so
for
us
right
now
what
that
perfect
was
was,
actually
you
know
putting
it
on
your
smartphone,
but
on
the
behind
that
you
know
they
also
add
a
bunch
of
coupons
and
all
you
know
the
thing
that
makes
that
receipt,
I
think
I
got
sent
a
Curtin
replacement
or
Halloween
costume,
and
so
on,
Thursdays.
Actually,
when
they
would
release
new
coupons,
we
would
crash
servers.
So
we
had
this
massive
farm
of
servers
just
to
handle
one
day
and
a
handful
of
hours
of
traffic.
C
So
what
we,
what
going
to
the
container
solutions
had
allowed
us
to
do,
was
not
have
to
use
that
infrastructure
solely
just
for
them,
so
we
could
spread
out
the
capacity
and
then
get
them
their
capacity
for
one
day.
So
that's
the
problem
we
ended
up
going
after,
but
what
we
discovered
on
the
flip
side
is
how
easy
it
was
to
digitize
that
very
long
receipt.
A
B
B
Built
a
lot
together,
good
too
much
history
here,
yeah
I
mean,
but
for
us
I,
look
at
every
choice
of
tool
as
being
temporary.
There's
no
right
solution
to
a
problem,
there's
continually
evolving
solutions
to
problems
and,
like
Melissa
said,
if
you
have
a
problem,
that's
a
solution!
That's
not
meeting
your
needs
completely,
don't
be
afraid
to
cut
bait
and
run
to
something
else,
ideally
build
in
such
a
way
that
you're
not
tied
to
individual
tools.
You
know
be
more
flexible
with
your
interfaces.
B
B
So
understanding
you
know
what
you
can
try
after
a
year
to
maybe
Prometheus
1.0
didn't
work
that
well,
but
maybe
because
2.0,
you
know
a
lot
of
solution
sets
you
weren't
able
to
achieve
before
in
an
earlier
iteration,
so
I'm
continually
trying
these
things
out.
I
think,
most
importantly,
don't
try
to
reinvent
patterns
yourself.
Don't
try
to
reinvent
the
wheel.
Look
at
what
other
major
companies
are
doing
and
try
to
adapt
their
solutions,
because
there's
companies
out
there
that
probably
don't
need
to
build
their
own
TS
DB.
D
A
D
Is
is
it
applicable
to
our
environment
right
it
doesn't
fit
within
our
transformation
journey?
Is
it
going
to
help
us
get
where
we
want
to
go?
Then
e
is
for
enterprise
readiness
right:
can
it
be
used
at
the
enterprise
level
I?
Is
it
integrated
it?
Can
we
integrate
it
well
with
other
pieces
of
the
puzzle
that
we
have
and
then
o
overhead
right?
D
Is
it
going
to
cause
a
lot
of
overhead
for
our
developers
or
whoever's
going
to
own
the
tool
in
the
end,
and
then
you
as
you,
is
it
useful
and
that's
like
really
the
most
important
thing
right?
We
don't
want
to
just
buy
our
get
a
tool
or
use
a
tool
just
to
have
it.
We
want
to
make
sure
it
can
actually
be
used
in
the
right
way.
So
that's
really
what
I
go
off
of
that.
A
B
The
enterprise
readiness
is
huge
as
well.
You
see
a
lot
of
tools
that
seem
like
they
solve
a
lot
of
problems
and
you
dive
into
it.
You
realize
I
can't
even
make
this
thing
highly
available.
How
am
I
supposed
to
depend
on
it
to
operate
my
most
critical
infrastructure,
24/7
365,
and
actually
it
alerts
what
I
need
them
so
that
enterprise
readiness
for
me
is
one
of
the
first
ones
I
look
at
if
I
can't
Google
the
name
of
the
tool
and
highly
available
and
there's
no
answers
out
there.
A
A
C
Yeah,
so
I
won't
go
into
specifics
about
it,
but
we've
so
when
we
drew
when
I
joined
CBS,
they
were
just
entering
their
digital
journey
and
so
I
was
brought
in
to
do
platform-as-a-service
and
we
had
teams
that
were
itching
to
jump
on
board.
So
we
got
our
platforms
up
and
things
were
great.
We
actually
had
a
team
that
we
said,
look
we're
gonna,
let
you
lift
and
shift
they
came.
They
had
a
bunch
of
contractors,
they
said.
Oh
I
can
do
all
this
amazing
stuff.
C
They
get
on
the
platform
and
the
next
thing
I
know
they
are.
You
know
they're
asking
for
150
200
gigs
worth
of
space
on
their
to
run
their
application
in
a
micro
service,
and
so
we
had
to
go
back
and
sort
of
I.
Guess
Ries
cooled
them
a
little
bit
on
how
you
develop,
and
you
know
what
it
looks
like.
What
does
a
micro
surface?
Look
like?
What's
the
DEF?
How
does.
C
Frustrating
but
at
the
same
time
you
know
they're
they're,
an
extension
of
our
teams,
so
we
had
to
help
them.
They
had
also
been
doing
very
traditional
development,
so
it
was
I
guess
my
my
advice
would
be
to
make
sure
that
the
first
apps
that
you
onboard
can
quickly
adapt
to
changes,
can
quickly
adapt
to
faults
and
failures
and
and
be
willing
to
accept
your
feedback
to
them
to
help
them
change.
I.
C
Think
that
you
know
they
thought
these
crazy
people
were
coming
in
and
telling
him
they
were
over
at
their
job
and
that
wasn't
in
at
all,
but
that's
certainly
probably
how
it
came
across,
because
it
was
an
important
call
that
they
meet.
They
moved
in
there
and
and
broke
it,
but
at
least
we
were
able
to
fix
it
pretty
quickly.
So.
D
So
I
wasn't
gonna
share,
but
so
my
role
on
the
team
is
primarily
owning
the
development
tool,
so
the
tools
that
our
developers
use
every
day
like
it
lab
Nexus
Jenkins
and
whatever
else
we
decided
to
bring
on
board
so
previous
to
all
these
modern
tools
that
I
just
mentioned,
we
had
you
know
a
homegrown
tool
because
I
say
if
you
there's
nothing
out
there,
that
fits
your
need.
What
do
you
do
you
build
it
yourself
right?
So
the
thing
about
that?
D
You
have
kleenex
right
in
case
I
said
it
here:
okay,
but
yeah,
so
it
just
made
it
difficult
for
my
team
to
kind
of
you
know
bring
about
that
DevOps
mindset
when
you
have
this
one
monolith
tool
that
does
everything
you
can't
move
very
quickly,
because
no
one
out
there
really
knows
how
to
use
it.
So
you
can't
really
deploy
fast.
You
can't
really
build
fast.
D
It
was
just
really
really
sad,
but
we
have
moved
on
to
more
modern
tools
like
git
lab,
and
you
know
Nexus
and
things
like
that
that
have
really
made
our
developers
lives
easier
and
it's
not
so
hard
to
bring
people
on
new
developers.
How
hard
is
it
to
find
a
developer?
That
knows
a
homegrown
tool
right,
so
yeah
so
kind
of
a
sad
story,
but
that.
E
I,
don't
I
don't
have
any
particular
horror
story,
at
least
not
one
that
I'm
willing
to
share
being
recorded,
but
yeah.
You
know
I,
think
I,
think
my
advice
is
more
how
to
avoid
horror
stories
which
is
to
you
know,
like
always,
have
a
plan
to
do
an
evaluation
of
a
technology
which
was
which
are
set
before
so
you
know.
Is
it?
Does
it
take
various
boxes
about
like
high
availability
and
a
bunch
of
other
stuff?
Does
it
have
a
good
documentation
and
other
people
supporting
it?
E
And
then
you
know
always
figure
out
a
way
to
do
a
staged,
rollout
and
always
be
able
to
roll
back,
and
that
sounds
really
obvious,
but
you
know
you'd
be
surprised
at
how
often
that
doesn't
happen.
So
I
think
you
know
as
long
as
you
you
know
you
can
test
out
some
things
relatively
quickly
and
you
know
get
one's
feet
wet
and
then
be
able
to
roll
back
and
abort
I.
Think
that's
the
most
important
thing.
B
Thank
you.
This
is
not
necessarily
a
failure
of
a
tool,
but
almost
a
overwhelming
success
of
a
tool.
There's
a
quote:
I've
cut
my
signature
for
about
you
know
six
years
or
so
it's
the
tense
tendency
if
a
hammer
to
treat
every
problem
like
it's
a
nail,
and
so
sometimes
you
have
tools
that
just
because
it
can
do
something
doesn't
mean
it
should
one
of
the
guys
in
the
audience.
B
Here
has
a
guy
who
built
this
with
me,
but
VMware
vCloud
director
was
a
fairly
simple
solution
for
delivering
Aya's
to
enterprise
and
at
the
time
it
took
people
about
30
days
to
get
a
VM
at
t-mobile
with
VMware
vCloud
director,
which
we
branded
as
T
cloud.
How
clever
of
us
it
would
take
them
three
or
four
minutes,
so
they
get
these
VMs
very
quickly.
We
made
sure
they
understood,
there's
no
backups,
there's
no
patching.
These
are
strictly
for
a
low
govern
step
test,
like
don't
do
anything
where's
that
going
production
on
here.
B
So
we
turned
this
on
and
saw
what
happened
with
it
and
within
a
few
months
or
so
we
had
you
know
VPS
calling
us,
because
their
production
servers
were
down
that
were
all
running
on
this
declawed
system.
We
had
a
whole
development
team
over
in
India.
That
was
saying.
Our
development
boxes
are
fast
enough.
Can
you
please
increase
the
resources
because
they
were
running
these
boxes
like
desktops
inside
this
T
cloud
environment?
So
if
you
put
something
out
there,
people
will
find
ways
to
use
it
that
you
never
thought
possible.
B
A
Guardrails
yeah
we
had
a
prep
call
and
Melissa
was
like
I
hate.
The
word
Governance.
That's
that's
fair.
It's
covered
ed
scarless,
similar
concepts
so
actually
I'd
like
to
hear
from
whoever
in
the
panel
wants
to
go.
First
governance
versus
guardrails.
What
do
you
pick
and
it
could
just
be
a
philosophical
choice
and
you
might
end
up
actually
be
doing
the
same
thing
as
the
next
company,
but
I
want
to
hear
which
do
you
lead
towards
and
then
how
your
company
thinks
about
that.
So
do
you
wanna,
go
desert.
D
So
we
have
a
lot
of
mission-critical
applications
that
you
know
we
have
to
really
kind
of.
You
know,
really
govern
and
make
sure
that
everyone
is
kind
of
doing
the
same
thing
in
the
same
way
just
to
make
it
easier,
for
you
know
us
to
fix
issues
if
they
happen
on
the
development
tool
side
we
are
like
when
it
comes
to
developer
tools
and
how
they
develop.
We
more
so
take
a
standpoint
of
guardrails.
We
give
developers
options
because
we
want
to
preserve
that
creativity,
like
you,
said
Melissa.
D
A
C
I'll,
just
so,
it
is
the
the
governance
for
me
and
in
large
companies
that
I've
worked
for
governance
has
always
turned
into
silos,
and
these
roadblocks
and
this
massive
thing
that
you
just
have
to
overcome.
So
if
you
tell
you
know,
look
here's
here's
what
you
can
stay
in
just
if
you're
in
these
you
know
five
blocks
or
whatever
good
go.
If
a
person
has
to
touch
a
button
along
the
way
automate
it
and
just
stop
making
it,
you
know,
be
governance
I.
C
E
E
Stack,
whether
that
be
some
set
of
database
doesn't
mean
that's
to
be
one,
but
you
know
some
set
of
databases
or
caches
or
networking
or
compute
or
functions,
and
you
know
I
think
the
reason
for
that
is
just
mainly
around
operations
cognitive
load
like
trying
to
make
it
so
that
you
know
you
can
have
common
documentation
and
stuff
like
that.
So
at
lift
we've
actually
done
a
pretty
decent
job,
trying
to
pick
a
set
of
sanctioned
or
governed
technologies
that
people
can
choose
from
I
think
we're
flexible
I.
E
Think
we
I
think
we
tried
to
be
open
to.
Does
someone
do
something
new
and,
and
we
don't
we
haven't
allowed
it
yet
you
know:
should
we
and
I
think
we've
adapted
pretty
quickly
to
to
doing
that,
but
so
I
also
tend
to
take
the
the
middle
ground
approach
of
it's
good
to
limit
the
bounding
box
boundaries.
But
you
know
we
should
be
open
to
expanding
them
well
and
also
actually
deprecating.
That's
also
a
part
of
it
too.
So
you
know
how
one
deprecates
technology
is
very
hard.
I
think.
B
That's
a
very
good
point:
I
mean
I,
have
I
have
kids
one
thing
you
learn
when
you're
a
parent
is,
if
you
want
your
kids
to
do
something,
give
them
two
options,
and
you
are
both
those
options.
So
I
think
governance
is
largely
the
same
thing.
If
I
want
to
tell
people
to
do
something,
I'll
give
them
a
set
of
choices
they
can
make
in
any
of
those
choices.
Are
things
that
I'm
okay
with
them
doing?
Yeah
I
generally
feel
that
that
governance
should
not
be
and
asking
for
permission
it
should
be.
B
A
So
if
the
AEIOU,
that
was
the
integrated,
was
one
of
the
things
right
and
so
at
gate
lab
being
a
single
application
for
the
entire
DevOps
lifecycle,
all
the
people
that
use
us
really
believe
in
that
whole,
like
you
know,
the
single
hub
type,
single
application,
type
experience
and
I'm
curious
to
hear
what
you
folks
thoughts
are.
Do
you
try
to
go
towards
something,
that's
more
kind
of
a
hub
like
model
various
like?
Maybe
one
made
to
let
a
couple
of
things
that
plug
into
it?
How
how
are
you
looking
at
that
integration
piece?
B
I
would
say
that
if
a
tool
can
do
two
things
and
it's
the
best
at
both
those
things,
I'll
use
it
for
both
those
options.
I,
don't
want
to
use
features
of
a
tool
just
because
they're
there,
because
I
already
have
a
tool
if
it's
not
as
good
as
something
else,
I
don't
want
to
name
vendors
but
there's
some
logging
tools.
Now
that
started
integrating
metrics
and
some
metrics
tools
that
started
integrating
logging
and.
G
B
Feel,
like
that's
a
good
way
to
be
bad
at
both
those
things.
So
I'd
rather
pick
a
set
of
distinct
tools
that
are
able
to
do
things
the
best
they
can
and
have
integration
points
where
they
can.
You
know,
expose
the
features
of
one
or
the
other,
but
I'm
not
actually
trying
to
combine
them
all
into
the
same
same
pane
of
glass,
because
that
pane
of
glass
is
always
going
to
be
too
crowded
or
not
good
enough
or
frustrating
in
some
way,
so
you'll
feel
limited.
B
C
Yeah
I
mean
we.
We
are
the
same
way
so
I.
You
know
I'm
a
firm
believer
that
sometimes
you
know
one
tool
does
a
great
job
at
one
thing
and
trying
to
you
know
boil:
the
ocean
actually
starts
to
break
that
tool,
but
at
the
same
time
I
don't
want
30
tools
that
do
the
exact
same
thing,
because
one
person
likes
it
one
simple
way
or.
C
The
key
question
yeah
so
well
for
us:
we've
got
three
repositories:
one
because
we're
a
heavy
mainframe
shop,
and
so
they
were
just
integrated
a
long
time
ago.
It
works
it's
automated
I'm,
not
gonna
mess
with
it.
It's
just
it
isn't
worth
a
hassle
right
now,
when
we've
got
so
many
other
places
that
we
can
go
solve,
we
had
another
team
using
a
completely
different
tool
and
then,
when
I
came
in,
we
brought
in
well.
We
brought
in
your
tools,
and
so
you
know
trying
to
figure
out.
What's
the
best
case
scenario
for
them.
C
E
Yeah
I
think
the
only
thing
that
I
would
add
is
that
I
I
do
definitely
agree
that
you
know
as
tools
get
merged.
There
can
be
this
phenomenon
where
you
know
they
they
get
worse
at
two
different
things.
I
do
think,
and
I've
talked
about
this
a
lot
in
other
talks
and
stuff
that
I
do
think
that
in
certain
areas,
particularly
shion's,
there
is
an
opportunity
to
have
at
least
a
more
integrated
viewpoint
of
what's
going
on
within
systems.
A
I
heard
represent
agree
like
I've
spent
a
lot
of
time
and
observability
as
some
folks
know,
and
a
lot
of
it
is
that
you
know
you
get
that
alert
and
then
you
jump
through.
Then
you
go
to
the
graph
on
the
dashboard.
Then
you
click
to
see
like
oh,
what's
the
trace?
Look
like
oh
wait.
Actually
somebody
else
is
looking
all
over
the
logs.
Is
it's
a
little
bit
of
a
mess
and
the
workflow
can
be
a
lot
better
and
I.
A
E
E
E
You
know
the
different
available
options
that
word
that
we're
on
the
market,
if
you
will,
whether
that
be
open
source
or
paid
products,
and
generally
when,
when
I
look
at
new
technologies
I,
you
know
like,
like
a
procurement
process,
whether
it's
open
source
or
not,
and
you
know,
look
through
different
check
marks
and
stuff
like
that
and
I.
Think
that
you
know
we
did
a
bunch
of
analysis
to
decide
whether
it
was
worth
it
whether
we
should
build
whether
we
should
do
different
things
and,
and
the
analysis
turned
out,
that
we
should
make
the
tool.
F
We
often
forget
about
the
people.
Transformation.
You've
talked
about
the
developers
right
when
you
we
talk
about
cloud
native,
drink,
the
kool-aid,
but
most
enterprises
like
the
three
of
you,
they're
delta,
CVS
right,
you
can
have
a
hybrid
environment.
You
have
technical
that
you
have
like
seed
that,
then
you
need
to
move
forward
with
your
transformation.
What
are
you
doing
to
educate
your
developers
because
not
many
understand
what
cloud
native
is
yeah.
D
So
at
Delta
we
have
an
immersive
cultural,
like
learning
experience
that
pretty
much
all
of
our
teams
who
are
moving
to
micro
services
go
through.
It
deals
with
agile,
devops,
qaq
e
security,
all
these
different
things
that
you
have
to
take
into
account
when
moving
and
transforming
yourself.
So
we
have
these
teams
go
through
this
eight-week
cycle,
and
then
they
learn
these
new
capabilities
that
will
enable
them
to
deliver
within
the
new
world.
C
Yeah,
so
we
do
we
do
that
as
well.
We
have
a
training
site
that
we've
published.
You
know
they
can
go.
Take
self-service
training
things
like
that.
We
do
one-on-one
sessions
pretty
pretty
regularly.
So
it's
a
two-day
session
that
will
travel
on-site,
the
advantage
that
we
have
had
in
the
last
year
because
of
our
sort
of
all
in
and
digital's
we've
got
to
hire
new
people,
so
we've
brought
in
people
with
experience
that
can
teach
other
developers
how
you
do
pair
programming.
C
B
They
were
the
team
that
we
pointed
most
other
development
teams
to
if
they
had
questions
that
they
want
to
see
how
things
were
done,
because,
hopefully
those
teams
had,
you
know,
learned
in
sort
of
a
train-the-trainer
sort
of
model
and
that's
worked
somewhat
well.
We
also
do
some
one-on-one
courses
where
we
teach
people
we've
done
some
doing
some
more
in
depth.
You
know
four
or
five.
B
They
cloud
native
development
classes
now
and
then
access
to
things,
like
plural
site,
where
were
able
to
give
people
online
training
available
to
them
to
allow
them
to
you
know
kind
of
consume
all
this
stuff
themselves.
We
have
seen
that
some
developers,
just
or
not
we
are
not
able
to
make
this
jump
and
they
want
to
keep
on
doing
things.
The
way
they've
always
been
doing
them,
and
you
may
not
be
able
to
stop
that
you
can
tell
them.
This
is
not
the
way
our
company
or,
as
Melissa
said,
the
entire
industry
is
going.
B
If
they're
made
nothing
in
their
career,
they
might
not
be
interested
in
upscaling.
They
might
just
want
to
write
it
out
as
long
as
I
can
going
from
company
the
company
until
they
don't
have
a
valuable
skill
set
anymore,
if
that
happens
either
the
next
10
or
15
years.
So
you,
you
will
still
face
some
of
that
with
people
that
just
are
not
interested
in
in
adapting
the
way.
B
A
B
Went
through
dojo
at
t-mobile,
I
think
Melissa's
done
the
same
thing.
So
it's
it's
a
similar
approach
that
some
companies
are
adopting
where
you
know
it
really
is
a
very
in-depth,
hands-on
you're
paired
with
people
who
know
what
they're
doing
and
the
goal
is
to
really
train
these
people
up
in
the
way
of
doing
this,
and
they
should
be
listening
to
everything
that
they
heroes,
gospel.
That
happens
that's
great.
If
it
doesn't
happen,
they
might
still
make
mistakes
as
they
go
on,
but
you
know
learn
from
the
people
that
you
are
paying
to
teach
you.
A
H
So
I
come
from
a
company,
that's
running
a
lot
of
like
legacy.
Vm
stuff
in
the
cloud
and
I
was
wondering
if
you
guys
can
kind
of
go
over
a
quick
story
of
adopting
kubernetes
or
yeah
stop
being
Cuban
Indies.
Did
it
come
from
the
bottom
up
from
the
developers
or
was
it
like
a
dictate
kind
of
come
come
down
from
from
you
know
the
upper
and
then
what
was
the
aha
moment
that
you
had
something
that
you
could
really
grow
so.
B
We're
still
fairly
short,
fairly
new
into
our
kubernetes
journey.
However,
we
did
adapt
to
pivotal
Cloud
Foundry
about
two
and
a
half
years
ago
or
so
and
transition
that
was
the
transition
from
you
know:
legacy
bottleless
into
cloud
nader
micro-services,
and
that
came
both
from
bottom
up
and
from
top
down
we
had
developers
that
were
frustrated
with
how
long
it
took
them
to
get
resources,
and
we
had
leadership
that
was
frustrated
with
how
long
it
took
them
to
deliver
new
lines
of
code.
B
It
was
seven
months
and
72
steps
to
get
new
code
to
production,
which
is
just
insane
when
you
think
about
it.
You
cannot
possibly
adapt
the
business
needs
when
it
takes
you
that
long.
So
really
it
came
from
both
sides.
You
had
people
who
wanted
to
change
and
you
leadership
that's
willing
to
support
them
and
with
that
they
were
really
able
to
to
make
that
transition
effectively.
Because,
as
we
go
at
building
these
platforms,
they
definitely
broke
a
lot
of
standards
that
we
had
at
t-mobile.
So
when
team
said
no,
you
can't
do
that.
B
We
could
say
well,
my
VP
and
your
VP
both
want
that
to
happen,
so
it's
gonna
happen
at
some
point.
Let's
try
to
get
a
solution
that
we're
both
happy
with
instead
of
just
me
and
I
usually
got
people
in
line
because
they
understand
this
has
high-level
sponsorship
up
to
the
cio
level
and
it's
the
people
on
the
ground
making
it
happen.
But
without
that
sponsorship
it's
more
or
less
a
science
experiment
that
you
hope
doesn't
fail
catastrophically,
because
if
it
does
then
you're
not
gonna
have
much
support
there.
B
C
Yep
agreed
I,
so
actually,
when
I
came
to
CBS
our
CTO,
he
brought
in
the
office
of
the
CIO,
our
sorry,
our
CIO
brought
in
built
an
O
Co,
o
CIO,
and
he
left
six
months
into
our
journey
and
I.
Remember
thinking,
oh
my
gosh,
there
goes
our
executive
sponsorship.
What
are
we
gonna
do
and
so
for
me
it
was
finding
that
development
team
to
make
the
product
work.
C
We
also
started
with
cloud
foundry
and
just
churning
into
kubernetes
now,
so
we
are
moving
a
bunch
of
applications
up
to
kubernetes
and
it's
it's
definitely
been
a
an
easier
transition
because
we'd
already
taught
them
how
to
use.
You
know
how
to
develop
in
spring
and
how
to
develop
micro
services
so
giving
them
back
some
of
the
features
that
the
cloud
foundry
didn't
actually
offer
them
actually
has
been
a
little
refreshing
for
them.
C
But
now
they're
like
oh
wait,
a
minute
I
have
to
manage
more
here,
so
you
kind
of
have
to
wait
your
trade-offs
a
little
bit.
But
you
know,
technical
debt
is
really
expensive
and
it's
really
hard
to
get
out
of.
So
if
you're,
not
all
in
for
your
journey,
I
would
say
either
get
all
in
or
just
get
out
and
stay
put.
A
E
From
lift
perspective,
we're
still
actually
mostly
in
virtual
machines,
so
most
of
our
compute
is
still
still
virtual
machines.
So
we're
we
have
a
team
working
on
kubernetes
and
probably
in
q1
or
q2
it'll,
see
larger
rollout.
The
the
reasoning
for
going
to
kubernetes
is
not
really
agility.
I
mean
we
had
a
you
know
a
bespoke
stack
that
we
could
deploy
to
you
very
quickly
using
modern
tooling.
E
It
was
really
because
of
our
bespoke
stack
and-
and
this
was
said
before
I
mean
we
had
our
own-
deploy
tooling
arm
development,
tooling,
all
this
other
stuff
and
like
as
the
industry
moves
forward
with.
You
know
tooling,
built
on
top
of
kubernetes,
whether
that
be
something
like
spinnaker
or
or
you
know,
other
other
tools
that
our
Cooper
entities
aware.
We
can
obviously
benefit
from
a
larger
community
to
give
us
things
for
free,
so
I
think
the
goal
for
kubernetes,
maybe
in
the
future,
a
little
bit
for
Ben
packing,
but
but
in
general,
I.
D
D
So
my
answer
is
pretty
short,
we're
still
in
VMs
as
well.
So
we're
you
know
just
starting
our
journey
as
I've
said,
but
I
think
that
what
prompted
our
journey
is
just
the
need
to
be
able
to
scale
fast
with
you
know
the
travel
industry
having
like
large
loads
at
times.
If
there's
storms
or
things
like
that
happening,
you
have
to
really
be
able
to
scale
up
and
down
and
in
and
with
the
model,
if
it's
very
difficult
to
do
that.
A
Awesome
well,
thank
you
so
much
panelists
for
taking
the
time
to
speak,
I
learned
a
lot.
I
hope
the
audience
did
too.
We
appreciate
your
time
and
all
of
you
please,
if
you're
interested
continuing
this
discussion,
tweet
at
me
and
we'll
continue
with
over
live
streams
and
conversation
like
that
and
we'll
be
here
for
a
few
minutes.
If
you
have
questions
thanks
so
much.