►
From YouTube: Keynote: More Power, Less Pain: Building an Internal Platform with CNCF Tools - David Sudia
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.
Keynote: More Power, Less Pain: Building an Internal Platform with CNCF Tools - David Sudia, Senior DevOps Engineer, GoSpotCheck, Inc.
Last year GoSpotCheck migrated from a PaaS to Kubernetes, and devs asked "Does it have to be this hard?" The engineering organization's major initiative this year was to be able to say "no," by building an internal Platform-as-a-Service...with no platform team. And keeping to a goal of using as many open-source and CNCF technologies as possible. Learn how GoSpotCheck used and put together tooling around Buildpacks, Helm, OpenTelemetry, Prometheus, Envoy, LinkerD and gRPC to make a much smoother experience for developers, from "local" development (which now happens in the cluster) through the first SLO alert. Also learn guidelines about where to make the strategic trade-off of what to do in-house and when to go with a vendor. Most of all, learn how to make a pleasant user experience for developers with Cloud Native tech.
https://sched.co/eoFV
A
Hi,
this
is
more
power,
less
pain,
building,
an
internal
platform
with
cncf
tools,
and
I
am
nervous.
My
name
is
dave
studio
though-
and
this
is
actually
a
sequel
to
a
talk.
I
gave
last
year
called
balancing
power
and
pain
which
I
gave
with
tony
rib,
and
it
was
about
moving
a
single
application
from
a
platform
as
a
service
over
into
kubernetes,
and
when
we
finished
that
talk,
a
bunch
of
people
came
saying.
Oh
so
he
built
a
platform
to
deploy
apps,
and
we
said
no,
we,
no,
we,
we,
we
moved
an
app.
A
The
platform's
coming
come
talk
to
us
next
year,
so
this
is
next
year.
Who
am
I
I'm
a
senior
devops
engineer?
I
build
clusters
and
deploy
databases
and
write
utility
applications,
and
I
help
with
architecture,
and
this
year
I've
been
leading
the
effort
to
make
a
more
develo
developer
friendly
platform
in
inside
of
our
company,
and
that
was
prompted
by
one
of
our
lead
developers
at
a
hackathon
last
winter.
A
Coming
up
and
saying,
I
don't
really
know
what
my
project's
going
to
be
other
than
figuring
out,
why
this
is
also
hard
and
how
to
make
it?
Not
so
hard,
so
that
was
a
catalyst
for
saying,
okay,
we
can
operate
now,
but
it's
not
pleasant.
We
need
to
work
on
the
developer
experience
and
make
this
better.
A
I
work
for
a
company
called,
go
spot
check,
it's
a
field
execution
app
where
you
have
sort
of
have
data
collection
missions
that
you
fill
out
on
a
mobile
application
that
go
back
for
near
real
time,
sort
of
business,
intelligence
analysis
we
as
just
for
context
on
our
size.
We've
got
about
40
engineers
and
qa
folks,
and
we
started
as
a
rails
monolith
and
we've
sort
of
branched
out
in
the
last
couple
of
years
to
go.
Microservices
and
node-based
cloud
functions,
we
run
postgres
and
couch
and
kafka.
A
A
A
We
figure
we're
gonna
go
to
a
place
where
we
we
have
a
lot
of
surrounding
tools
that
are
gonna
fill
the
the
gaps
of
utility
that
we
need,
maybe
not
right
now,
but
but
soon
or
in
the
future,
as
well
as
now,
and
we
figured
that
it
would
be
a
long-term
bet
to
to
pay
off
in
terms
of
interoperability
and
efficiency,
and
I
do
think
it
is
paying
off.
But
there
was
struggle
going
from.
You
know
a
monolith
on
an
all-in-one
platform
with
one
or
two
teams
that
were
very
close
to
lots
of
teams.
A
Working
on
lots
of
services
in
a
distributed
environment
with
open
source
tooling
has
has
been
difficult,
and
the
best
metaphor
I
could
come
up
with
is
from
my
experience
as
a
parent.
It
has
really
felt
like
going
from
the
slick
stroller
system
to
a
bunch
of
toddlers
poking
each
other.
In
the
heart
there
have
been,
there
have
been
growing
pains.
One
of
the
biggest
difficulties
we've
had
was
just
resourcing
we're
a
pretty.
A
You
know
we're
a
smallish
mid-sized
company,
my
team,
the
operations
team
is
2.2
people
that
point
to
being
my
manager,
who
tries
really
hard
to
be
in
ic
but
has
to
manage,
and
you
know
we
we
we
used
to
be
the
devops
team,
now
we're
the
ops
team,
because
there's
too
much
ops
to
do
now
that
we
can't
really
do
any
of
the
dev
stuff.
We
had
a
platform
team
at
one
point
it
you
know
being
dispersed
out
into
the
feature
teams,
and
so
there's
there's
actually
no
resources
dedicated
to
building
this
platform.
A
It's
all
just
been
done
with
whatever
we
can
sort
of
grab
from
people
and
get
them
to
to
contribute,
and
it's
just
been
time.
It's
taken
us
about
two
and
a
half
years
to
figure
out.
What
does
our
platform
even
need
to
have
much
less,
how
we'll
build
it
and
how
we'll
you
know
what
what
pieces
we
can
put
together
to
compose
it
and
then
just
to
do
the
iterative
process
of
we
moved
in
app
now,
we've
moved
lots.
What
what's
missing?
A
A
I
was
going
to
do
a
deep
dive
into
the
the
stack
that
we
created,
but
the
deeper
message
for
me
going
through
this
is
that
the
cncf
has
lots
of
options
for
every
kind
of
tool,
there's
probably
more
than
one
implementation,
and
you
can
really
build
and
compose
a
stack
out
of
whatever
you
want
that
fits
for
your
needs,
so
so
less
than
paying
attention
to
the
choices
we
made
it.
You
know
it's
more,
that
it's
possible
to
do
this
composition
of
a
platform.
Now
I've
had
this
mantra
for
the
last
couple
of
years
of.
A
If
you
can
wait
six
months,
you
should
and
that's
just
because
the
ecosystem
is
moving
so
fast.
The
tooling
is
being
developed
so
fast
that
in
six
months
everything
is
going
to
be
100
easier,
I'll
get
into
my
case
study
for
that
in
a
little
bit.
But
but
I've
been
saying
this
over
and
over
again
and
I
feel
like
it's
starting
to
change
so
we
started
the
the
pendulum.
Swing
of
simplicity
and
simplicity
is
great,
but
it
has
limits.
We
were
able
to
deploy
really
quickly.
A
A
What
do
we
actually
want
is
is
the
question
we
ended
up
having
to
answer
and
do
we
have
the
resources
to
do
it
all
right
going
to
that
side
we
get
into
kubernetes
and
we
realize
oh,
we
need
metrics,
okay,
well,
great
prometheus
is
there
for
that,
and
we
need
to
be
able
to
see
what's
happening
between
our
systems
well
distributed.
Tracing
is
there
for
that
jaeger's
there,
okay
cool
we
got
that
covered,
but
then
you
get
into
the
smaller
nitty-gritty
things
of
how
do
we
actually
secure
this
properly
and
hey?
A
I
would
expect
that
if
I
change
my
environment
variables,
the
pod
is
going
to
restart,
but
that's
not
actually
true.
How
do
we
get
pod
restarts
when
the
config
changes
and
there's
just
these
and
and
and
and
it
starts
to
feel
overwhelming
and
that's
why
I'm
so
excited
that
things
are
kind
of
swinging
into
this
happy
medium
where
the
tooling's
there
it
takes
less
work
to
get
the
tools
working
together
and
I
think
critically
the
vendor
support
is
catching
up.
I'm
going
to
give
you
some
some
concrete
examples
of
this
observability.
A
A
Most
of
our
engineers
had
ever
been
on
a
vpn
before
so
that
was
confusing
for
them,
and
the
cloud
native
stuff
was
falling
over
occasionally
or
commonly,
because
we
didn't
have
dedicated
eyes
on
it,
because
we
were
doing
50
things
trying
to
set
all
the
and
and
and
stuff
up.
So
it
wasn't
a
great
experience.
A
Now
we
actually
have
a
vendor
who
fully
supports
cloud
native
stuff.
It's
not
an
external
metric,
that's
going
to
get
charged
at
five
times
the
cost
and
they
give
us
a
helm
chart
we
deploy
the
helm
chart.
It
sends
out
prometheus
and
open
telemetry.
We
send
our
stuff
there.
It
forwards
it
on
to
a
central
place
where
everyone
can
look
at
it,
and
we've
got
great
tooling
around
it.
It's
been
a
fantastic
experience.
That's
only
really
been
possible
in
the
last
year
year
and
a
half
mesh
increases
another.
A
A
The
standards
are
getting
better,
and
so
interoperability
is
actually
becoming
a
real
possible
thing
right.
We
use
ambassador
for
our
gateway
and
it
plays
very
nicely
with
link
or
d
both
of
those
play
nicely
with
the
open,
tracing
and
open
telemetry.
So
we
can
get
observability
into
all
this
really
easily.
It's
nice,
it's
really
nice
building
and
deploying
this
is
probably
the
number
one
value
add.
We've
had
this
year
for
our
develop.
That
developer
experience
I
mentioned
in
that.
A
You
know
when,
when
that,
when
that
lead
was
talking
about
how
hard
everything
was
he
was
really
referring
to.
I
got
to
do
17,
yml
files,
and
I
got
to
write
this
docker
file
and
then
we
have
to
maintain
all
of
it
and
we've
cut
all
that
down
by
abstracting
it
out
with
standardized
helm,
charts
that
we've
written
for
our
organization,
for
you
know,
go
microservice
or
or
rails
service,
and
now
they
just
have
to
put
in
some
values
and
deploy
it.
A
It's
getting
much
closer
to
being
a
pleasant
platform
for
docker
files,
we're
using
build
packs
now
no
more
docker
files
to
write
or
maintain,
ironically
enough
we're
using
heroku's
built
pack
stack.
So,
as
we
migrate
out
the
last
long
tail
of
our
applications,
we
don't
even
have
to
change
the
proc
files,
it's
seamless
to
just
get
things
out
from
where
they
were
and
deploy
them
into
kubernetes.
It's
it's
been
real
pleasant
and
made
things
much
faster,
and
the
thing
I'm
most
excited
about
honestly
is
actually
the
marketplace
that
is
being
created.
A
I've
actually
gotten
surprise
from
people
when
I
say
that
we
want
to
buy
and
not
build,
and
I
think
that's
partially,
because
a
lot
of
the
most
vocal
people
in
this
environment
are
the
big
players
and
so
thanks
to
kubecon
for
giving
me
a
keynote
slot
to
to
give
this
perspective.
But
you
know
there's
a
space
between
the
five-person
org
and
the
5000
person,
org
that,
where
there's
there's
room
where
we
we
wanna
buy
and
not
build
we're
we're
too
big
for
the
platform
as
a
service.
A
A
A
I
think
one
of
the
biggest
pitfalls
of
of
platform
teams
that
I've
seen
is
that
they
build
things
for
themselves
and
platform
teams
tend
to
be
composed
of
the
the
wonkiest
engineers
or
some
of
them,
and
you
know
it
ends
up
being
a
complex,
docker,
orchestration
stack
that
is
powered
by
make
files
written
in
vim
to
do
local
development
and
I'm
one
of
those
wonky
people
I
like
make.
I
like
them,
don't
at
me,
but
that's
not
what
everyone
consuming.
A
That
platform
wants
to
use,
and
so
I
got
I
didn't
get
a
product
manager,
but
I
got
part-time
from
a
product
manager
for
two
months
who
helped
me
do
interviews
of
our
our
internal
users
of
our
engineers
and
qa
and
support,
and
we
put
together
personas
and
then
we
were,
and
then
he
kind
of
downloaded
into
my
brain,
a
bunch
of
product
management.
You
know
info
and
strategies
and
stuff
that
we've
used
over
the
rest
of
the
year
to
help
inform
what
we
build.
A
The
next
thing,
we've
done,
that's
been
really
critical
is
sort
of
harnessing
conway's
law.
We
know
that
you're
going
to
have
your
technology.
Eventually,
you
know
reflect
your
people
and
your
teams.
We
try
to
hack
that
a
bit
and
make
cross-functional
working
groups
where
there's
representation
of
the
personas
we
created
from
various
people.
A
So
if
you
know
we
had
a
persona
of
the
junior
engineer
and
the
like
the
senior
engineer
that
just
wants
to
ship
stuff
and
isn't
really
into
configuration
and
getting
their
hands
dirty
and
devops
stuff,
those
people
need
to
be
represented
on
a
group,
that's
working
on.
How
do
we
do
observability
or
how
do
we?
You
know
work
on?
How
do
we
improve
our
local
development?
A
A
This
and
y'all
can
figure
out
what
you
want
to
use
and
then
they're
able
to
become
experts
and
make
the
choices
which
are
are
really
impactful
for
people
actually
wanting
to
use
that,
since
we
don't
have
anyone
any
dedicated
team
to
actually
implementing
that
team
has
a
board,
it
generates.
We
generate
stories,
and
then
people
pick
up
those
stories
as
they
can
to
write
the
script
that
will
you
know,
install
all
the
tooling.
You
need
to
interact
with
our
service
mesh
or
something
so.
A
A
I
don't
think
we're
quite
at
a
rails
moment,
but
as
a
relatively
early
adopter,
I
think
we're
getting
a
lot
closer.
It's
not
exactly
the
stroller
I
showed
earlier,
but
but
it's
getting
to
be
a
little
bit
more
like
this
necessarily
complex
squirrel
feeder.
You
know
it
does
a
lot
of
stuff
that
is
important
it
we
still
had
to
put
it
together.
We
had
to
compose
it,
but
it
looks
and
feels
a
lot
more
professional
and
it's
it's
a
lot
more
pleasant
to
to
to
use.
A
So
my
mantra
is
changing
it's
now.
If
you
can
wait
six
months,
you
might
actually
be
good
to
go
right
now.
The
the
tooling
is
at
a
point
in
terms
of
maturity
and
interoperability,
where
you
can
dive
in
as
a
midsize,
org
and
compose
something
that
that
is
going
to
serve
your
needs.
Probably
pretty
well,
and
one
of
the
things
I'm
most
excited
about
is
seeing
the
actual
platforms
as
a
service
here
every
year,
because
I
really
truly
believe
that
if
you
are
a
five
person
org,
you
should
not
be
in
kubernetes.
A
Thank
you
for
watching
I'm
at
the
develop
nick
and
the
regular
places
since
I'm
not
about
to
step
down
from
a
platform
podium
into
the
crowd
of
my
peers
and
chat,
which
I
really
miss.
If
you
didn't
get
something
out
of
this,
that
you
wish
did
or
you
want
more
detail,
I
would
be
overjoyed
if
you
reached
out
to
me.
I
love
talking
about
this
stuff.
Thank
you.
So
much
for
watching.