►
Description
This whole story began with Docker. It began with Docker because developers simply loved it. It began with Docker because of the grass roots developer driven adoption of containers. It began with Docker because we needed to find new ways to deploy, run and manage applications using containers.
In this talk Hannah will reflect on the origin story of Kubernetes, and how Developer Experience is playing an increasingly important role in organisations today. Sharing stories of success (and sorrow) to help you as you build and launch your own platforms.
A
So
I
am
very
excited
to
introduce
our
next
speaker,
I'm
also
quite
biased,
because
we
used
to
work
together
and
I'm
a
big
fan
of
hers.
So
our
next
speaker
is
hannah
foxwell
from
good
morning
from
town
zoo,
labs
at
vmware
hanna's
talking
about
where
we
started
and
where
we're
going.
So
that's
going
to
be
quite
interesting
hannah
over
to
you
awesome.
Let.
B
B
But
first,
let's
talk
about
why
we
need
platforms.
Delivering
software
is
hard.
A
successful
platform
makes
it
easier
for
development
teams
to
deliver
apps
into
production
and
an
unsuccessful
platform
can
actually
make
it
harder.
You
know,
I
think
these
these
stats
here.
These
are
pretty
scary,
but
they're
also
believable,
based
on
my
experience,
working
working
with
customers
and
helping
to
address
some
of
these
problems.
Now
only
52
of
net
new
apps
ever
make
it
to
production.
B
B
B
I
feel
quite
lucky
that
I
remember
the
days
before
the
internet.
You
know
there's
lots
of
people
now,
like
you
know
the
next
generation
who
who
haven't
experienced
that
they've
grown
up
in
an
internet
enabled
world
in
a
digital
world,
but
I
do,
I
do
remember
dial
up
as
a
teenager.
I
remember
getting
excited
about
yahoo
and
napster
and
myspace
and
we've
all
been
part
of
this
evolution
in
technology.
B
The
internet
has
began
and
plays
an
increasingly
important
role
in
our
lives,
and
you
know
when
we
were
younger.
We
saw
those
analog
businesses
around
us
move
online
and
those
companies
that
were
good
at
technology
having
an
unfair
advantage
over
those
that
weren't
with
the
agile
manifesto
in
2001
software
development
became
agile
and
development
teams
started
shipping
code
more
frequently
and
the
businesses
they
worked
for
wanted
change
an
ever-increasing
velocity.
B
This
was
a
really
tough
time
to
be
in
infrastructure
or
operations
because
it
was
so
hard
to
keep
up.
There
was
this
tension
between
dev
and
ops,
delivering
software
frequently
and
safely
needed
new
approaches
and
tools,
or
that
velocity
was
going
to
be
at
the
expense
of
stability
and
often
was
at
the
expense
of
stability.
B
In
2011
we
were
using
tools
like
chef
and
pufflet
to
deliver
infrastructure
as
code,
but
I
remember
the
shift
in
the
community
as
docker
came
on
the
scene
in
2013
and
it
really
changed
the
game.
Suddenly,
everyone
was
talking
about
docker
and
how
they
were
experimenting
with
containers
developers,
simply
loved
working
with
docker
with
the
development
community
embracing
docker.
We
needed
new
ways
to
manage
these
containers
and,
of
course,
in
june,
2014
kubernetes
was
founded.
B
I'm
really
fortunate
working
in
vmware
tanzu
that
two
of
the
three
co-founders
of
kubernetes
actually
are
part
of
the
vmware
tanzu
team,
and
you
know
the
origin
story
around
kubernetes
is
theirs
to
tell
it's
not
mine,
but
my
story
is
really
one
about.
You
know,
excitement
and
innovation
and
the
impact
that
it
had
on
the
community
as
a
whole.
You
know
there
was
a
better
way
of
doing
things.
It
was
impossible
to
ignore
this.
B
B
These
were
the
harder
problems
to
solve,
and
so
that's
when
I
got
involved
in
the
human
ops
community
to
try
and
elevate
that
conversation
and
that
focus
to
the
people
part
of
this
problem.
You
know
technology
was
only
one
aspect
of
this.
We
had
a
lot
of
cultural
and
people
challenges
to
address.
If
we
wanted
to
get
better
at
this,
if
we
wanted
to
be
not
so
hard
and
in
2018,
I
got
really
lucky
and
joined
a
team
of
people
who
were
on
a
mission
to
build
wildly
successful
platform
teams.
B
B
B
It
gives
you
an
api
to
interact
with
your
infrastructure
and
operate
your
apps
in
in
a
fantastic
way,
but
when
you
think
about
delivering
a
platform
as
a
service,
this
might
not
be
the
service
you
want
to
expose
to
your
teams
and
in
many
organizations
I
work
with
it
isn't
the
case.
The
surface
area
for
configuration
is
massive.
B
B
All
right,
kelsey
hightower,
said
that
kubernetes
is
a
platform
for
building
platforms.
You
know
that's
a
fantastic
quote.
I
will
quote
that
forever.
It's
powerful
flexible
extensible,
but
it's
not
a
developer
tool.
I
don't
think
not
yet
anyway,
you
know
the
wall
of
yaml
is
real
and
we
need
to.
We
need
to
really
think
about.
You
know
what
service
are
we
providing
to
the
developers
in
our
organization
for
the
app
teams
that
want
to
land
on
these
platforms?.
B
So
how
do
we
approach
this
problem
in
the
right
way
and
how
do
we
provide
that
platform
as
a
service
experience
instead
of
building
platforms
as
silos
within
our
organization,
the
state
of
devops
report
in
2020
called
out
some
really
interesting
insights
that
really
resonate
with
my
experience.
Building
platform
teams
as
well.
A
product
mindset
is
key
to
scaling
devops
and
your
platform
and
higher
levels
of
devops
evolution
mean
more
self-service
offerings
for
developers.
B
B
You
don't
want
to
disband
that
team
and
you
don't
want
to
re-prioritize
their
time
in
a
way
that
leaves
your
platform
stagnant
and
brittle.
It's
amazing.
How
often
I
see
this
happening
in
companies.
You
know
what
started
off
with
a
lot
of
promise
loses
momentum
simply
because
people
aren't
working
on
it
actively,
and
I
hope
it
goes
without
saying
that
deadline
driven
development
is
a
really
bad
idea,
especially
when
you're
building
a
new
service.
B
B
The
next
thing
I
see
a
lot
of
in
teams
is
field
of
dreams,
engineering
and
what
I
mean
by
that
is
you
know.
If
if
we
build
it,
they
will
come,
they
build
a
platform
in
a
vacuum,
never
speaking
to
the
teams
who
might
want
to
use
it.
I've
seen
a
lot
of
time
and
money
wasted
on
this
approach.
I'm
talking
millions,
tens
of
millions
when
you
don't
speak
to
your
users
about
what
they
need.
You
miss
opportunities
to
solve
their
problems
and
you're
more
likely
to
over
engineer
your
solution.
B
So
here's
a
model
that
I
found
to
be
really
useful
when
we
think
about
building
platforms
and
platform
teams,
I'll
start
with
the
application
team
and
their
mission,
because
this
is
really
intuitive.
You
know
the
application
teams
that
work
in
your
organization.
They
want
to
build
an
amazing
product
and
a
valuable
service
to
their
users.
B
The
way
I
like
to
think
about
platform
teams
is
exactly
the
same.
They
want
to
build
an
amazing
product
and
a
valuable
service
for
their
users,
but
their
users
are
the
developers
they're
the
application
teams
who
are
consuming
this
platform
as
a
service
and,
of
course,
there's
infrastructure
somewhere,
whether
you're
using
a
cloud
provider
or
whether
there's
you
know
a
data
center,
that
your
company
is
managing
yeah.
B
When
we
provide
these,
what
we
provide
a
platform
as
a
service
we
want
to,
we
want
to,
we
know,
allow
the
application
team
to
both
build
and
operate
their
applications.
We
want
to
give
them
the
tools
they
need
to
be
successful
at
that.
One
anti-pattern
that
I
see
frequently
occurring
is
where
the
platform
team
are
the
operators
of
the
apps,
and
that
doesn't
really
make
sense.
They're,
not
the
right
people
to
do
that.
They
don't
have
the
knowledge
of
what
those
applications
are
are
doing.
B
The
best
people
to
support
those
apps
are
the
people
who
built
those
apps.
You
know
you
build
it,
you
run
it,
and
so
you
know
we
what
what
we
really
want
to
look
for
and
what
we
really
want
to
move
towards.
Is
this
setup
whereby
you
know
you
build
it?
You
run
it
and
you
own
that
service,
you
own
that
service
and
you
provide
that
service
to
your
users.
B
So,
let's
talk
more
positively
instead
of
things
that
we
shouldn't
do.
Let's
talk
about
some
of
the
things
that
we
can
do
some
really
simple
and
easy
things
that
we
can
do
to
get
our
platforms
back
on
track.
If
some
of
those
things
that
I
was
saying
earlier
were
resonating
with
you,
you
know:
ask
yourself
why
you're
building
a
platform
remember
we
don't
just
build
platforms
for
fun.
B
Even
though
building
platforms
is
fun,
we
provide
a
service,
a
service
to
developers
and
when
I
say
devx,
I'm
talking
about
user
experience
for
developers
using
that
platform
setting
out
your
mission
and
building
a
team
to
deliver
on
that
mission
is
the
first
step.
Technology
ought
to
be
an
implementation
detail.
Your
purpose
is
to
solve
problems
for
your
users.
B
Are
you
know
by
creating
that
culture
of
of
learning
and
sharing
building
bridges
with
your
users
talking
to
them
more
often
sharing
what
you've
achieved
and
what
you're
working
on
next
in
your
roadmap
show
that
progress,
but
also
seek
feedback.
You
know,
is
the
thing
that
we've
built
good
enough.
You
know
what
could
we
be
doing
better
like?
How
can
I
help
you
more
invite
people
to
regular
demos
or
blog
internally
talk
internally
about
what
you've
built
really
evangelize?
That
platform
experience
that
you're
providing.
B
B
Getting
software
to
production
still
feels
hard
for
so
many
people
and
I've
been
working
on
this
problem
for
10
years
now,
and
I
don't
think
it's
going
to
go
away
anytime
soon.
We're
still
learning
how
to
do
this
and
as
technology
changes
we'll
have
to
learn
and
adapt
with
that,
but
as
platform
engineers
and
platform
teams,
we
can
help.
You
know
we
can
help
by
delivering
platforms
as
a
service
instead
of
building
walls
and
silos
within
our
organizations,
and
we
can
help
by
focusing
on
the
developers
as
our
as
our
users
of
these
platforms.
B
A
Thank
you
hannah.
That
was
fantastic.
I
am,
as
I
mentioned
earlier,
slightly
biased
because
I
feel
very
passionately
about
some
of
those
same
things
I
had
I've
there's.
I
don't
think
I've
got
any
questions
yet
on
the
slack.
But
what
I
wanted
to
ask
was,
I
love
the
way
you
frame
it
as
it's
not
just
about
building
platform.
It's
also
about
building
platform
teams,
and
you
mentioned
that.
There's
you
know
within
the
platform
team
there's
their
van
ops.
You
need
to
be
able
to
do
both.
B
Yeah
I
mean
I
I
I
think
I
know
where
your
question
is
going
and
it's
I
think
I
mentioned
it
on
one
of
my
slides,
but
I
didn't,
I
didn't
speak
to
it.
So
I'll
speak
to
it
now,
which
is
about
really
having
someone
who
is
the
product
manager
of
that
service
internally,
if
you
could
imagine
you're
amazon
for
a
moment,
aws
and
you're
providing
a
service
through
an
api,
our
something
new
you've
got
a
product
manager.
Who
is
really
looking
at
the
strategy
for
that
service?
What
does
it
need
to
do
today?
B
What
might
it
need
to
do
tomorrow
and
how
do
I
make
sure
that
people
can
consume
it
without
needing
to
ask
me
questions,
and
I
think,
when
we
approach
our
internal
platforms
in
that
way,
and
we
put
a
product
manager
in
place
who
values
those
things
we
we
drive
towards
a
better
outcome
for
the
users
of
the
users
of
the
platform.
You
know
the
kind
of
the
extreme
end
of
it
is.
B
You
know
when
you
have
your
platform
team
in
that
silo
who
are
interacted
with
via
tickets,
but
you
know
imagine
if
a
cloud
provider
did
that
how
like
unthinkable,
that
would
be-
and
you
know
these
are
these-
these
are
the
platforms
that
developers
are
accustomed
to
consuming.
So
if
we
give
them
a
worse
user
experience
within
our
own
organizations,
they
will
simply
go
elsewhere.
B
A
I
liked
your.
I
also
liked
your
comment
about
field
dreamers
development.
Like
I
love
that
film.
I
think
that
might
show
how
old
I
am,
but
I
mean
I
like
that
film
and
I
like
the
idea
of
kind
of
people,
think
if
they
build
it,
they
will
come,
but
unlike
field
of
dreams
that
that
probably
doesn't
happen-
and
you
talked
about
collaboration
which
is
again
so
important,
as
well
as
the
the
platform
team
folks
collaborating
with
the
application.
Folks
are
there
other
people
that
they
should
be
trying
to
communicate
with
them?
B
My
little
picture
was
was
so
oversimplified
and
in
large
organizations,
you'll,
probably
chop
up
those
capabilities
of
your
platform
into
into
different
domains.
You'll
absolutely
need
to
work
with
security,
and
I
think
a
good
like
one
of
the
definitions
of
a
good
platform
is
that
it,
you
know,
is
secured
by
default.
B
You
know
it
makes
it
difficult
for
developers
to
do
something
that
would
put
you
know
the
security
of
your
infrastructure
and
your
applications
at
risk,
so
so
yeah
I
mean
it
is
very
dependent
on
the
size
and
the
maturity
of
the
organization,
but
but
yeah
like,
I
think,
there's
a
huge
amount
of
teams
that
you
need
to
work
with,
and
sometimes
I
think
you
know.
Sometimes
I
think
security
teams
could
benefit
from
that
as
a
service
mindset
as
well.
How
can
we
help
the
rest
of
the
organization?