►
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 Kubernetes to PaaS to … Err, What’s Next? - Daniel Bryant, Ambassador Labs
Developers building applications on Kubernetes today are being asked to not just code applications -- they are also responsible for shipping and running their applications, too. We often talk about needing a Kubernetes platform, but are we really looking for a PaaS? Or instead, are we looking for some kind of developer control plane with a Goldilock-sized collection of tools that provides just the right amount of platform? This talk will look back on my experience of building platforms, both as an end-user and now as part of an organization helping our customers do the same. The key takeaways are: - Treat platform as a product - Realize that you can’t have good developer experience (DevEx) without good UX - Focus on workflows and tooling interoperability We’ll wrap this talk with a walk-through of the CNCF ecosystem through the developer control plane lens, and look at what’s next in the future of this important emerging category.
A
Okay,
so
we're
gonna
get
started
next
session
from
kubernetes
and
pastor
or
what's
next
and
my
name
is
danielle,
I'm
I'm
more
than
happy
to
be
here
as
a
moderator
district,
chair
and
trade
host,
and
here
we
are
another
daniel
bryant
from
the
the
ambassador
rep
right
and
then
he
is
the
head
of
the
devil.
So
I
believe
he
got
a
lot
of
a
bunch
of
interesting
stuff
to
talk
about
today.
So
please
welcome
to
daniel.
B
B
Now
I've
asked,
but
from
kubernetes
to
pass
platform
as
a
service
to
what's
next,
I'm
gonna
pitch
its
golden
paths:
aka
paved
roads,
paved
paths,
pace
platforms,
the
mercedes-benz
folks,
cued
it
up
perfectly
in
the
keynote
this
morning.
Right
they
mentioned
about
golden
pass,
which
I
thought
was
great.
B
After
we
sort
of
looked
at
some
of
that
developer
focus,
I
am
going
to
say
something.
I'm
kind
of
hearing
being
called
platform
engineering
is
key
to
this,
going
forward
right,
platform,
engineering
and
I'll
break
down
some
of
this
as
well.
That's
my
spoiler
alert.
You
know
you
can
go
and
go
get
coffee
now
right,
but
we'll
dive
into
this
in
much
more
detail.
Very
briefly,
at
daniel
bryant
uk
on
most
of
the
interwebs
twitter
linkedin
github,
all
the
good
places
right.
I
am
head
of
devrella
ambassador
labs.
B
My
background
is
java
developer,
moved
into
solution.
Architecture
then
did
ops
built
a
bunch
of
platforms
on
mesos
on
kubernetes
made
a
bunch
of
mistakes
had
a
few
successes
would
love
to
share
that
today
and
I
love
sharing
my
knowledge.
I
love
writing
a
few
books
onto
my
name
with
some
friends
of
mine
and
I'm
on
info
cue
and
the
new
stack
a
lot
as
well.
B
Let's
begin
our
journey,
so
we're
hearing
shift
left
all
the
things
right.
That's
what
I'm
hearing
a
lot
from
community
folks,
I'm
chatting
to
to
customers
and
we're
being
told,
particularly
as
developers
we
need
to
shift
left
it
kind
of
makes
sense
right.
Even
in
my
career
early
on,
like
2000s,
we
were
taught
to
think
about
the
ilities
early
reliability,
the
security,
all
these
good
things
extensibility
right,
but
you
need
abstractions,
apis
and
tooling
to
help
this
right.
B
The
danger,
if
you
don't
have
these
things,
you're,
just
shifting,
left,
more
responsibility
on
to
developers
and
the
joker
charity
major
says
it
perfectly
right.
You
can't
call
yourself
a
full
stack
engineer
unless
you
can
do
react
all
the
way
through
to
chip
design.
That's
full
stack
right
bit
of
terraform
in
the
mix
bit
of
bash
there
as
well.
It's
not
going
to
work,
even
the
smartest
of
us
in
the
room
can't
hold
that
many
abstractions
in
our
brain.
B
Now,
when
I
started
my
career,
2000s
kind
of
pre-devops
right
dinosaur
age,
the
tooling,
the
abstractions
was
not
there.
I
wasn't
doing
much
security
stuff
because
it
was
basically
hardware
stuff
and
a
different
team
did
that
when
I
worked
at
the
uk
government
as
an
example,
now
I
think
we've
almost
come
full
circle.
You
know,
tool
sprawl
is
pretty
much
an
issue
in
the
cloud
native
space
and
it's
mandatory
at
this
point.
B
B
B
Now
we'll
build
this
slide
up
as
we
go
along
through
the
talk,
but
I
think
and
chat
with
me
and
afterwards
at
the
booth,
if
you
think
I'm
wrong,
but
I
think
every
developer
needs
to
think
about
coding
shipping
running
living
in
my
ide
these
days
we
separate,
deploy
and
release
right,
they're,
two
different
things
deploy
into
kubernetes,
releasing
maybe
using
argo
flux.
Something
like
that
right
and
then
running
is
all
about
observability.
B
Getting
that
feedback
that
resilience
continuous
delivery
does
not
stop
when
you
deploy
something
it
only
just
begins
right.
You
get
the
feedback
going
on.
You
need
to
code
as
a
developer.
You
need
to
ship,
you
need
to
run,
but
you
need
those
abstractions,
because
you
can't
do
it
all
yourself.
You
need
the
abstractions
for
the
platform
team
to
kind
of
communicate
with
you
now
kubernetes
I've
chatted
to
many
people
over
the
last
live.
I
was
pre
1.
B
1-0.
I
was
involved
in
kubernetes
and
I've
chatted.
Many
folks
and
some
folks
literally
look
at
kubernetes
and
think
it's
a
paz.
They
think
it's
a
heroku.
They
think
it's
a
cloud
foundry
and
they're
disappointed
when
it's
you
know
it
doesn't
do
all
the
code.
Ship
run
things
right,
but
other
folks
look
at
kubernetes
and
see
it
as
that
foundation
of
sort
of
you
know
foundational
platform
as
a
component,
and
I
was
at
devoxx
uk
last
week
doing
a
talk
and
josh
long,
I'm
sure.
B
If
you're
in
the
java
space,
you
know
josh
long,
he
types
and
codes
faster
on
stage
than
I
do
normally
and
he's
just
an
epic
kind
of
person
like
lots
of
great
jokes,
but
he
did
this
graduate.
I
love
kubernetes,
it's
my
favorite
yaml
database
right
and
I,
like
I
looked,
I
tweeted
it.
I
got
a
bit
of
an
interaction.
I
was
like
well
done,
josh,
that's
great,
but
it
kind
of
got
a
bit
more
surreal
right,
as
in
emmanuel
jumped
in
the
mix
who's
a
database
specialist.
B
He
works
on
hibernate,
which
is
an
orm
right
and
he's
like
yeah.
I
think
this
is
kind
of
true
kube
is
an
api
database
that
happens
to
be
in
yaml
and
then
brian
grant
co-creator
of
kubernetes
got
involved
like
yeah
by
design.
Kubernetes.
Is
the
api
database
right?
It's
one
of
your
core
foundational
pieces
of
your
platform,
but
when
you
think
about
it,
this
way
it
kind
of
changes
things
up
a
little
bit.
B
Let's
take
a
step
now
back
to
the
future.
Through
my
development
career,
my
my
sort
of
ops
career
as
well,
I'm
going
to
brain
dump.
This
table
we'll
walk
through
it
together,
don't
worry!
But
what
I
want
to
do
is
the
years
go
down
through
here,
yeah
my
career,
roughly
20
years
or
so
career,
and
I
want
to
overlay
my
cognitive
load
on
this.
The
kind
of
the
challenges
I
was
having
as
a
developer
as
I
was
going
through
this
time
period
and
spoiler
alert
stuff
to
the
right
means
it
was
more
painful
right.
B
So
I
started
in
2000
java,
monoliths
in-house
tin.
As
a
developer,
I
lived
in
my
ide
oracle
jdev
I
pushed
it.
It
was
cvs
at
the
time.
Git
wasn't
a
thing
back
then
right
and
I
pushed
to
that
and
then
the
ops
team
deployed
it
and
dealt
with
all
security
they
raised
the
ticket.
If
there
was
a
problem
kind
of
happy
days,
I
was
learning
I
had
some
amazing
mentors.
It
was
all
good
stuff
right.
B
It
got
a
bit
more
tricky
2005
time.
I
was
doing
a
lot
of
classic
sewer
at
the
time
and
the
promise
was
you
know,
the
workflows
are
standardized.
The
interoperability.
Is
there
xml
all
the
things
right
and
anyone
who's
live
through.
That
era
will
recognize
like
the
promise.
Was
there.
The
delivery
was
not
quite
there.
I
had
to
think
more
about
shipping
and
running
now
as
a
developer,
because
my
code
wasn't
just
running
on
an
app
server.
It
was
running
in
an
enterprise
service.
Bus,
it
was
running
in
a
message
queue.
B
It
was
running
in
some
other
enterprise
middleware.
It
was
a
lot
trickier,
as
I
stepped
through,
that
in
my
career
I
did
a
bunch
of
work
on
ruby
on
rails
and
also
later
java
on
cloud
foundry
classic
paths.
Cf
push
at
the
command
line.
Heroku
push
the
stuff
went
wrong
when
it
was
running,
we
used
to
use
new
relic
quite
a
lot
right,
new
relic
dashboard
popped
up.
I'd,
look
at
it
figure
out.
What's
going
on,
do
some
coding
test
locally
push
super
super
easy.
B
The
developer
experience
the
ux
of
heroku
and
the
ux
of
new
relic
had
clearly
been
thought
about
as
products.
They
worked
really
really
well
step
through
a
little
bit
now
to
where
we're
at
now
right,
so
I
went
to
work
for
a
boutique
consultancy
called
open
credo
in
london
in
2015
time.
I
think
it
was,
and
we
know
as
consultants
you
only
get
brought
in
when
stuff's
going
wrong.
Anyway.
B
B
I'm
gonna
get
bash
to
bootstrap
that
then
I'm
gonna
have
to
docker,
and
I
love
containers,
love
docker,
not
trying
to
sort
of
say
anything
bad
about
all
this
stuff,
but
there's
just
so
many
layers
right
and
most
developers
that
I
was
interacting
with
particularly
at
that
time
just
wanted
to
write
code.
She
just
wanted
to
ship
some
value
and
go
home,
and
I
respected
that
right.
I
love
learning
playing
with
the
new
stuff.
B
B
B
I
learned
you
can't
have
good
developer
experience
without
good
user
experience
and
I
mean
proper
user
experience,
not
ui.
So
when
I
back-end
engineer
right
when
twitter
bootstrap
was
released,
I
thought
that
was
ux,
but
that's
just
like
a
web
framework
right.
So
I'm
talking
about
proper
user
experience
and
focus
on
the
workflows
and
the
interop.
So
many
times
we
had
these
promises
on.
You
know,
workflows
and
interop
we've
not
quite
delivered
as
an
industry.
B
We
get
distracted,
sometimes,
but
I'll
walk
through
these
three
things
now
and
give
you
a
bit
more
of
a
deeper
dive
into
each
one.
So
platform
is
a
product.
This
is
not
new
right.
The
golden
paths
like
we've
heard
netflix
talk
about
them.
I
know
they've
been
working
on
them
many
years
I
first
bumped
into
it.
In
qcon
new
york
2017
time
frame.
They
talked
about
freedom
and
responsibility.
B
You
could
build
your
app
as
you
wanted
to
you
could
ship
it.
You
could
run
it,
but
you
were
on
your
own.
If
you
deviated
from
the
paved
path,
they
had
an
approve
sort
of
like
not
as
I
proved
but
they'd
come
together
and
agreed
on.
This
is
the
command
line
tool
set.
We
use,
you
know
we
use
jenkins
or
spinnaker
to
deploy,
and
this
is
the
platform
we're
running
on.
You
can
step
away
from
that,
but
it's
on
you
to
maintain
it
right.
B
They
talked
a
lot
about
these,
making
it
easy
to
do
the
right
thing.
That's
the
golden
path.
I
also
saw
a
spotify.
Of
course
they
were
like
golden
paths.
They
had
like
golden
pass
for
ml
services,
golden
paths
and
microservices
golden
paths
for
their
desktop
app
again,
it's
making
it
easy
for
the
engineer
to
quickly
spin
up
a
project,
a
developer,
get
everything
ready,
have
it
all
plugged
into
ci
and
cd
and
just
get
coding
and
delivering
value.
B
I
worked
on
a
bunch
of
stuff
at
2005
2015
for
not
on
the
high
street.
That
was
my
first
proper
platform
as
a
product.
We
used
mesos
at
the
time
and
containers
and
we
really
thought
about
the
developer
experience
and
it
paid
dividends.
I've
chatted
to
go,
go
spot
check.
They
did
a
great
keynote
dave
studio
did
a
great
keynote
and
we
had
him
on
the
podcast
a
while
back.
If
you
look
back
a
couple
of
years,
kubecon
dave
talks
about
how
he
thought
about
properly
designing
and
treating
the
platform
as
a
product.
B
Now
it's
got
to
be
product
led
right
and
guerrilla.
If
you
don't
follow
him
on
twitter,
fantastic
and
say
sorry,
nikki,
I've
learned
a
lot
from
nikki
over
the
years,
nikki
had
worked
at
financial
times.
She
worked
at
sky
scanner
and
all
these
companies
right.
These
big
you
know
not
even
like
unicorns
necessarily
financial
times
skyscanner
other
companies.
They
are
really
talking
about.
B
You
need
to
invest
in
the
platform
as
a
product
staff
it
appropriately
resource
it
appropriately
think
of
it
as
a
product
and
if
you
haven't
bumped
into
team
topologies
yet
like
this,
is
my
what
single,
like
biggest
recommendation
as
a
book
from
this
conference
right
it
talks
about
once
you've
got
your
platform
as
the
product.
How
do
you
offer
it
as
a
service
to
your
dev
teams
and
it
talks
about
stream,
align
teams,
sprint
teams,
scrum
teams,
that
kind
of
thing
how
they
interact
with
the
platform
best
practices,
all
these
kind
of
good
things.
B
B
My
case
study
here
is
ambassador
labs
right
we
drink
our
own
champagne
or,
as
them
jen
said.
I
showed
him
earlier.
It's
like
eating
your
own
dog
food.
There's
another
thing
right,
but
I
like
cats
too
much,
I'm
not
going
to
eat
dog
food,
so
we
drink
our
own
champagne,
drink
our
own
water,
ambassador,
labs
and
blog
posts.
You
can
check
out.
We
use
our
own
tools.
B
We
donated
the
cncf
emissary
ingress
used
to
be
ambassador
api
gateway.
We
donated
telepresence
to
the
cncf,
but
we
use
these
things
day
in
day
out
in
our
normal
dev
workflows,
for
offering
our
sas
product
staffed
appropriately.
We
have
dedicated
platform
teams,
we
look
at
it
as
a
product.
We
do
interviews
retros
when
things
go
wrong
when
things
go
right
as
well,
and
we
just
we
really
learn
and
think
about
that.
This
is
a
product
as
much
as
the
products
we
sell
to
everyone
else,
onboarding
and
training.
So
so
important
right.
B
You
can
have
the
most
amazing
platform
in
the
world
amazing
product.
Like
think
about
all
the
good
products
you
use
like
the
documentation's
good
or
the
products
so
intuitive.
You
don't
need
docs
right,
but
you've
got
to
get
people
onboarded
really
really
effectively,
and
we
really
focus
on
that.
We're
not
perfect
we're
trying
our
best,
so
you
can't
have
good
developer
experience
without
ux.
This
is
you
know.
Good
ux
is
the
next
one,
a
good
ux
platform,
so
any
designers
in
the
room
will
totally
be
rolling
their
eyes
again.
B
These
are
classic
books
right,
but
I
read
them
a
few
years
ago
and
they
really
helped
me
understand
about
building
for
specific
people
in
mind,
because
it's
very
tempting
as
platform
builders
we're
actually
not
building
for
ourselves
or
building
for
other
folks
right.
You
really
need
to
think
about
personas
platform
experts,
the
hipster
engineer,
I'm
sorry,
but
that's
pretty
much
all
of
you
right
if
you
come
to
a
conference
you're
pretty
much
a
hipster
right,
you're
learning
new
stuff,
but
there
is,
as
gene
yang
calls
it
a
fantastic
blog
post,
the
99
developer.
B
These
are
the
folks
I
mentioned
earlier
on.
These
are
most
of
the
work.
99
of
the
work
is
done
by
these
folks
right
they're,
not
at
conferences
they're
either.
You
know
too
busy
can't
convince
their
boss
to
come
along,
not
so
interested
whatever,
but
these
folks
are
doing
the
real
work
right
and
designing
for
them
is
very
different
than
designing
for
the
hipsters
us
at
kubecon
user
research
is
really
really
key,
so
go
out
into
your
life.
B
If
you're
a
platform
engineer,
if
you're
an
ops
person,
building
a
kubernetes
platform,
go
out
into
your
teams
and
ask
what
the
biggest
problem
is.
Honestly
as
a
consultant,
we
got
brought
into
so
many
platform
builds
that
were
going
wrong.
I
don't
mention
any
names,
but
in
london
and
straight
away
we
learned
to
ask:
have
you
chatted
to
the
development
teams
and
nine
times
out
of
ten
folks,
like
the
ops
team
were
like?
Why
would
I
do
that?
B
I'm
just
copying
amazon
or
I
know
what
developers
want
you
know,
but
if
you
don't
chat
to
your
customers,
the
developers,
how
are
you
going
to
solve
their
problems?
How
are
you
going
to
build
the
thing
for
them
and
do
watch
you
know
user
researchers
keep
it
watch
users
in
their
daily
tasks.
I've
been
shocked
right.
I've
done
a
lot
of
interviews
on
zoom
over
the
last
few
years,
with
users
using
telepresence
and
there's
some
very
standard
uses
of
telepresence
for
fast
feedback,
hot
reload
remote.
B
You
know
local
to
yeah,
sorry
remote
local
debugging
on
kubernetes,
but
then
I've
seen
some
folks
use
telepresence
in
ways.
I
could
never
imagine
right
and
they
because
it's
open
source
project,
they've
modified
it
in
different
ways,
and
I
you
know
I
was
horrified
a
few
times
right,
but
I
learned
a
bunch
of
stuff.
B
Sorry
now
for
my
use
case
for
this,
I'm
going
to
shout
out
the
argo
project,
the
folks
haven't
bumped
into
arg,
I
mean
other
cicd
or
other
cd
platforms
do
exist,
but
argo
really
put
a
lot
of
thought
into
the
ux
right.
There's
a
fantastic
ui
in
argo
cd.
I
do
a
lot
of
training
a
lot
of
teaching
and
they
see
a
life.
Argo
rollouts,
it's
just
fantastic
right.
It's
really
been
thought
about
from
a
user
experience
perspective.
B
I've
heard
like
the
folks
at
intuit
who
use
argo
and
contribute
a
lot.
Some
of
their
developers
just
use
the
ui
to
understand,
what's
going
on
in
the
cluster
at
a
service
at
a
deployment
at
a
pod
level.
Right
because
imagine
a
coupe
cuddle
get
pods
or
whatever.
It's
not
super
intuitive
folks
that
don't
like
the
cli,
that's
much
more
intuitive
right
and
for
us
I
love
the
cli.
I'm
sure
many
of
you
do
that's
fantastic,
there's
a
constant,
refreshing!
Cli.
Argo
really
thought
about
their
target
persona
developers
versus
ops.
B
I
think
there
workflow
and
interop.
Now
this
is
a
really
important
sort
of
section.
If
you
like
now,
I've
learned
a
bunch
of
the
netflix
folks,
I'm
very
lucky
with
qcon
conference.
I've
chatted
to
many
of
them
and
they
talk
about
full
cycle
developers
quite
a
lot
now.
This
is
a
developer
that
is
empowered
from
idea
to
delivering
value
and
getting
that
feedback.
B
Now
I
mentioned
earlier
full
stack,
you're
doing
potentially
all
the
things
right
now:
full
cycle
developers
they're
responsible
all
the
way,
but
they
have
clear
integration,
points,
clear
platform
components
available
to
them
to
make
their
job
easy.
It's
great
blog,
post.
The
standout
quote
for
me
is
the
centralized
platform
teams
act
as
force
multipliers
by
turning
their
specialized
knowledge
of
the
workflows
into
reusable
building
blocks.
I've
seen
this
right
in
a
couple
of
companies
and
it's
fantastic
right.
B
B
My
use
case
here
is
an
interop
example
between
two
cncf
projects:
emissary
ingress
and
linkid,
and
myself
and
jason.
I
think
yeah,
myself
and
jason
from
buoyant,
and
we
were
looking
to
put
together
a
cncf
webinar,
a
tai
joined
us
anyone's
on
twitter,
thai's
famous
on
twitter,
and
he
very
kindly
offered
to
host
us
and
jason,
and
I
were
you
know,
we're
playing
with
these
two
cncf
projects
right.
My
the
emissary
ingress
I
was
working
on
is
the
north
side
gateway
link
d,
east
west
service
mesh
we're
like?
B
Can
we
mash
these
up
to
get
an
end
to
end
tls
story?
End-To-End
transport
encryption
now
both
use
the
kubernetes
resource
model
right,
so
they
use
crds
controllers,
all
the
best
practices
baked
in
to
kubernetes,
and
we
looked
at
like
how
they'd
interrupt
and
actually
turned
out
to
be
a
one-line
bit
of
config,
and
I
can
tell
you
I'm
not
picking
on
any
other
service
meshes,
but
when
we've
integrated
emissary
ingress
with
other
service
meshes,
there's
a
few
more
lines
of
config
involved.
Shall
I
say
right-
and
you
know
this
is
really
interesting.
B
B
So
I
think,
there's
some
kind
of
need
for
a
platform
control
plane
emerging
right
as
we've
gone
through.
You
know
we're
pretty
much
agreeing
like
even
the
big
sort
of
category
sections
on
the
cncf
landscape.
We've
got.
You
know
our
dev
environment,
there's
continuous
deployment,
kubernetes
runtime
observability
and
they
map
pretty
much
to
code
to
ship
and
to
run
when
I
think
about
these
things
right
as
we're
building
up
this
slide.
B
B
Fantastic
quote
by
kelsey:
you,
like
any
kubernetes
talk.
You've
got
to
do
a
kelsey
like
quite
right
because
he's
on
point
so
much
of
the
time
and
when
I
first
read
this
tweet,
it
kind
of
stung
a
little
bit,
because
I
was
building
platforms
at
the
time
and
I
kind
of
thought
my
constraints
were
unique
and
my
requirements
were
unique
right
and
kelsey.
I'm
convinced
the
majority
of
people
managing
infrastructure
just
want
to
pass
platform
as
a
service,
the
only
requirement
it
has
to
be
built
by
them.
B
That's
a
little
subtle,
dig
right
and
I'm
like
yeah.
I
see
you
kelsey,
like
yeah
you're
kind
of
right
there.
That's
that's
kind
of
hitting
me
a
little
bit,
but
this
is
2017
right.
Two
years
later,
kelsey
came
and
said:
the
delta
between
kubernetes
and
a
developer-friendly
pass
is
where
the
next
layer
of
value
is
and
where
things
tend
to
get
opinionated
the
requirement
for
reliable
end-to-end
workflows.
B
This,
I
think,
is
the
golden
path,
golden
paths,
right,
reliable
workflows,
but
it's
a
delta
between
kubernetes
and
what
we
need
to
get
stuff
done
and
again
you
know
kelsey's.
So
on
point
with
these
things,
naming
is
hard.
I'm
not
saying
this
is
the
perfect
name,
but
I
think
this
is
where
we're
going
through.
You
know,
as
an
industry,
now
right
we're
going
for
these
golden
paths
so
building
the
golden
paths.
I
had
I
sort
of
put
together
this
thread.
I've
been
reading
about
platform
engineering.
I
was
like
how
do
we?
What
do
we
call?
B
Is
it
devops?
Is
it
sre
like
how
do
we
build
these
golden
paths?
I
put
this
tweet
out
there.
I
assembled
a
bunch
of
research
right
and
I
was,
as
I
was
learning
my
team
and
I,
and
it
just
blew
up
like
that,
is
my
most
famous
tweet.
I
think
right.
I
was
like
wow
people
like
this
stuff,
great
conversations.
B
B
B
I
see
you
know
anecdotally
right,
but
successful.
Orgs
are
investing
in
golden
paths
and
the
platform
teams
they're
staffing,
this
stuff,
this
project,
sorry.
Accordingly,
the
successful
orgs
are
starting
small
and
then
getting
big.
It's
developer-led
right,
bottom-up
motion,
as
we
call
it
again
the
projects
I
went
in
when
they
were
failing
very
much
top
down
the
cto
ceo
had
mandated
a
platform
bought
a
platform
sometimes
or
the
ops
team
thought
they
knew
best
and
were
mandating
top
down
honestly
didn't
work,
the
ones
which
did
sort
of
we
managed
to
recover.
B
B
There's
also
a
bit
of
an
internal
devrel
right,
so
my
career
has
gone
from
engineer
to
devrel
a
bit
of
marketing
involved
right
because
I
realized,
when
I
was
doing
entrepreneurial
stuff,
I
was
always
selling
whether
I
was
an
architect
whether
I
was
a
programmer.
I
was
always
selling
something
and
I
thought
I
want
to
learn
about
this
marketing
thing
and
you
have
to
communicate
the
long-term
vision
to
developers
to
get
them
to
buy
in.
Why
should
I
learn
this
thing?
You're
creating
oh
another
command
line
tool.
B
You
really
got
to
recognize
the
socio-technical
aspect
of
the
system.
We
all
love
our
tech,
myself
included
right.
I
was
like
docker
docker
docker.
When
it
came
out.
I
love
docker
right.
It's
fantastic
bit
of
tech,
love,
kubernetes
love!
You
know,
istio
all
the
things
right,
but
you
must
not
forget
the
human
aspect
we've
got
to
adopt
this,
and
I
learned
this
from
alan
barr
about
adjusting
a
hospitality
focus
to
get
folks
on
board
a
good
ui
paints.
A
thousand
clis
I've
learned
this
more
from
my
career.
B
I
was
you
know:
linux
user
loved
the
cli
migrated
eventually
to
mac.
No,
I
do
recognize,
particularly
in
bigger
organizations.
Uis
can
really
open
doors.
Some
developers
do
not
feel
comfortable
with
the
cli.
Don't
want
to
learn
the
cli.
I
respect
that
right,
they're
doing
their
job.
If
we
can
give
them
tools
to
help
them
do
their
job
they're
going
to
use
them.
B
I
do
like
to
see
you
like
that
right
and
the
key
thing
developers
we
need
to
help
them
eliminate,
toil
like
sometimes
you
know
when
you
say:
oh
that's.
How
do
we
fix
this
or
a
bit
more
kubernetes?
How
do
we
fix
that
or
a
bit
more
istio
how
to
fix
that?
A
bit
more
and
poor
developers,
like
my
god?
This
is
all
these
technologies
coming
on
top.
We
should
kind
of
hide
that
from
folks
right
they
just
want
to
get
their
job
done
so
automate
and
create
to
remove
friction.
B
That's
the
key
thinking
point
for
these
platforms
and
the
standards
for
me.
I'm
seeing
some
standards
emerge.
Apis
like
open
telemetry
is
a
good
example
in
the
api
space
right.
If
you
adopt
open
telemetry,
you
can
swap
out
your
metrics
back
end
as
you
scale.
It's
a
good
investment
cncf
doing
great
work
in
this
space
love
some
git
ops,
not
for
everyone,
but
I
really
like
that
standard
as
a
best
practice
how
to
deliver
software
and
kubernetes
and
the
kubernetes
resource
model.
B
If
you're
building
tools
look
at
what's
out
there
in
kubernetes
land,
look
at
you
know:
operators,
look
at
coop,
cuttle
plug-ins,
don't
fight
against
the
grain.
I
saw
this
all
throughout
my
career,
where
folks
would
fight
against
the
grain
of
where
a
platform
was
going
adopt
the
kubernetes
resource
model.
You
get
the
biggest
interrupt
there
for
your
fellow
developers.
B
Now
I
might
be
dating
myself
with
the
next
meme
a
little
bit,
but
you've
hopefully
spotted
as
I'm
going
through
here
and
throughout
the
presentation.
I'm
talking
a
lot
about
developers,
yeah
hardcore
old-school
meme,
but
it's
because
I've
been
coming
to
coupon.
I
was
literally
the
first
one
that
ran
in
london.
I
helped
out
at
coming
to
kubecon
for
so
long
and
I'm
seeing
the
pivot
towards
developers,
but
it's
been
very
much
an
ops
conference.
I
think
up
until
you
know
recently,
but
we've
really
got
to
think
about
our
target
users.
B
Our
target
customers
yeah,
you
may
be
developers,
that's
great
work
with
the
ops
folks
to
help
them
understand
where
you're
coming
from,
but
this
focus
on
developers
is
really
really
important.
We
are
building
a
platform
shiny
technology,
but
the
goal
is
to
help
developers.
You
know
code
ship
and
run
so
we
come
back
to
this
slide
right
there.
We
need
this
need
for
the
platform
control
plane.
Now
I
think
it's
really
a
developer
control
plane.
That's
the
most
important
thing
right.
B
B
You
know,
collection
of
folks
of
technologies
and
what
I
think
is
we're
going
to
see
a
lot
of
work
in
this
space
right,
we're
seeing
things
like
backstage
right
as
a
custom.
Ui
we're
seeing
lots
of
you
know:
interactions
integrations
in
the
api
space.
Many
vendors
are
merging,
which
is
always
a
good
site.
Baster
labs,
humanitech
other
folks
right,
there's
lots
of
interesting
stuff
going
on
here,
but
you'll
notice.
It's
the
ui,
it's
the
integration
points
and
it
touches
in
to
the
actual
tooling
for
the
code,
the
ship
and
the
run.
B
This
is
where
I
think,
if
you're
getting
into
platform
engineering
getting
into
ops,
spend
some
time
in
investing
in
this
space.
This
is
where
we're
struggling
at
the
moment.
You
know
I
would
recommend,
having
a
look
at
this
space
cool,
so
wrapping
up
I'm
pretty
much
onto
time
there.
I
think
so
from
kubernetes
to
past
golden
paths
right
when
creating
a
golden
path.
How
much
should
you
build
yourself
and
how
should
you
assemble
the
control
plane
for
effective
use
by
developers
are
really
the
key
questions.
B
I
think
asking
you
should
be
asking
treat
your
platform
as
a
product
realize
you
can't
have
good
developer
experience
without
good
user
experience
and
focus
on
the
workflows
and
the
tooling
interop
right.
This
has
got
to
be
developer.
Led
a
developer
led
control
plane.
I
wouldn't
mandate
top
down.
These
are
my
key
takeaways
right
and
just
a
final
tweet
I'll
I'll
leave
you
with.
B
I
was
that
oh
well,
almost
read
it.
I
was
at
dockercon
last
week,
fantastic
docker,
doing
amazing
work
at
the
moment.
Docker
extensions,
rolling
out
lots
of
great
stuff,
but
the
really
great
conversation
for
me
was
between
scott
johnson,
ceo,
there
and
kelsey
hightower
mentioned
before,
and
kelsey
dropped.
My
drop
moment
right.
He
was
like
you,
don't
want
a
10x
developer,
we're
talking
about
10x
developers.
B
What
you
want
is
someone
that
can
come
in
and
make
10
other
developers
more
productive,
and
I
was
like,
oh
that
yeah
that
that
kind
of
hit
right-
and
that
is
the
role
of
the
platform
engineer-
it's
not
actually
another
developer,
necessarily
right.
It's
the
role,
the
platform
engineer,
making
10
other
folks
pick
a
number
more
productive,
because
we're
all
sort
of
singing
the
10x
engineer
is
a
bit
toxic
right.
You
don't
really
want
one
that
going
on,
but
I
thought
this
was
a
really
really
good
point.
B
I'll
leave
you
with
that.
To
think
with
do
feel
free
to
connect
with
me
right,
I'm
on
twitter
on
linkedin
and
hit
me
up
on
the
best
of
life.
Slack
we've
got
a
booth.
We
are
not
a
pizza
vendor
this
morning.
Everyone's
coming
to
me
saying:
we've
got
too
many
big
graphics
of
pizzas,
we're
not
pizza
vendor.
We
do
help.
Kubernetes
solutions
come
and
chat
to
me
and
the
team
there
there's
a
bunch
of
resources
I
put
up
for
you
there,
our
golden
path,
pizza
party
platform,
engineering
guide.
B
C
Thanks
seeing
as
you've
done,
some
consultancy
work
and
you've
come
into
companies
to
try
and
help
them
fix
this.
You
didn't
obviously
just
have
to
convince
engineers
about
what
to
do.
You
also
have
to
convince
like
management
right,
yeah
yeah.
What
strategies
do
you
have
for
convincing,
but
maybe
non-tech-savvy
managers
about
why
golden
paths
are
important.
B
B
Sometimes
it's
very
much
not
what
we
think
as
engineers
some
companies
you're
rewarded
for
growing
your
organization,
your
reward
for
growing
your
fiefdom.
Shall
we
call
it
right
and
therefore,
if
I
say
I'm
going
to
help
you
with
deaf
productivity
they're
like
that's,
not
good
for
me
right,
I
lose
my
engineers
or
I
can't
get
my
hiring
rec
for
next
year.
I'm
not
gonna
get
promoted
bad
luck.
You
have
to
really
like
it's
the
five
wise
thing
right
really
dive
into.
What's
your
motivation,
why
why
why?
B
And
then
you
usually
get
the
actual
motivation
once
you've
got
that,
then
it
start
trying
to
adapt
to
that
motivation
and
I'll.
So
I'm
on
camera
I'll,
be
careful.
I
say
I
guess,
but
it's
a
bit
tricky,
because
sometimes
the
folks
that
hire
you
in
to
fix
stuff
are
actually
the
problem
right.
They
think
it's
just
developers
need
to
go
faster.
Ops
need
to
produce
a
different
platform
and
actually
it's
how
you're
leading
the
organization
it's
how
you're
defining
the
incentives,
how
you're
setting
the
mission
of
the
strategy
right.