►
From YouTube: The Elephant in the Kubernetes Room: Team Interactions at Scale - Manuel Pais, Independent
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
The Elephant in the Kubernetes Room: Team Interactions at Scale - Manuel Pais, Independent
Kubernetes helps us tame sprawling microservices architectures and address increased operational complexity. Kubernetes gives developers abstractions and APIs to deploy and run their services. Yet, the elephant in the room is that to run, maintain and evolve Kubernetes clusters, we need more ops expertise and most likely a dedicated team to do so. The question that begs to be asked is if we risk going back to pre-DevOps isolation between Dev and Ops teams? Is the tradeoff between better operational tools and introducing a new dependency layer on the path to production for application teams worthwhile? Are we making life easier for application teams or instead reducing their end-to-end ownership? Manuel will then introduce Team Topologies, a balanced approach for thinking about teams responsibilities and interactions which can help get the most value out of your Kubernetes adoption.
https://sched.co/Uadp
A
All
right:
well,
why
don't
we
go
ahead
and
get
started
good
afternoon
again
and
welcome
to
the
ops
track.
This
is
a
really
interesting
session.
The
elephant
in
the
kubernetes
room
team
interactions
at
scale
very,
very
kind
of
timely
topic,
I
think
also,
and
we're
lucky
enough
to
have
done
well
page
co-author
of
team
topologies
here
to
give
us
a
run-through,
so
man
well.
Thank
you.
B
First
of
all,
thank
you.
Everyone
for
attending
this
talk
the
last
afternoon
of
the
last
day
of
Cuba
and
North.
America
appreciate
that
so
we've
had
so
many
great
talks
about
kubernetes
and
engineering
activities
around
communities
in
the
last
days
and
there's
also
countless
great
articles
online
about
what
different
companies
are
doing
using
communities.
But
often
what
you
see
is
they'll
have
a
very
one
sentence
or
one
paragraph
about
you
know
who
we
are,
what
are
the
teams
involved
and
then
they'll
jump
straight
into
the
technology
part?
Now?
What
have
we
done?
B
What
have
we
achieved
on
the
technical
side,
and
so
they're
always
puzzles
me
a
little
bit,
because
I
find
that
the
way
teams
are
set
up
how
they
interact.
You
know,
how
is
the
technology
being
provided
to?
Other
teams
is
really
fundamental
to
the
success
and
the
adoption
of
new
technology,
in
particular
kubernetes.
B
So
in
this
talk,
you're
not
going
to
get
any
technical
insights
I'm.
Sorry,
if
that's
what
you're
looking
for
but
I
guess
not
and
I'm,
going
to
talk
a
little
bit
about
kubernetes,
really
a
platform
and
then
looking
a
little
bit
at
the
history
of
DevOps
and
this
kind
of
equilibrium
we'll
see
what
is
team
cognitive
load
and
why
it
matters
in
this
context
and,
finally,
we'll
look
at
some
kind
of
healthy
team
interactions
and
kind
of
more
explicit
ways
of
that
teams
can
think
about
how
they
interact
with
each
other.
B
So
a
couple
of
days
ago,
actually
during
the
keynotes
here,
I
I
confess
I
was
having
this
Twitter
conversation
and
basically
I
had
said.
Like
I
was
impressed
with
how
big
the
conference-
and
you
know
a
breakout
room-
is
like
500,000
people
and
so
Zeb,
Palmer,
replied
and
I.
Think
this
is
very
accurate
and
pragmatic
answer,
and
is
he
was
here
as
well,
and
he
said
you
know,
there's
always
a
next
new
thing,
the
next
big
thing.
So,
just
yesterday
we
were
at
the
OpenStack
conference
and
I
also
hear
that
dr.
B
Khan
doesn't
get
as
many
people
anymore.
So
this
is
typical
evolution
in
technology
and
that's
how
the
industry
has
evolved
and
progressed,
and
you
know
get
more
benefits
from
the
technology
that
we
use
so
as
organizations
we
should
be
expecting
to
deal
with
this.
You
know:
what's
the
next
big
thing,
we
should
expect
that
and
kind
of
what
we're
trying
to
say
is.
B
We
should
try
to
be
more
adaptive
rather
than
go
for
this
big
transformation
or
big
reorganization,
because
now
we
want
to
be
DevOps
or
we
want
to
adopt
or
annuities
whatever
it
might
be.
So,
as
was
mentioned,
I
co-wrote,
this
book
team
topologies
with
Matthew
Skelton,
published
by
T
Revolution
Press
from
Jim
Kim,
who
wrote
the
Phoenix
project
and
the
web's
handbook,
and
so
on.
B
So
we
talked
about
different
patterns,
four
types
of
teams,
the
expected
behaviors
and
interactions,
and
so
on,
but
kind
of
the
the
ultimate
outcome
that
we
would
like
to
get
from
organizations.
Looking
at
team
topologies,
how
do
we
become
more
of
a
living
organism
that
can
adapt
and
kind
of
morph
to
take
in
new
technology
and
new
practices,
rather
than
going
through
this
kind
of
major
transformation
into
a
whole
new
animal?
If
you
like,
so
let's
start
by
discussing
a
little
bit,
you
know
is
kubernetes
a
platform.
B
Obviously
it
depends
how
you
define
platform
right.
So
we'll
look
at
that
and
before
I'd
like
to
take
you
to
explain
a
little
bit
this
story
so
back
in
March
this
year,
I
was
at
Q
Khan
in
London,
and
Melanie
Sabula
from
Airbnb
gave
this
great
talk
about
how
they've
adopted
kubernetes
and
I
wrote
this
piece
for
info
queue.
So
I've
been
an
editor
for
them
for
years
and
I
knew
this
would
get
some
attention
because
kubernetes
and
because
unicorn
air,
B&B,
Google
etc
always
gets
attention.
B
But
what
happened
was
that
we
got
twenty
three
thousand
page
views
in
one
week.
So
if
we'd
have
an
idea,
the
usual
number
of
views
for
a
story
throughout
his
whole
lifetime
is
1/10
of
this.
So
this
would
like
a
proper
viral
kind
of
story,
and
so
I
was
thinking
about.
How
did
why
did
his
store
in
particular
pick
up
the
interest
from
so
many
people
and
I?
B
It
takes
a
while
before
people
feel
comfortable
with
this
new
technology,
and
so
I
believe
that
the
reason
that
attracted
so
much
attention-
and
we
know
that
kubernetes
as
a
platform,
if
you
like,
helps
us
manage
you-
know
the
complexity
of
microservices
scale
up
and
down
orchestrate
all
these
great
stuff
that
we
need,
and
it
also
provides
you
know
reasonably
good
abstractions
for
deployment
and
run
time
of
the
services
right.
So
that's
all
good.
B
That's
all
helpful,
but
there's
a
lot
more
going
on
right,
I'm
sure
you
know
better
than
me
all
these
other
tasks
that
you
need
to
think
about.
How
do
we
set
up
the
hosts
for
the
clusters
if
we
need
to
update
a
new
version
of
kubernetes?
How
do
we
do
that?
You
know
if
we
have
to
decide
on
namespaces
versus
clusters,
for
isolation
of
services
and
environments
and
so
on.
So
you
can
pick
insert
your
favorite
or
least
favorite
task
here,
the
point
being
that
there
there's
this
whole
bunch
of
activity
going
on
as
well.
B
So
if
do
we
know
who
is
responsible
for
this
type
of
tasks,
and
also,
very
importantly,
do
you
know,
do
we
know
who
is
impacted
if
this
is
like
an
afterthought?
If
it's
not,
you
know
clearly
for
everyone,
then
you're
probably
going
to
run
into
friction
when
teams
should
be
adopting
communities
they're
going
to
find
it
difficult
to
understand
what
you
need
to
do
so
I
think
it's
good
to
have
a
definition
of
a
platform
and
I
like
this
one
from
Evan
butcher.
So
he's
saying
a
digital
platform
is
a
foundation
of
self-service.
B
Api
is
tools
and
services,
that's
kind
of
common
sense,
but
also
the
knowledge
and
support
which
are
arranged
as
a
compelling
internal
product.
So
there
are
two
things
that
stand
out
for
me
here.
So
he's
talking
about
knowledge
and
support,
so
that
kind
of
implies
that
we
need
a
team
around
this
platform.
We
need
to
provide
good
documentation
and
we
need
people
that
can
help
the
users
understand
and
adopt
the
platform,
and
the
other
point
is
that
it
should
be
a
compelling
internal
product.
B
B
That
means
the
platform
should
really
make
it
very
easy
to
do
the
right
thing
for
most
use
cases
and
most
teams,
so
we're
not
talking
about
kind
of
the
old-school
kind
of
black
box
where
we
put
all
kind
of
shared
service
in
there,
and
then
we
don't
even
know
what
the
platform
does
or
how
they
run.
Are
they
how
to
use
them?
We're
talking
about
a
compelling
internal
product.
B
So
what
I'm
trying
to
say
here
is
that
kubernetes
itself
is
not
your
platform,
its
foundation.
It
provides
a
lot
of
the
functionality
that
we
need,
but
actually,
if
you
look
at
this
definition,
what
you
need
is
you
know,
setting
up
the
team
setting
up
the
support
and
the
knowledge
and
for
everyone
to
be
able
to
adopt
this
platform
in
a
easy
way.
So.
B
Of
course,
to
validate
this
I
need
a
tweet
from
Kelsie
Hightower
right
who,
by
the
way,
had
a
great
keynote
a
few
days
ago.
So
he
was
saying
few
weeks
ago
that
you
know
we
could
do
95%
of
what
cloud
native
does
with
VMs
application
service
and
configuration
management,
and
if
he
had
to
do
it
all
over
again,
he
might
use
kubernetes
but
would
be
kind
of
an
implementation
detail
behind
the
change
management
system.
B
So
when
he
talks
about
change
management
system
here,
I
think
about
the
platform
and
actually
the
workflows
that
the
platform
supports
and
provides
to
our
internal
teams
right.
So
we're
saying
you
know
you
could
be
kubernetes
or
you
know
whatever
used
Cloud
Foundry
OpenShift
whatever
it
is,
the
point
being
that
the
actual
platform
needs
to
have
a
kind
of
a
wrapper
around
this.
That
is
specific
to
our
organization.
So
we
get
into
the
question
of
who
is
then
responsible
for
this
platform.
B
Where
we
had
development
group
and
the
operations
group
isolated,
sometimes
the
operations
group
was
outsourced
to
a
third
party
company,
even
and
so
people
didn't
know
each
other
and
the
communication
was
through
tickets
or
other
kinds
of
formal
requests
right
for
any
kind
of
infrastructure,
change
and
so
on.
So
this
was
the
the
essential
problem
that
DevOps
is
trying
to
address
and
what
they
were
saying
is.
B
You
know
you
need
to
actually
sit
together,
know
each
other
and
find
out
discover
the
good
solutions
for
the
problems
that
are
affecting
the
both
groups,
around
deployment,
scaling,
monitoring,
etc.
So
that
was
the
basic
premise
of
DevOps
you
know,
and
then
we
got
all
the
tools
that
helped
us
and
are
great
but
kind
of
the
basic
idea
was
this
and
over
the
last
10
years,
especially
the
last
five
years
or
so.
We've
had
also
research
around
DevOps
practices
and
what
helps
teams
become
more
performance,
in
particular
the
state
of
DevOps
reports.
B
So
now
there
are
two
from
Google
and
puppet
labs,
and
this
knowledge
was
condensed
in
this
book
accelerate
also
from
IT
revolution
by
dr.
Nico,
first
gray,
and
just
humble
and
Jin
Kim,
and
what
they
did
is.
You
know
first
they're
using
statistical
methods
to
analyze
data
from
the
surveys
and
they
found
out.
B
So
this
is
kind
of
our
ideal
type
of
product
team
right.
So
what
happens
when
we
introduce
kubernetes,
I,
love,
elephants
and
I?
Think
of
companies
is
kind
of
an
elephant
right.
It's
not
a
small
thing
that
you
plug
into
your
workflow
and
you
use
write
this.
It's
a
big
thing.
It
gives
us
a
lot,
but
it's
you
know
it's
a
big
change.
So
what
are
we
going
to
do
then?
Assuming
we
have
this
kind
of
cross-functional
teams
full-stack,
if
you
like,
are
we
gonna
say?
Well,
your
full
stack.
B
So
you
know
you
take
on
kubernetes
as
well,
and
you
set
up
your
own
clusters
and
all
the
tooling
and
everything
you
need.
That's
probably
not
going
to
work
right.
So
the
red
color
here
is
it's
not
by
accident
it's
going
to
get
bloody
there
for
this
team,
so
they
wouldn't
be
able
to
continue
to
deliver
the
the
features
that
they're
focused
on
from
a
business
point
of
view.
B
And
if
we
have
this
kind
of
structure,
where
we
still
have
an
ops
group
and
a
development
group,
even
if
they're
you
know
collaborating
where
will
they
with
DevOps
but
where
the
screen
is
fit
in.
So
if
we're
saying
well,
the
ops
team
is
responsible
for
the
operational
side,
so
you
take
on
the
coronaries
load.
B
This
is
probably
not
going
to
work
so
well
either.
So
for
the
record
I'm
not
recommending
this,
because
if
we
take
the
risk
of
now,
these
two
groups
are
again
speaking
different
languages.
Focusing
on
different
things.
One
is
group,
is
you
know
the
cool
kubernetes
team
and
their
focus
on
that
and
the
development
teams
you
know
focus
on
whatever?
Is
the
new
JavaScript
or
react
framework
or
whatever?
So
you
don't
want
this
isolation,
because
actually
the
value
for
the
business
is
in
the
intersection
right
is
when
we're
able
to
deliver
and
run
our
services
efficiently.
B
So
if
these
are
not
good
approaches,
what
else
can
we
do
it's
important
to
introduce?
At
this
point
the
idea
of
team
cognitive
load
so
cognitive
load?
The
definition
is
the
total
amount
of
mental
effort
being
used
in
the
working
memory
and
it
can
be
broken
down
into
three
different
types
of
cognitive
load.
Okay,
so
we
have
intrinsic
cognitive
load.
That
means,
if
I
need
some
skills
for
my
day-to-day
work
and
I
don't
have
them.
Then
I'm
gonna
take
effort
in
my
memory
to
actually
find
out.
B
You
know
how
do
I
write
this
class,
or
rather
I
write
this
test
or,
if
I'm
learning
a
new
language,
that's
going
to
increase
my
intrinsic
cognitive
load,
but
we
know
how
to
reduce
that.
We
know
through
training,
pair
programming,
mentoring,
dojos,
whatever
techniques
you
use,
we
can
obscure
people
and
reduce
the
intrinsic
cognitive
load,
and
then
we
have
extraneous
cognitive
load
where
it's
related
to
the
mechanics
of
what
we're
doing
so.
How
do
I
deploy
my
application?
B
How
do
I
access
the
test
environment,
these
kind
of
activities
that
we
need
to
do
to
get
the
outcome
that
we're
looking
for
that
are
not
directly
related
to
the
business
outcome
right
and
then
we
have
the
germane
cognitive
load.
So
it's
everything
around
the
business
domain,
the
kind
of
problems
we're
trying
to
solve
for
our
users
or
new
functionality
we're
trying
to
deliver.
So
you
can
imagine
what
we're
trying
to
do
we
should
be
trying
to
do
is
reduce
as
much
as
possible,
intrinsic
and
extrinsic
octave
load.
B
So
we
leave
more
space
available
for
germane
and
focusing
on
the
business
outcomes.
The
kind
of
value
add
for
our
organization,
and
so
the
question
then,
is:
how
do
we
reduce
extraneous
cognitive
load
and
that's
where
platforms
come
in
and
how
we
use
them?
So
there's
this
famous
quote
right
the
best
part
of
my
days
when
I
update
ten
different
demo
files
to
deploy
a
one-line
code.
Change
said
no
one
ever,
and
this
is
an
example
of
extraneous
cognitive
load,
so
you're
trying
to
achieve
some
outcome
with
that
code
change.
B
And
you
have
to
understand
the
syntax
of
these
files,
which
which
configurations
you
need,
and
so
on
so
I
mentioned
Airbnb
that
they're
in
this
story.
So
what
they
did
was
they
provide
a
small
tool
that
allows
teams
to
focus
on
the
specific
configuration
that
is
important
for
their
projects
or
their
services.
So
they
don't
have
to
deal
with
all
the
mo
files
anymore.
B
They
focus
on
what
is
specific
to
a
project
that
we
need
to
configure
and
decide.
So
that's
what
you
have
there
on
the
left
and
then
they
use
this
tool
called
cube
gen,
which
generates
all
the
mo
files
for
all
the
different
environments
that
they
need
so
development,
cannery
and
production
and
then
applies
this
to
whatever
cluster
is
assigned
to
that
project
or
service.
B
So
that's
the
reason
enabling
teams
help
upskill,
the
stream
teams
provide
them
knowledge
and
reduced
learning
curve
around
whatever
domains,
test,
automation,
log.
What
have
you
complicated
subsystem,
teams
and
platform
teams,
so
we're
for
the
purpose
of
this
talk,
we're
focusing
on
stream
teams
that
kind
of
provide
a
heartbeat
of
delivering
value
to
the
to
the
business
if
you
like,
and
the
platform
team,
which
is
really
kind
of
shielding
the
stream
teams
from
and
knowing
having
to
know
the
internals
of
the
platform
of
the
internal
services
that
they
use.
B
So
this
service
can
be
anything
from
logging
monitoring,
deployment
etc.
So
in
this
context,
the
platform
team
has
a
very
specific
and
clear
purpose,
which
is
to
enable
the
stream
teams
to
be
more
autonomous,
with
self-service
capabilities
and,
very
importantly,
the
goal
is
to
reduce
the
extraneous
cognitive
load
of
the
stream
teams.
So
having
this
very
clear
purpose
helps
drive
certain
kinds
of
behaviors
and
thinking
about
platform
in
in
specific
ways.
B
So
we
should
have
an
on-call
support
for
a
platform.
We
should
have
status
pages
that
clearly
indicate
what's
the
current
status
availability
of
different
services,
specify
what
are
the
expected
or
suitable
communication
channels
for
teams
to
report
incidents
in
the
platform
or
ask
questions
or
provide
feedback,
make
this
clear
for
everyone.
So
it's
easy
to
provide
that
information.
B
The
response
time
for
incidents
in
the
platform
should
also
be
clear,
and
if
you
have
downtime,
or
at
least
degraded
performance,
because
you're
upgrading
cluster,
the
new
governance
version
or
what
have
you
these
things
should
be
announced
and
planned
and
find
out
if
anyone's
going
to
be
impacted.
So
we
shouldn't
just
assume
it's
okay
to
do
this.
B
Is
this
service
looks
looking
like
what
you
need,
and
so
we're
not
working
for
a
long
time
until
we
deliver
something
we
do
it
iteratively
and
we
can
apply
good
practices
like
TDD,
pair
programming,
what-have-you
and
critically.
We
want
to
focus
on
having
as
few
services
as
possible
of
higher
quality.
B
Like
I
said
before,
not
the
platforms
of
all
that
we
just
put
all
kinds
of
services
in
a
shared
platform,
but
actually
the
fewer
services,
the
higher
the
quality
we
can
provide,
and
we
know
you
know
we
understand
those
services
better
and
all
these
requires
good
product
management
skills.
So
understanding
you
know
what
are
the
different
priorities
for
the
teams?
How
do
we
set
up
a
roadmap?
How
do
we
communicate
that
to
our
users
and.
B
Finally,
the
platform
needs
to
be
focused
on
the
developer
experience.
This
means
it
needs
to
speak
the
same
language
as
the
development
teams
in
your
organization.
So
often
this
means
having
command
line
based
tools
like
in
Airbnb,
but
perhaps
in
some
organizations
their
developers
are
used
to
more
graphical
interface
approach,
and
so
it
should
cater
to
that
and,
very
importantly,
look
for
the
right
level
of
abstractions
for
your
engineering
teams.
That's
what
Airbnb
did
and
whatever
technology
that
you
use
it's
not
going
to
be
providing
the
specific
abstractions
that
make
more
sense
for
your
organization.
B
This
is
contextual,
it
depends
on
which
teams
you
have
which
much
maturity
they
have,
and
you
know
how
they
like
to
to
work
and,
in
general,
the
principle
of
keeping
it
simple
as
much
as
possible
and
reduce
complexity,
at
least
in
terms
of
the
usage
of
the
platform.
Sometimes
you
might
take
a
costing
it's
more
complex
to
make
it
easier
to
use
it's
kind
of
sounds
strange,
but
it
that
might
happen
and
that's
okay,.
B
So
Adam
Jacob,
who
created
chef
last
week,
had
this
treat
which
got
me
thinking
because
he's
comparing
these
our
experience
of
docker
with
kubernetes
and
regardless
what
you
think
about
it.
I'm
not
sure
kubernetes
is
in
the
business
of
making
the
user
experience
great
for
everyone,
because,
with
such
a
large
user
base,
that's
basically
impossible
and
like
I
was
saying
the
user
experience
or
the
developer
experience
depends
on
where
your
developers
and
engineers
are
at
today.
B
So
it's
contextual
to
your
organization,
so
I
think
you
always
need
the
platform
and
in
your
internal
platform
you
need
to
focus
on
the
user
experience.
Obviously,
kubernetes
should
be
thinking
about
a
good
developer
experience
as
well,
but
they're
not
going
to
be
able
to
provide
the
best
experience
for
everyone.
That's
basically
impossible.
B
So
there's
one
example
that
I
really
like
from
Twilio
around
getting
feedback
and
asking
feedback
from
the
platform
users,
the
engineering
teams.
So
what
they
do
is
I
believe
every
quarter.
They
run
a
Net,
Promoter
Score
survey
with
their
internal
teams
and
ask
them.
You
know
how
easy?
How
comfortable
do
you
feel
using
the
platform
to
build,
deploy
and
run?
Your
services,
and,
also
importantly,
is
it
compelling?
B
So
we
need
to
be
aware
of
the
expected
behaviors
from
from
team,
so
the
platform,
if
we
were
working
on
a
new
service
or
evolution
of
an
existing
service
we
would
expect
in
the
beginning
to
there
would
be
strong
collaboration
with
the
stream
team
that
needs
this
new
service.
So
we
expect
you
know,
perhaps
we're
going
to
time
box
a
period
of
time
where
we
expect
to
explicitly
collaborate
and
dedicate
the
effort
to
do
that
to
find
out.
You
know
how
should
the
service,
which
should
be
the
inputs
and
outputs
of
the
service?
B
And
then,
as
the
service
becomes
more
stable,
we
would
expect
a
platform
team
to
focus
more
on
stability,
providing
good
support,
great
documentation,
which
is
very
important
as
well.
So
if
you
need
to
hire
a
technical
writer
for
the
platform
or
you
need
to
send
people
in
technical
writing
trainings,
you
should
do
that,
because
documentation
should
not
be
enough
to
thought
it's
very
important
to
make
it
easier
to
adopt
a
platform
by
the
stream
teams.
B
B
Now
this
doesn't
mean
that
are
we
hiding
the
whole
kubernetes
and
the
development
team
should
not
know
anything
about
it
about
the
details?
That's
not
what
we
mean.
We
know
that
you
know
there's
kubernetes
running
underneath
and
that's
fine.
We
should
actually
promote
if
the
development
teams
are
interested
and
the
engineers
in
kubernetes
and,
for
example,
they
know,
there's
some
new
functionality
coming
in
in
kubernetes
version
X.
They
should
reach
out
to
the
platform
and
talk
about
you
know
when
and
how
should
we
adopt
this
new
functionality
that
could
be
useful
for
us?
That's
fine!
B
So,
for
example,
you
might
have
a
development
team
that
needs,
let's
say
a
new
metric
service
where
I
need
my
metrics
for
my
service
in
machine,
readable
format.
So
I
can
process
into
some
dashboard
that
my
clients
want
to
see,
for
example.
So
if
you
look
at
the
is
loosely
based
on
that
example,
from
Airbnb,
they
have
these
different
services
and
we're
saying
well,
we
want
to
work
on
it
on
this
new
service.
B
So
we
expect
this
kind
of
pattern
to
take
place
where
the
development
team
and
the
platform
team
will
collaborate
strongly
in
the
beginning
to
understand
what
exactly
is
you
need?
What
should
be
the
format?
How
do
you
run
this
and
at
some
point
it
starts
to
become
clear
up
to
the
last
phase
where
we
establish
this
service?
Ok,
it's
now
stable.
B
So
I'm,
getting
to
the
end
of
this
presentation,
I
wanted
to
leave
you
with
three
pointers
to
get
started
on
this
kind
of
more
team,
centric
approach
to
adoption
of
kubernetes,
so
number
one.
You
can
go
back
to
your
teams
and
Excel
assess
the
cognitive
load
they
have
today.
How
well
do
they
understand
the
platform
that
they're
supposed
to
use,
whether
it's
kubernetes
or
something
else,
and
the
abstractions
they
have
to
to
use
on
a
regular
basis?
How
well
do
they
understand
them
or
is
this
causing
friction,
is
causing
problems
and
difficulties?
B
Number
two:
you
can
define
your
platform,
make
it
more
visible
and
understand.
What's
the
gap
between
you
know,
we
have
this
kubernetes
implementation,
we're
using
it,
but
looking
at
the
definition
of
a
digital
platform,
what
exactly
is
the
gap?
What
are
we
missing?
Do
we
need
better
documentation?
Do
we
need
to
clarify
what
is
the
support
around
the
platform,
whatever
it
may
be,
so
understand?
What
is
the
gap
there
and
number
three
three
think
about
the
team
interactions?
B
Do
we
know
who
is
responsible
for
what
is
that
clear
and
who
is
impacted,
and
in
general
you
know?
How
do
we
collaborate
on
new
services
and
do
we
have
this
understanding
of
what
should
be
happening
in
terms
of
the
interactions
either
collaboration
when
we're
working
on
a
new
service
or
X
as
a
service.
B
Making
these
team
interactions
very
clear
is
going
to
help
reduce
friction
and
increase
adoption
of
kubernetes
or
whatever
technology
you're,
trying
to
put
forward
to
help
your
organization
and
think
about
the
Airbnb
example,
and
they
had
some
great
talks
here
at
cube
con
as
well.
Their
challenges
today
are
not
you
know,
on
the
adoption
of
the
platform
or
in
scaling,
because
so
many
teams
have
seen
how
useful
it
was
to
accelerate
their
delivery
of
their
services.
B
So
today
their
problem
is
actually
dealing
with
that
huge
amount
of
teams
using
their
platform,
so
I'm
near
the
end.
So
there's
this
slide.
If
you,
if
you
get
the
slides,
we
have
a
number
of
examples
of
companies
adopting
this
kind
of
platform,
behaviors
and
just
yesterday
also
published
this
article,
which
is
based
on
this
talk,
or
vice
versa.
B
So
if
you
want
to
share
this
with
someone
that
doesn't
have
time
see
the
video
that
could
be
useful
and
I
want
to
thank
you
for
attending
this
talk,
I
wrote
me
and
Matthew
would
like
appreciate
if
you
couldn't
give
any
kind
of
feedback,
so
you
have
the
latest
version
of
the
slides
on
the
on
the
schedule
and
if
you
could
give
us
feedback
that
we
were
great.
Thank
you
very
much.
A
C
B
So
the
crucial
idea
is
that
we're
we're
trying
to
reduce
cognitive
load
on
the
on
the
stream
teams
on
the
product
teams,
if
you
like,
and
so
the
other
types
of
teams,
that
is
always
their
primary
goal.
So
there
are
different
ways.
So
we
talked
about
platform
enabling
is
more
in
terms
of
upscaling
and
reducing
the
learning
curve
to
gain
new
capabilities
and
the
we
have
also
complicated
subsystem
teams.
Sometimes
you
wanna.
If
you
have
a
piece
of
software,
that's
really
complicated
because
algorithmically,
it's
very
complex
or
it's
kind
of
a
niche
technology.
B
D
Definitely
love
the
approach
of
saying,
like
hey,
look,
we
have
this
platform,
let's
make
it
attractive
for
you
for
people
who
decide
to
kind
of
choose
their
own
adventure.
How
do
you
kind
of
outline
the
like
the
the
definition
of
done
or,
if
you
really
want
to
own
your
own
experience
like
what
are
some
of
these
boxes?
You
say
of
here's.
What
you're
like
really
signing
up
for
you
know
from
like
security
from
you
know
like
whatever
like?
Was
it
really
the
list
that
you
like?
Tell
people
yeah.
B
So
one
one
thing
is
just
have
good
documentation
around
the
platform
and
the
platform
can
be
also
as
small
as
possible.
You
know
if
you're,
using
your
startup,
maybe
a
platform
is
just
a
wiki
page
saying
we
use
this.
We
use
whatever
server
lists,
and
these
are
the
kind
of
recommended
services
and
defaults.
Or
what
have
you
and
if
it's
a
bigger
platform,
then
you
need
more
documentation
around.
You
know
what
does
it
do
and
how
and
and
just
like
we've
seen
it's
also
providing
the
support
to
the
teams
to
understand
how
the
platform
runs.
D
B
So
if
you
have
a
stream
team,
a
product
team
that
needs
wants
to
take
kind
of
alternative
Road,
essentially
there
are
then
on
their
own
right.
So
the
platform
it
should
make
it
easier
to
do
the
right
thing
for
most
use
cases,
it's
kind
of
paving
the
road.
So
if
a
team
has
a
specific
reason
why
they
need
to
go
off
track
because
they
need
to
do
something
very
specific,
they
better
have
you
know
a
good
use
case
for
that
and
understand.
You
know
we're
investing
this
effort
to
do
that
outside
the
platform.
B
It
has
to
have
reasonable
benefit
for
us
to
do
that,
but
essentially
then
they're
outside
the
platform.
The
other
way
to
see
this
is
the
platform
should
not
be
like
we
said
should
not
be
mandatory,
should
not
be
a
one-way
thinking.
So
there
are
examples
where
organizations,
for
example,
foresee
ICD
will
the
platform
team
will
provide
different
stacks.
You
want
to
use
jenkins
or
you
want
to
use
some
other
tool
for
your
CI
CD.
You
know
we
have.