►
From YouTube: DevOps is dead. Embrace platform engineering.
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Let
me
first
start
with
you
know
remarking
that
the
title
of
this
presentation
is
provocative
and
I,
don't
really
mean
it.
Devops
isn't
that
platform,
engineering
and
devops
are
actually
best
friends,
but
wouldn't
you
agree,
makes
for
a
great
title
now:
I
am
all
about
platform
engineering
really
I
am
working
with
and
contributing
to
the
platform.
Engineering
communities
wherever
possible
and
I
encourage
you
to
do
the
same.
It's
such
a
interesting,
such
a
thriving
community
and
there's
so
much
going
on.
A
There's
internal
developer,
platform.org
platformengineering.org,
there's
a
large
slack
group
they're,
the
engineering
meetups,
there's
platform
con
and
I
myself
I
work
for
Humanity
in
my
day,
job,
basically
at
night,
more
or
less
here
in
Europe
for
the
community.
A
A
How
and
you
know
why
I'm
choosing
this
title
or
on
the
other,
on
the
one
hand,
because
it
has
obviously
attracted
your
interest,
but
there
is
more
to
it,
I
think
devops
in
its
current
form.
If
you
want
the
devops
that
I'm
seeing
practice
in
many
many
organizations
is,
this
is
a
victim
of
misinterpretation.
A
The
devops
you
know
in
its
Core
Essence
is
about
culture
and
it's
about
people
management
and
it's
about
aligning
people
alongside
a
joint
delivery
process.
A
But
devops
is
not
that
the
idea
of
taking
everything
that
has
been
in
specific
silos
before
and
just
throwing
it
at
the
individual
contributor
without
any
filter.
If
you
want
I,
really
believe
that
that
is
not
a
very
responsible
or
clever
thing
to
do
and
I
think
it's
producing
a
lot
of
burnouts.
Frankly,
it's
very
bad
for
the
mental
health
for
many
many
people
and
it's
slowing
down
the
productivity
of
the
respective
teams.
A
Frankly,
just
leading
to
a
lot
of
frustration
now,
I
think
one
of
the
things
that
we
have
to
acknowledge
is
that
cloud
native
is
dirty.
It's
chaotic.
It
is
complex
and
developers
just
waste
a
lot
of
time
operating
apps
and
trying
to
make
sense
on
how
things
fit
together.
If
we
think
about
the
applications
that
we
operate
10
years
ago,
there
were
a
lot
simpler:
they
had
less
global
scale,
less
distribution,
less
users,
monoliths
less
tools.
Everything
is
becoming
much
more
complex
and
I.
A
Don't
think
that
this
is
because
we
just
like
like
to
procure
new
stuff
or
try
out
new
technologies,
which
is
often
used
as
a
reason,
I
think
it's
because
the
world
we
live
in
and
the
amount
of
users
we
serve
is
global
is
complex
in
itself
and
our
applications
need
to
meet
that
demand
of
an
Ever
evolving
ever
more
complex
yeah
globalization
really
now.
I
always
think
that
this
is
the
core
point
of
all
of
this,
and
this
is
why
I
want
to
emphasize
this
again
and
say
that
not
devops
is
dead.
A
That
will
probably
remain
to
be
the
philosophy
or
concept
and
The
Guiding
Star.
As
long
as
we
are
building
software,
but
you
build
it,
you
run
it
at
all,
cost
that
is
dead
and
it
will
not
deliver
results
and
in
fact
it
will
lead
to
that
burn
out
of
your
teams.
Now
the
answer
to
I
think
that
is
platform
engineering
platform
engineering,
if
you
want
is
the
is
the
implementation
of
good
practices
of
devops
to
a
certain
extent.
A
Now,
let's
look
at
a
little
graph
here.
The
the
pink
curve
is
a
proxy
for
cloud
native
adoption.
In
the
end,
it's
just
you
know,
container
adoption
that
I
believe
is
a
good
proxy
and
the
yellow
curve
is
the
right
rise
of
internal
developer
platforms
and
platform
engineering.
A
Now,
if
you,
if
you
go
back
a
little
bit
in
time,
16
years
by
now,
we
have
a
noteworthy
presentation
by
Lana
fogles,
who
I
think
still
is
the
CTO
at
Amazon
web
services,
and
he
proclaimed
this.
You
build
it,
you
run
it
now.
If
you
think
back
2006
the
you
build
it,
you
run
it
applications
that
we
just
discussed
were
a
lot
more
simpler
than
the
ones
that
we
are
confronted
with
today,
and
that
means,
in
the
context
of
the
time
that
claim
of
anaphor
was
made
a
lot
of
sense.
A
Yes,
you
build
it
you
run,
it
is,
is
a
good
idea,
but
as
I
just
suggested,
Cloud
native
has
become
a
lot
more
complex,
and
that
means
as
there's
Cloud
native
trend
evolves
we're
seeing
more
and
more
teams.
Look
at
this
and
say
this
can't
be
the
answer:
we're
actually
overwhelming
people
we're
not
helping
them
we're,
making
things
we're
just
throwing
stuff
at
them,
we're
making
things
more
and
more
complex,
and
then
in
2011
there
is
cloud
native
at
Google
and
as
they're
observing.
A
Oh
things
are
getting
more
and
more
complex,
they
start
with
actually
building
platforms
and
rolling
them
out
at
scale,
and
you
can
see
that
five-year
lag
function
from
cloud
native
to
hey.
A
We
need
to
change
this
in
a
lot
of
different
teams,
salando
in
Europe
GitHub
in
in
in
in
the
United
States,
where
Jason
Warner
moves
over
from
Heroku
after
being
their
senior
as
president
becoming
the
CTO
at
GitHub
and
then
starting
to
build
an
internal
Heroku
based
on
Amazon
web
services
and
that
five-year
lag
function
holds
true
in
almost
every
organization
that
I'm
that
I'm
observing
after
five
years,
they're
saying:
oh,
you
know
it's
not
as
easy.
After
all,
let's
not
forget
that
you
know
kubernetes
on
eks.
A
Everyone
has
taken
the
Amazon
world
has
been
around
since
I,
don't
know
three
four
years,
so
it's
still
very
fresh,
and
so
now
more
and
more
teams
are
saying.
Okay,
this
this
can't
be
the
truth.
We
have
to
simplify
this,
and
this
is
why
platform
engineering
is
picking
up
so
rapidly.
You
know
it's
not
because
Gartner
made
it
a
top
trend
for
2023,
no
gotten
I
made
it
to
top
10
for
2023,
because
it's
a
response
to
that
complexity
that
we're
currently
confronted
with
yeah.
A
A
You
know,
let's
look
at
the
platform
at
the
application
developers
and
then
the
platform
operations
SRE
teams
for
the
application
developers
is
really
about
reducing
waiting
times,
reducing
cognitive
load,
making
things
easier
to
consume,
enabling
self-service,
making
it
really
simple
to
change
configurations
effectively,
making
it
really
simple
to
request
an
S3
bucket
without
having
to
you
know,
learn
yet
another
technology
or
you
know,
maybe
you
can
even
your
your
good
at
terraform,
but
you
just
don't
want
to
you
want
to
focus
on
the
application
hand
you're
just
not
trying
to
understand
how
that
particular
networking
is
now
implemented.
A
I
think
it's
very
important
that
we
want
to
achieve
all
of
that
without
abstractions
the
developer.
We
shouldn't
go
back
into
a
world
that
we
had
in
2014
2015,
where
you
know
we
had
these
platforms
and
there
were
black
holes
and
you
had
no
idea
what
would
happen
under
the
hood.
If
you
would
send
a
certain
command,
so
modern
platforms
are
golden
paths,
opaque
abstractions.
A
We
want
to
reach
this,
but
while
not
taking
away
context,
if
you
think
about
a
team
like
a
Google
at
a
Google,
you
you
say:
hey
I
need
I
need
a
certain
resource
component
and
then
the
system
will
say:
okay.
What's
your
context,
you're
deploying
like
a
change
of
that
app
to
that
environment.
A
Well,
I'm
going
to
match
you
that
resource
and
that
feels
like
okay,
Central
Google
streams
are
deciding
which
resource
to
match,
but
they're,
actually
very,
very
good
at
giving
you
the
context,
hey,
you
know
we're
choosing
this
resource,
and
this
is
the
way
it's
configured
because
of
ABC,
and
if
you
want
to
apply
a
change,
then
that's
the
team.
You
can
speak
with
or
you
can
actually
apply
that
change
yourself.
If
you
want
to
go
deeper,
so
I
call
that
layered
abstractions,
let
the
user
decide
what
cognitive
load
they
want
to
expose
themselves
with
now.
A
The
second
team
that
actually
touched
by
this
is
obviously
the
operation
team
platform
team,
SRE
team,
depending
on
what
latest
bus
world
you're
using
and
for
them
it's
really
about
standardization
by
Design
and,
frankly,
reducing
repetitive
tasks.
I
think
it's
a
good
time
to
look
at
platform
engineering.
A
If
you
have
a
jira
bot
that
is
flowing
over
with
hey,
can
you
help
me
debug
this
and
hey
I
need
a
new
environment
here
and
at
this
point
platform
engineering
might
be
something
to
look
at
reduce
ticket
ops
and
then
actually
allow
these
teams
to
focus
to
frankly
hit
their
SLA
and
improve
the
things
that
their
practices
they're
using
right
now,
what's
an
internal
developer
platform?
Well,
it's
pretty
simple.
A
It's
the
sum
of
many
components
that
form
golden
paths
for
developers.
There
is
no,
not
the
IDP
an
IDP
and
that's
for
many
people,
frustrating
that
want
to
have
easy
answers
to
complex
questions
and
IDP
for
a
healthcare
provider
in
in
in
South.
Africa
might
look
very
different
to
the
financial
services
company
in
Norway
or
the
e-commerce
company
in
in
San
Francisco.
But
it's
really
about
making
sure
you
have
reusable
components.
You
wire
all
your
Dev
tools
and
orchestrate
them
in
a
structured
manner.
A
You
allow
the
development
team
to
consume
that
with
low
cognitive
load,
and
you
allow
the
platform
engineering
team
to
automate
that
to
actually
reduce
human
interaction
and
that
in
combination
actually
helps
you
operate
the
infrastructure
in
a
repeatable
manner.
Now
I'm
I'm
from
Germany,
so
I
obviously
need
to
think
about
cars.
A
All
the
time
and
I
have
this
analogy
with
a
car
manufacturing
industry,
immature
organizations
tell
teams
to
build
a
car,
give
them
a
credit
card
and
then
tell
them
where
to
find
a
store
with
raw
materials
and
then,
when
they
struggle
they're,
sending
people
to
help
them
organize.
And
then
you
call
that
devops
now
mature
organizations
tell
teams
to
build
a
car,
give
them
a
credit
card
and
tell
them
where
to
find
the
raw
materials.
A
A
And
if
you
think
about
this
and
that's
something
that
Jason
Warner
said
and
that
resonated
a
lot
with
me
in
a
good
setups
in
a
good
setup
developers
and
operations,
do
not
talk
about
transactional
things
they
speak
about.
How
can
we
improve
the
process?
How
can
we
make
work
easier
and
less
interruptive
for
all
parts
involved,
but
they
don't
speak
about
hey?
Can
you
please
spin
up
that
environment,
because
that
just
leads
to
waiting
time
and
not
actually
produces
every
any
tangible
value
and
outcome?
A
But
that's
you
know
all
good
and
fine.
Congratulations
yet
another
category,
hello
platform
engineering,
but
where
do
you
actually
get
started
with
platform
engineering-
and
you
know
I've
been
fortunate
enough
to
help
a
number
of
organizations
at
this
point
on
their
Journey
towards
platform
engineering,
and
there
is
a
certain
Playbook
that
I've
been
picking
up
and
you
know,
to
a
certain
degree,
a
step-by-step
guide
and
that
will
help
you
digest
or
dissect
how
to
actually
approach
platform
engineering
as
a
first
step.
A
I
think
it's
really
about
making
sure
you
treat
your
platform
as
a
product,
because
a
platform
and
an
internal
developer
platform
looks
so
different.
No
matter
in
what
organization
you
look
into,
there
is
no
one-size-fits-all,
and
there
is
no
recipe
that
you
can
look
up
on
Reddit.
That
will
just
allow
you
to
get
that
as
a
sensible
default.
You
need
to
shape
this
into
and
you
tailor
that
to
the
situation
that
you
find
yourself
in.
A
You
will
have
different
CI
pipelines
and
you
will
run
different
types
of
workloads
and
all
of
that
needs
to
be
mirrored
within
the
platform
now
I
think.
Then
it's
also
important
to
understand
that,
depending
on
your
industry,
you
will
have
completely
different
governance
requirements,
security
requirements,
it's
a
difference
whether
you
work
in
you
know
the
US
government
sector
or
in
e-commerce
framework
in
you
know
a
basement
of
a
Berlin
hipster
startup.
A
If
we
speak
about
platform
as
a
product,
what
we
mean
is
that
yeah
you
should
treat
it
as
a
product.
You
know
assign
a
product
owner.
Maybe
you
can't
afford
somebody
for
a
full-time,
but
it's
a
side
project
for
one
of
your
POS.
They
should
have
a
you
know,
clear
road
map
and
grad
tickets
and
or
whatever
other
project
management
tool
you're
using
they
should.
A
You
know
a
platform
team
has
software
Engineers
that
can
actually
build
stuff.
You
do
user
interviews,
you
have
a
user
right,
it's
an
internal
user,
but
it's
a
user.
There's
nothing!
You
know
used
as
a
user.
You
should
do
user
interviews.
You
should
measure
whether
your
user
likes
your
platform
and
you
need
to
do
things
step
by
step
by
step.
You
know
and
really
see
that
Above
So
number
one
and
which
sounds
trivial,
but
not
enough
platform.
Engineering
teams
do
that.
Make
sure
you
treat
your
platform
as
a
product.
A
Manual
pays
and
Matthew's
gotten
have
said
that
for
you
know
years,
but
it's
so
vital.
So
important
I
really
make
sure
that
this
is
the
way
you
you
approach
and
three
things
now
number
two
prioritization
I
think
many
teams
fall
into
that
prioritization
fallacy.
Where
they're
you
know,
they're
letting
themselves
be
guided
by
feelings
on
what
to
do.
First,
the
the
most
obvious
thing
is
they
they
think
about.
You
know:
what's
the
first
thing:
a
developer
does
when
they
join
a
company
well
and
they
think
oh
well,
they're
on
board.
A
Well,
let's
actually
start
with
making
it
really
simple
for
developers
to
onboard
another
behavioral
pattern
that
I'm
observing
is
that
they
say
well,
what's
the
first
thing
that
that
we
do
when
we
start
a
new
application
or
service,
and
then
the
answer
is
well
we're
you
know
starting
a
new
service.
Let's
say
you
know
a
spring
boot
service,
we'll
take
a
template
and
then
we'll
clone
and
then
we'll
start
to
customize.
A
A
How
often
do
you
actually
spin
up
a
new
service
and
if
you,
even
if
you
do
that,
very
often,
how
much
time
does
that
take
you,
and
even
if
it
takes
you
a
long
time,
isn't
there
a
lot
of
other
stuff?
That's
less
obvious
and
that's
less
anchored
in
your
brain
that
takes
a
lot
more
time
and
a
lot
more
interactions
from
developers
and
operations,
thus
actually
providing
a
lot
of
a
lot
more
Roi
return
on
investment
to
the
actual
case.
A
So
the
first
things
you
think
of,
if
you
think
about
platforms
and
what
you
could
optimize
and
you
know
really
things
that
go
beyond
the
simple
update
of
an
image.
Well,
the
first
things
you
think
about:
don't
necessarily
need
to
reflect
the
things
that
you
should
actually
Focus
your
attention
on.
If
you
start
on
your
platforming
journey,
I
always
propose
the
same
procedure
on
how
to
actually
approach
this
now.
Take
a
wide
piece
of
paper.
Sit
down!
Ask
yourself!
A
Well,
how
often
do
you
go
beyond
the
simple
update
of
an
image
and
don't
ask
that
yourself?
Let
me
correct
myself:
ask
that
your
users,
your
individual
front-end
developers
and
your
backend
developers
and
your
you
know,
operation
teams
and
juniors
and
seniors
make
sure
to
speak
to
a
couple
of
them.
How
often
are
they
adding
environment
variables?
How
often
do
they
change
configurations?
How
often
do
they
spin
up
a
new
environment?
How
often
do
they
onboard
new
colleagues
then
normalize
that
so
against
100
deployments?
How
often
do
they
do
that
individual
action?
A
How
much
time
is
included
for
from
developers
how
much
time
is
included
per
individual
action
for
operations
teams,
and
then
you
know
sum
this
up,
multiply
that
with
your
total
number
of
deployments,
and
you
have
your
Roi
case,
you
know
then
just
look
at
what's
the
largest
number
of
hours
that
we
spend
as
a
company
on
those
specific
things,
and
here
you
go,
you
have
your
prioritization
make
sure
you
do
that
exercise.
Don't
just
think
you
can
sense
that,
from
your
own
experience
very
unlikely,
you
can
step
number
three
agree
on
the
lowest
common
denominator.
A
Tech
stack,
it's
unlikely
that
you
can
churn
out
something
that
sadly
works
for
everything.
You
know.
If
you
say
you
know
you
both
you,
you
find
yourself
building
a
very
long
stack
of
everything
you
need
to
support
yeah.
You
will
probably
not
be
able
to
ship
any
product
anytime
soon
and
who
knows
whether
you
still
have
your
funding?
If
you
can't
actually
provide
you
know
tangible
results
fairly
quickly,
so
look
at
what's
the
most
used
thing
or
what
does
the
future
hold?
You
know?
A
Is
the
future
VM
or
is
the
future
kubernetes
or
is
the
future
Lambda
functions?
You
know
I,
don't
particularly
care,
but
you
should
find
your
lowest
common
denominator
and
then
start
optimizing
against
this.
In
most
cases
it
will
be
containers
and
kubernetes,
but
you
know
everybody's
individual.
Maybe
it's
you
know
it's
it's
a
it's
a
managed
service
of
another.
The
providers
just
make
sure
you
don't
try
to
do
everything
at
once.
Foreign
number.
Four.
A
You
want
to
find
your
I
call
it
a
lighthouse,
app,
a
lighthouse
team,
one
team
of
people
that
are
really
Innovative
that
want
to
try
new
things
that
are
the
ones
that
are
always
front
and
center.
If
it's,
you
know,
if
there's
something
new,
to
try
that
are
really
interested
in
in
doing
this,
providing
feedback
testing
stuff
and
they
should
have
an
application.
That's
exactly
on
your
lowest
common
denominator.
Tech
stack.
A
Take
that
team
right
and
then
work
with
that
team
very
closely
and
the
next
step
decide
about
the
general
architectural
layout.
We
are
seeing
two
patterns,
trending
Dynamic,
internal
developer
platforms
and
static
internal
developer,
Platforms.
In
the
end,
it
comes
down
to
the
methodology
of
configuration
management
that
you
choose
and
apply
static,
configuration
management
or
dynamic
configuration
management.
This
here,
the
the
one
that
we're
seeing
right
now
is
a
static
IDP.
So
you
have
your
IDE
to
code.
A
Then
you
have
static
config
files
in
your
version,
control
system,
your
workload,
yaml
files
on
an
environment
by
environment
basis
infrastructure
as
code,
and
you
have
your
CI
and
Registries
to
actually
build
the
workload
and
then
you
throw
everything
at
a
CD
at
a
controller
and
then
stuff
gets
deployed.
So
that's
the
approach
with
static
configuration
management
and
the
general
architecture.
That's
I
would
say
the
most
common
approach,
but
also
the
I
wouldn't
call
it
outdated,
but
the
you
know,
probably
less
less
modern
or
less
flexible
approach.
A
A
You
have
your
workloads,
you
have
a
workload
specification
that
describes
the
environment
in
an
agnostic
way,
so
one
file
that
works
across
all
environments-
and
there
is
an
open
source
project
called
score
that
is
dealing
with
exactly
that,
and
workloads
and
workload
specifications
are
the
the
two
things
that
developers
usually
deal
with.
So
they
say
hey.
This
is
my
workload
depends
on
a
database
of
type
postgres,
rather
than
saying
hey
on
that
particular
RDS
instance.
A
A
If
you
want
so
the
platform
team
can
say
well,
if
the
context
is
staging,
then
please
match
that
particular
RDS
or
create
that
DNS
and
there
are
still
normalci
pipelines
to
build
the
workload
and
then
there's
a
workload,
a
platform
orchestrator
to
basically
read
that
declarative
application
model
and
then
say
well,
where
am
I
okay,
environment
of
type
staging
I'm,
going
to
create
the
actual
config
files
context,
specific
I'm,
going
to
match
the
infrastructure
or
I'm
going
to
create
new
ones
and
then
I'm
orchestrating
the
workloads,
resources
and
providers.
A
The
beauty
is
that
the
developer
can
decide
how
deep
do
I
want
to
go.
How
much
cognitive
loads
do
I
want
to
take
it's
a
clear
separation
of
responsibilities
of
death
and
Ops
without
getting
in
their
ways
and
and
it
drives
yeah
standardization
by
Design.
So
those
are
the
key
patterns.
There
is
really
like
if
you've
gone
down
One
path,
you
could
still
change
that.
But
I
would
say
you
know
think
about
this
before
you
start
building
yeah
then
start
building
I
believe
again
platform
as
a
product.
A
Small
changes
make
sure
you
build
the
one
thing
that
matches
your
return
on
investment,
think
of
the
calculation
that
we
did
before
and
makes
it
10x
better,
even
if
it's
only
a
small,
tiny
thing,
but
you
want
to
make
sure
that
your
evangelist
team
loves
it
and
thinks.
Oh,
this
is
so
much
better
than
everything
we
have
before
over
allocate
time
on
this,
it's
the
small
little
details
that
really
make
your
early
fans
and
then
you
can
take
that
those
ambassadors.
A
If
you
want-
and
you
can
start
scaling
this
to
the
next
teams-
actually
expand
your
usage.
Look
at
the
next
things
that
actually
provide
Roi.
Never
forget
that
there
is
no.
There
is
no
platform,
that's
ready!
It's
constantly
evolving!
Once
you've
reached
a
certain
point.
There
will
be
a
new
technology
to
weave
in
so
iterate
iterate,
iterate
and
I
encourage
you
to
get
help
and
exchange
thoughts
with
fellow
platform
Engineers
there's
platformengineering.org
platform
con.
A
As
a
conference
there
are
the
meetups
there's,
the
slack
group
and
yeah
I
hope
you
make
the
most
out
of
it
and
you
enjoy
your
journey
such
an
exciting
time.
If
you
want
to
chat
about
this
again,
you
know
reach
out
to
me
Casper
at
qnitech.com
and
until
then
thank
you
for
listening
to
this
talk
and
see
you
soon.