►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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 Developer Control Planes- Daniel Bryant, Ambassador Labs
Developers building applications on Kubernetes today are being asked to not just develop applications -- they are also responsible for releasing and running their applications, too. In this talk, we’ll discuss the secular shift towards what Netflix calls “Full Cycle Development” or what Google calls “Service Ownership”. With developers managing so much of the cloud-native development loop, a new class of infrastructure has emerged -- the developer control plane. We’ll explore the evolution from Kubernetes to PaaS, to the developer control planes in use today. We’ll draw on our personal experiences and podcast chats with the larger CNCF community, and discuss real-world examples of developer control planes used at New Relic, Spotify, InVision, and Twitter. 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
Hello,
everyone
and
welcome
to
from
kubernetes
to
pass
to
developer
control
planes.
My
name
is
daniel
bryant,
I'm
the
director
of
devrel
at
ambassador
labs,
and
you
can
find
me
on
mostly
interwebs
at
daniel
bryant
uk.
Now
I'm
going
to
discuss
over
the
next
20
minutes.
These
high
level
key
points,
I
believe,
as
a
cloud
native
community
as
a
devex
days
community.
We
need
to
focus
more
on
treating
our
platforms
that
we
deploy
applications
onto
as
a
product.
A
I'm
going
to
argue,
we
should
realize
that
you
can't
have
good
devex
without
good
ux
and
when
I
say
good
ux,
I
mean
proper
ux,
not
just
like
back
end
engineer,
ux
that
I
typically
do
proper
ux
and
we
need
to
focus
on
the
workflows
and
the
tooling
interoperability,
and
this
is
where
this
notion
of
developer
control
planes
will
come
into
their
focus
more
clearly
now
we're
being
told
increasingly
to
shift
left
as
developers
right
now.
This
is
not
a
new
thing.
A
I
started
my
career
in
java
development,
javascript
development
back
in
2001,
2002
time
frame,
and
we
were
being
asked
then
to
think
about
the
ilities
early
on
in
the
process.
We
used
to
call
them
non-functional
requirements,
not
a
great
name
right.
Really,
it's
cross-functional
requirements.
It's
things
like
reliability,
scalability
security,
all
this
good
stuff
right,
the
challenge
was
back.
Then
there
wasn't
great
abstractions.
There
wasn't
great
apis.
There
wasn't
great
tooling
to
help
us,
and
this
led
to
fragmentation.
You
know
devs
doing
this.
A
This
thing,
ops
doing
just
this
thing,
infosec
doing
just
this
thing
and
it
kind
of
meant
for
a
lot
of
handoffs
and
a
lot
of
models,
all
the
good
stuff
you've
heard
in
books
like
accelerate
devops
handbook.
These
are
real
challenges
back
in
the
day.
Right
now,
I
think
we've
got
a
lot
more
options.
You
know
massive
hat
tip
here.
There's
cncf,
there's
lots
of
projects
out
there.
Now
the
only
challenge
is
almost
gone.
The
other
way
and
the
tool
sprawl
is
an
issue
for
shifting
left.
A
We
all
know
the
value
of
thinking
about
security
early,
but
there's
lots
of
different
tools.
We
all
know
the
value
of
thinking
about
deployability
reliability
early,
but
again,
there's
lots
of
tools
and
it's
easy
to
poke
fun
right
at
the
cncf
landscape.
We
all
like
to
do
a
cheap
shot
of
kubecon
right.
Let's
be
honest,
though
this
is
a
sign
of
a
healthy
community
lots
of
divergence,
lots
of
innovation
going
on
it
does
mean
it's
challenging
for
us
to
pick
which
tools
are
going.
A
You
know
are
going
to
be
useful
to
us,
but
it's
still
a
sign
of
a
healthy
community.
The
only
slight
snag
with
you
know,
kubecons,
and
I
am
missing
not
being
there
in
person
in
kubecon,
hopefully
soon
right,
but
each
kubecon
doesn't
help
with
this
tool.
Sprawl
and
ceo
of
ambassador
labs
richard,
and
I
regularly
joke
on
this
kind
of
thing
that
every
kukon
brings
innovation
brings
conversations
brings
discussions
brings
more
tools
and
tools
are
somewhat
like
tribbles
in
the
star
trek,
unifor
universe
right.
A
So
let's
take
a
step
back
for
a
moment.
Look
at
my
career
and
the
control
planes.
I
was
used
to
using
as
a
developer
how
my
cognitive
load
varied
over
time
and
how
difficult
I
found
the
job.
Basically,
I
think
this
relates
very
much
to
the
developer.
Experience
that
I
had
available
to
me
at
the
time.
A
So,
looking
back
at
my
dev
career
and
apologies
for
a
bit
of
a
data
dump
table,
this
is
the
best
way
I
could
find
to
animate
it,
but
very
briefly
I'll
step
through
in
the
early
2000s.
I
was
working
on
java,
monoliths
deploying
in-house
actually
for
the
uk
government
when
I
was
working
there
for
a
bit,
and
I
just
thought
about
coding
right
2005
time,
I
was
doing
more
enterprise
kind
of
development,
classic
soa
service,
oriented
architecture
moved
into
racking
and
stacking
some
of
the
tin.
There
was
even
cloud
emerging
around
this
time
right.
A
Amazon,
with
aws
with
sqs
and
s3
were
popping
up
on
the
scene,
and
I
was
excited
by
this.
I
started
learning
more,
not
only
about
coding,
but
about
shipping
and
even
limited
degrees
of
running
applications.
How
to
pixie
boot
servers
how
to
use
chef
to
deploy.
You
know
java,
the
jvm
on
the
machines
and
our
2010
time.
I
actually
went
and
did
a
bunch
of
work
in
ruby
and
rails
heroku
doing
some
java
work
on
cloud
foundry,
and
this
was
a
very
different
experience
proper.
You
know
classic
platform
as
a
service.
A
A
Maybe
you
can
look
at
the
logs
if
something
was
going
wrong,
but
as
a
developer,
I
didn't
think
too
much
about
the
the
ci
cd
aspect
of
what
I
was
doing.
Marx's
services
came
along
right,
2012,
which
time
pick
a
date
and
but
then
new
options
were
available
to
us.
Modularizing
our
architecture,
designing
for
replaceability
docker
popped
up,
kubernetes
popped
up
suddenly,
as
a
developer.
You
know
I
was
working
as
a
consultant
in
london.
A
There
was
suddenly
a
lot
of
things
to
learn
as
a
full
stack
engineer,
everything
from
new
languages
all
the
way
through
to
databases
to
queues
and
distributed
logs
to
terraform
to
chef
to
puppet.
You
know,
there's
a
lot
of
things
to
learn
as
a
developer
and
in
2020
now
we've
sort
of
come
full
circle.
You
know
micro
services
plus
plus
we're
looking
for
that
path.
Like
experience
once
again,
kubernetes
is
the
foundation,
but
maybe
we're
missing
that
sort
of
top
layer
to
make
it
easier
for
developers
to
provide
that
good
developer
experience.
A
Right
and
again,
I
think
a
lot
of
engineers
now
would
recognize
themselves
as
full
lifecycle
developers
we'll
cover
that
a
bit
more
in
a
minute,
but
you
are
responsible,
for
you
know,
taking
the
business
ideas,
coding
them,
shipping
them
and
running
them
as
well.
You
know
you
build
it,
you
run
it
verdenvergles
famously
said.
I
see
this
in
many
organizations
we
work
with
ambassador
labs.
A
Now,
if
I'm
going
to
map
on
my
cognitive
load
over
the
years
as
a
developer,
it's
an
interesting
graph.
I
think
right
you
can
see
in
my
early
years.
You
know
I
was
obviously
learning
a
lot
fresh
out
of
college
fresh
out
of
university,
but
it
was
pretty
happy
right.
I've
created
my
java,
app
packaged
it
in
a
jar
or
a
war.
Artifact
put
it
into
a
portal
or
handed
it
off
to
ops,
and
you
know
stuff
happened
right
happy
days
as
I
got
into
more
soa,
I
was
spinning
up
tin.
A
I
was
racking
and
stacking,
but
even
if
I
didn't
want
to
go
that
deep
in
the
infra,
I
kind
of
enjoyed
it,
but
even
I
didn't
want
to
go
that
deep.
I
was
still
having
to
think
about
things
like
application,
service,
enterprise,
service,
buses,
more
kind
of
infrastructure,
kind
of
components,
and
I
was
like
you
know.
This
is
kind
of
a
lot
more
complicated
right
going
to
the
world
of
heroku
and
clyde.
Foundry
was
a
breath
of
fresh
air
right.
You
know
so
much
simpler
as
a
developer
focus
more
on
my
code
more
on.
A
A
This
is
when
I
think
you
know
the
cognitive
load
just
shot
through
the
roof
granted.
I
didn't
have
to
learn
all
the
tools,
but
the
consultancy
I
was
working
with
at
the
time
was
a
fantastic
team,
open
credo
I'll
shout
them
out.
We
were
deliberately
going
in
and
helping
folks
embrace
new
technologies,
so
we're
having
to
learn
all
these
new
things,
but
yeah
again
as
a
full
stack
developer.
A
A
So
what
did
I
learn
through
my
time?
You
know
my
20
year
journey
in
it
treating
platform
as
a
product
is
key.
Now
I
saw
this
obviously
in
heroku
I
saw
this
in
cloud
foundry,
the
folks
behind
those
platforms
clearly
invested
in
things
like
ux
product
management,
project
management,
all
this
good
stuff
and
even
companies.
I
worked
at
and
I'll
shout
out,
not
on
the
high
street
uk
online
marketplace
myself
and
nick
jackson.
A
bunch
of
other
awesome
folks
worked
there
and
built
a
platform
on
mesos
at
the
time.
A
We
really
thought
about
our
platform
as
a
product,
and
it
really
showed
in
terms
of
adoption
and
user
experience.
It
wasn't
perfect,
but
it
was
a
lot
better
than
other
places.
I've
worked
where
the
platform
was
an
afterthought,
or
it
was
just
ops
responsible
for
it,
and
developers
had
to
put
up
with
what
we
were
given.
A
I
also
learned
you
can't
have
good
devex
without
good
ux
right
I
mean
twitter.
Bootstrap
was
a
miracle
at
the
time.
Right
me
as
a
back-end
engineer,
when
twitter
bootstrap
came
on
as
a
ux
tool
as
a
kind
of
css
collection
on
javascript,
and
things
made,
my
life
designing,
uis
much
easier,
but
still
I
I
was
a
back-end
developer
right.
I
wasn't
a
good
user
experience
developer.
A
I
worked
with
some
amazing
ux
folks
and
I
really
dialed
into
the
value
of
ux
and
again
we're
treating
the
platform
like
a
product.
Good
devex
requires
good
ux
and
I
learned
to
focus
on
the
workflows
and,
I
think,
hashicorp,
to
be
honest,
like
michelangelo
and
the
whole
team,
I've
been
very
lucky
to
see
their
journey
right
from
day
zero.
Pretty
much.
They
really
taught
me
this.
You
know
when
I
first
bumped
into
terraform
as
an
example,
I
was
a
bit
confused.
A
You
know
different
stanzas
different
configs
for
different
clouds,
where's
the
value,
but
I
soon
learned
the
magic
was
in
the
workflow,
the
terraform
plan,
the
terraform
apply
the
general
modular
structure
that
emerged
over
the
time.
It's
like
consistent
workflow
is
the
key
here,
there's
only
a
little
bit
of
extra
cognitive
load
to
learn
the
different
conflicts.
A
A
There's
always
a
kelsey
hightower
tweet
for
any
occasion
in
kubernetes
right
and
because
he's
he's
awesome
basically
and
this
tweet,
I
thought
was
perfectly
relating
to
what
we're
just
discussing
now.
This
is
you
know
it's
a
couple
of
years
old
this
tweet
now,
but
kelsey
was
saying
the
delta
between
kubernetes
and
a
developer
friendly
pass
is
where
the
next
layer
of
value
is
and
where
things
are
tend
to
get
opinionated.
A
I
require
a
requirement
for
reliable,
end-to-end
workflows
and
I
think
we
still,
even
though
this
is
like
a
2019
tweet,
we
still
haven't
really
got
that
developer
friendly
pass.
Yet
some
folks
are
clearly
on
the
path
trying
both
internally
and
as
a
product,
but
I
think
this
tweet
captures
what
I'm
trying
to
say
today,
like
thinking
about
the
platforms
as
products
as
passes
that
we
all
want.
A
So,
let's
look
at
the
three
things
I
mentioned
platform
as
a
product.
Now
learns
a
lot
from
dave
studio
over
the
years.
Dave's
awesome
he's
done
various
cto
roles,
he's
keynoted
at
cubecon
in
the
past,
and
I
know
there's
a
lot
of
text
on
this
slide.
But
I'll
just
paraphrase
by
saying
I
had
some
great
chats
with
dave
at
previous
coupe
cons
and
he
came
up
to
the
ambassador
labs
booth,
one
time
and
said
you
know
fantastic
talk
by
pinterest.
A
A
I
always
say
start
small,
get
big
right
and
I've
definitely
worked
on
a
few
projects,
kind
of
as
a
consultant.
We're
brought
in
to
try
and
save
the
projects,
and
these
are
platform
projects
in
big
companies.
I
won't
share
any
names,
but
we'd
often
join
the
project
and
I'd
realize
there's
been
no
iteration
the
platform
folks
building
the
platform
would
not
even
talk
to
the
developers.
Chaos
ensued
right,
so
this
book
is
a
great
reference
for
how
to
start
small
iterate
learn
get
big.
A
Just
almost
great
timing.
Right,
nikki
I've
learned
a
lot
from
nikki
over
here,
sticky,
writes
and
ft.com
skyscanner
recently,
and
she
was
saying
she
quote:
tweeted
a
really
interesting
thread
about
building
platforms,
and
then
she
was
arguing.
I
strongly
believe
that
companies
need
to
invest
heavily
in
platforms
and
the
platforms
need
to
be
staffed,
properly
treated
as
products
right
and
again.
Folks,
like
nikki
and
gagley
here,
are
talking
about
this
dave
other
folks
right.
There's
smart
people
talking
about
interesting
things,
I'm
always
interested,
I
think
treating
platforms
as
products
is
really
really
key
staffing
them.
A
Accordingly,
setting
goals
iterating
accordingly,
point
number
two:
you
can't
have
good
devex
without
good
ux
right
now,
shout
out
to
the
argo
project.
I've
been
lucky
enough
to
play
around
with
argo
for
a
couple
of
years.
Now
argo
is
growing
all
the
time
as
many
things,
but
in
particular
argo
cd
is
a
fantastic
ui
for
understanding
your
current
deployment
state
in
kubernetes
and
embracing
git
ops
to
deploy
things
you
know
to
finding
git
reconciled
into
kubernetes.
A
I've
been
lucky
enough
to
chat
to
many
of
the
intuit
folks,
the
black
rock
folks,
the
red
hat
folks
behind
argo
did
a
great
podcast
with
alex
m
on
the
argo
project.
So
I'll
put
the
links
down
there,
you
can
check
out
and
alex
really
helped
me
understand
about
the
value
of
the
ui
of
argo.
You
know
almost
put
aside
the
github's
benefits.
Put
aside,
some
of
these
other
benefits
that
he
said.
The
ui
is
really
useful
in
big
enterprises
for
helping
them
build
their
mental
model
of
of
how
deployments
work.
A
What
is
a
node,
what's
deployed
where,
when
we're
doing
canaries
rolling
upgrades,
what's
going
on,
it's
a
great
tool
to
help
developers
build
their
mental
model,
and
that
is
key
in
devex
following
on
from
this,
you
know
not
just
ui
right.
The
cli
of
argo
rollouts
is
fantastic.
I
constantly
use
this
in
my
demos
right.
It's
like
a
watch
command
as
the
canaries
are
going
out,
you
see
new
pods,
spinning
up,
you
see
traffic
being
rerouted
and
you
see
pods
being
spun
down
when
the
canary's
successful
and
the
ux
of
it
is
just
fantastic
right.
A
It's
a
cli
tool,
but
it's
fantastic
people
have
clearly
put
time
and
energy
and
iterated
on
this
user
experience
this
great
developer
experience
so
good
ux
for
platforms.
I
bumped
into
this
book
quite
a
few
years
ago.
Now
it's
a
great
read:
it's
a
chunky,
read
in
some
ways,
but
it
talks
about
affordances
personas,
a
bunch
of
things.
I
really
use
I've,
helped
teams
build
platforms.
Now,
the
classic,
of
course,
steve
krug,
don't
make
me
think
we
still
discuss
this
in
ambassador
labs
quite
a
bit.
A
It's
a
great
book
again
for
thinking
about
personas
and
many
of
the
good
ux
things
that
perhaps
we
as
back
engineers,
back-end
engineers,
don't
always
think
about
so
do
think.
Personas
user
research
is
key.
Can't
reiterate
that
one
enough
too
many
times
as
a
consultant
brought
in
to
save
a
platform
build,
and
then
you
know
as
soon
as
I
ask
the
question
like
what
do
your
developers
actually
want
from
the
platform?
A
And
if
the
lead
engineer
on
the
platform
team
said,
oh,
we
haven't
talked
to
the
developers
or
we're
going
to
give
them
what
what
they
need.
I
was
like
uh-oh,
this
project's,
probably
doomed.
If
you're
not
listening
to
your
customers,
your
users
you're
never
going
to
deliver
value
for
them.
It
will
simply
get
sidelined
or
people
will
work
around
it
and
do
watch
your
users
in
their
daily
tasks.
Using
your
tools,
constant
surprises,
ambassador
labs
people.
A
You
know
going
through
and
using
our
tools
in
ways
we
never
thought
possible
and
things
that
we
thought
were
simple
and
obvious
and
not
to
them,
and
vice
versa.
So
actually
watching
people
jumping
on
a
zoom
in
our
case-
and
you
know
asking
folks
to
step
through
quick,
starts
and
tutorials
look
at
tele
presence.
Look
at
emissary
ingress.
We
learn
so
much
from
doing
that
and
we're
humbled
all
the
time
right.
So
I
thoroughly,
you
know,
encourage
you
to
think
about
developer
experience
by
actually
watching
some
developers
experience
your
tools,
workflows
and
interops.
A
So
this
is
an
interesting
one
right.
I've
learned
a
lot
from
the
netflix
folks
over
the
last
few
years
on
this
and
yep.
I
know
we're
not
all
netflix
right
but
they're,
often
at
the
vanguard,
they're,
often
leading
the
way
I
like
to
look
at
what
they're
doing
sort
of
in
a
few
years
time.
The
rest
of
us
might
be
following
suit
right
and
they
talk
a
lot
about
this.
A
You've
got
to
balance
that
devex
with
you
know:
flexibility
of
platform,
governance,
security,
these
kind
of
things,
but
it's
a
great
discussion
of
thinking
about
all
these
trade-offs.
We
as
platform
engineers
we
as
developers
right.
We
want
to
think
about
when
we're
building
and
using
platforms,
and
I've
got
a
quote
svp
of
engineering
at
ambassador
labs.
I
had
some
great
chats
at
bjorn
over
the
years
and
we
did
a
podcast
recently
and
he
pulled
out
this
really
key
thinking.
Point
for
me:
he's
seen
many
things
in
his
time.
A
A
I
want
to
pull
out
that
they
all
seem
to
mention
now,
cheryl
kind
of
in
in
looking
at
the
developer
experience
of
cloud
native,
she
talked
a
lot
about
the
value
of
having
service
catalogs
having
a
good
ui,
and
she
mentioned
spotify's
backstage,
which
we've
many
of
us
have
heard
of
I'm
sure
mario
talked
about
enabling
self-service
for
developers
being
opinionated,
but
you
know
allowing
them
to
break
out
if
necessary,
but
that
self-service
is
key
and
casper
talked
about
things.
Thinking
around
the
mechanics,
the
workflow
kubernetes
is
almost
a
given.
A
He
was
saying
it's
the
next
layer
up
of
managing
promotion
of
code
through
environments,
implementing
git
ops,
in
a
way
that
developers
can
understand
and
manage
these
kind
of
things.
So
I
put
links
there
all
these
links
go
into
the
podcast
more
details.
I've
learned
a
bunch
of
these
folks,
so
thank
you
very
much
to
them
to
help
build
my
knowledge.
A
Successful
organizations
are
investing
in
platforms
and
platform
teams,
yaml
pretty
much
the
lingua
franca
of
cloud
config,
although
I
think
we're
seeing
more
and
more
auto
generation
for
yaml
now
something
we're
looking
into
a
lot
of
ambassador
laps,
because
yaml
is
rather
verbose
to
keep
constantly
writing
yourself
right,
I'm
going
to
say
a
good
ui
paints,
a
thousand
clis.
You
know,
I'm
not
saying
don't,
show
the
cli
any
love
right,
I'm
a
big
cli
user,
but
particularly
in
large
enterprise
context,
a
really
good
user
experience,
a
really
good
portable
dashboard
service.
A
Catalog
takes
you
a
long
way
in
terms
of
developer
experience.
Some
folks
are
just
simply
happier
in
the
ui
gitops
is
sort
of
becoming.
I
think
the
protocol,
the
standard
workflow
best
practice
for
deployment,
the
reconciliation
mode,
massive
hack
tip,
of
course,
to
the
weave
works
folks
for
all
the
great
work
they're
doing.
Cornelia
davis
has
done
some
great
presentations
talking
about
this
reconcile
loop.
That
you
know
is
in
kubernetes
and
then
gitops
builds
on,
and
so
this,
I
think,
is,
is
key
to
a
lot
of
future
devex.
A
This
notion
of
git
ops
for
deployment
and,
lastly,
adopting
the
kubernetes
resource
model
enables
interop
using
things
like
custom
resources,
defining
your
own
customer
resources
and
treating
the
entities
within
kubernetes
as
they
should
be
used
just
the
other
day.
Jason
morgan
from
buoyant
tonight
we're
doing
a
demo
of
integrating
two
cncf
projects,
link
d
and
emissary
ingress,
and
because
both
the
projects
treated
all
the
kubernetes
entities,
as
you
think
they
would
like
emissary
ingress
routes.
The
services
link
the
augment
services.
A
It
was
literally
a
one-line
piece
of
config
to
get
the
tools
working
well
together,
whereas
in
the
past
there's
been,
you
know
when
we've
used
different
service
meshes
or
different
ingresses
there's
been
a
lot
more
config
needed
to
work
around
different
ways.
Things
were
using
kubernetes
or
or
not
using
kubernetes
is
the
case.
I'm
not
saying
that's,
not
so
bad,
but
it
wasn't
a
great
developer
experience
when
you
had
to
kind
of
do
all
these
patches
and
work
work
workarounds.
It's
sometimes
provided
more
flexibility,
but
it's
always
a
trade-off
right.
A
Good
developer
experience,
easy
integration
versus
that
more
power,
so
this,
I
think,
in
summary,
is
the
role
of
the
developer
control
plane
right.
I've
talked
about
coding,
shipping
running,
I
think
you
know
we
ops
have
had
their
control
planes
for
a
long
time.
I
think
it's
now
time
when
we
need
this
developer
control
plane,
probably
a
thin
ui
on
top
service
catalog
that
kind
of
thing
some
kind
of
protocol
mechanism.
I
talked
about
git,
ops
being
that
I
think
git
is
pretty
much
like
being
accepted
as
the
single
source
of
truth.
A
Now,
regardless
of
whether
we're
in
the
coding
stage,
the
shipping
stage
or
the
run
stage
right,
you
think
code
is
obvious
in
git
ship,
you
know:
junior
argo
cd,
your
argo
rollouts
all
in
config
in
git
and
even
run
defining
mappings
to
your
backend
services
via
ingress
or
service
mesh.
That's
all
crds
right.
That's
all
code
config
stored
in
git
triggered
through
with
git
ops
to
actually
being
deployed.
A
So
I
think
this
developer
control
plan
is
a
powerful
concept.
It's
similar
to
things
like
you
know,
open
application
model
are
probably
worth
exploring
or
definitely
worth
exploring
two.
If
you
sort
of
squint
there's
a
little
bit
of
the
developer
control
plane
here,
I
think
many
of
us
are
converging
to
this
kind
of
model.
If
you
like
of
how
and
developers
should
interact
with
platforms
so
wrapping
up
what's
next
for
platforms,
I
think
we,
as
you
know,
devex
days
community
as
a
cloud
native
community
really
need
to
think
about
treating
platforms
as
a
product.
A
This
is
exactly
what
I
said
at
the
start,
but
if
you
resource
them
set
the
goals
accordingly,
iterate
on
them
platforms.
This
built
this
way
provide
so
much
more
value.
Minimize
the
friction
provide
better
developer
experience
and
you
do
have
to
realize
that
you
can't
have
good
developer
experience
without
good
user
experience
right,
good
ux.
A
I
learned
that
the
hard
way
you
know
don't
learn
my
mistakes,
don't
follow
my
mistakes
and
invest
in
getting
expert
opinion
on
user
experience,
engage
with
your
target
users,
your
your
key
personas
and,
I
think,
focus
on
the
workflows
and
the
tooling
interoperability.
This
is
where
you
know
a
lot
of
interesting
thinking
around
developer
control
planes
at
the
moment
how
things
interrupt
this,
I
think,
is
going
to
be
an
air
of
active
research,
active
products
and
consolidation
of
things
over
the
next
few
few
years.
A
I'll
say.
Thank
you
at
that
point.
You
can
find
me
on
the
interwebs
here:
email
twitter.
Also
on
the
ambassador
slack,
you
can
find
the
references
in
the
podcast
I
mentioned
down
below
and,
of
course,
I've
got
to
mention
we're
hiring
right.
If
you
like
what
you've
seen
today,
please
come
and
join
me
thanks.
A
lot.