►
From YouTube: DevOps ain't dead but...we gotta talk
Description
Don't miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from 18 - 21 April, 2023. 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.
A
Cool
so
hello,
everybody,
it's
great
to
see
you
all
here
today,
it's
so
cool
to
see
people
from
all
over
the
place.
That's
really
exciting,
get
to
talk
to
every
single
one
of
you
about
this
I
come
to
you
from
Humana
Tech,
to
talk
to
you
a
little
bit
about
what
we've
learned
from
the
adoption
of
platform
engineering
and
what
we
originally
called
this
is
devops
is
dead,
as
you
can
see
with
the
cool
logo.
A
Obviously
it's
threw
up
a
few
things.
It
stirred
some
controversy,
but
I
want
to
kind
of
dive
into
what
it
really
is
about
and
what
that
really
means
devops
isn't
dead.
We
just
need
to
talk
about
iterating
and
doing
things
a
little
bit
better.
So
let's
talk
about
doing
devops
responsibly.
A
A
My
background
is
actually
I'm
a
full
stack
engineer
primarily
from
the
e-commerce
world
and
text-based
online
games
whole
world
in
there
that
I've
been
doing
since
I
was
a
kid
I've
also
been
in
fintech,
as
well
as
automotive
industry,
but
I'm.
Actually,
an
anthropologist
by
formal
education,
so
part
of
what
we're
going
to
talk
today
is
about
this
collaboration
of
humans
and
technology
and
what
happens
and
how
we
can
manage
that
effectively
and
make
sure
that
people
aren't
burning
out.
A
It's
the
perfect
segue
for
me
to
introduce
you
to
kind
of
today's
Core
theme.
You
can
find
me
via
email
or
at
malloryhead.
You
can
also
find
me
by
that
name
on
LinkedIn,
if
you're
interested
so
as
a
whole,
the
concept
of
devops.
As
we
know
it,
is
a
victim
of
misinterpretation
and
misapplication.
It's
a
bit
of
both
at
its
core,
though.
We
believe
that
devops
is
more
than
just
a
person
you
hire
or
a
methodology
you
employ.
It
really
is
at
the
end
of
the
day
about
people,
management
and
human
interaction.
A
A
Don't
have
to
tell
this
group
that
it's
a
very
familiar
group
with
this
place
developers
right
now
are
wasting
about
25
of
their
time
operating
apps
as
the
complexity
increases,
so
we're
looking
at
25,
more
services
and
infrastructure
resources
per
application
in
comparison
to
how
things
probably
were
in
2010,
which
I
just
realized
is
quite
a
long
time
ago,
when
you
think
about
it,
but
that's
quite
a
big
scale
up
in
how
complex
things
get
in
terms
of
services
and
infrastructure,
resources,
there's
also
five
times
more
specialist
tools
in
the
tool
chain
to
meet
the
challenges
of
scaling
and
with
that
also
comes
a
lot
more
specialist
roles,
including
devops
sres.
A
Whatever
you
want
to
call
that
role,
there
is
things
that
match
this
idea
of
specialized
tools
within
the
tool
chain
that
meet
this
challenge.
The
challenges
that
come
with
scaling
we're
also
seeing
an
increase
in
the
demand
and
complexity
of
all
of
these
different
things,
which
is
driven
by
evolving
Global
environments
within
applications.
A
This
is
just
sort
of
the
nature
of
technology
and
we
all
know
how
this
works,
but
at
the
end
of
the
day,
Cloud
native
is
a
really
complex
sphere.
There's
a
lot
of
things
going
on
it.
Changes
constantly
and
best
practices
are
always
involving.
A
So
this
idea
of
you
build
it.
You
run
it
at
all.
Costs
really
does
not
work.
It
results
in
Burnout
for
you,
it
results
in
Burnout
for
your
team.
When
this
was
first
said
you
build
it,
you
run
it
in
2006.
We
think
a
lot
of
companies
interpreted
that
kind
of
incorrectly
and
it's
resulted
in
a
lot
of
issues
for
people
at
the
end
of
the
day.
A
A
While
we
have
said
that
devops
is
dead,
what
we
actually
really
mean
it's
dead
in
the
context
of
you
build
it,
you
run
it
at
all
costs.
Instead,
we
want
to
say
this
is
a
stage
two
that
is
more
about
enablement,
engaging
individual
contributors
in
a
way
that
they're
comfortable
and
really
just
allowing
people
to
grow
within
infrastructure
and
Cloud
native
in
a
way
that
is
sustainable
for
them.
So
it's
about
you
build
it.
A
You
run
it,
but
do
it
intelligently
and
don't
forget
about
the
people
at
the
end
of
the
day
that
are
sitting
behind
that
computer
screen.
So
this
chart
is
really
interesting
and
the
reason
I
bring
it
up
is
because
we're
seeing
a
five-year
lag
in
Concepts
within
Cloud
native,
really
catching
on
and
we're
starting
to
notice.
A
Now
that
there
is
a
big
adoption
happening
with
platform,
orchestrators
and
idps,
things
that
are
native
to
platform
engineering
as
a
whole,
so
we'll
go
into
that
a
little
bit
but
I
just
like
to
show
this,
because
it
just
shows
that
there
is
fairly
predictable
cycles
of
when
things
start
getting
adopted.
So
I
suspect.
We
will
see
this
idea
of
devops
2.0
platform
engineering
as
a
logical
thing,
more
and
more
in
the
next
few
years.
A
More
people
are
talking
about
it
and
it's
going
to
keep
catching
on
foreign,
so
why
do
we
advocate
so
strongly
for
platforms
and
by
extension
platform
engineering
as
to
as
opposed
to
traditional
devops
approaches
so
for
application
developers?
We
find
it
enables
self-service
they're
able
to
do
things
on
their
own
without
resorting
to
ticket
ops
which,
as
we
all
know,
is
a
big,
complicated
process
that
makes
everyone
exhausted.
A
It
reduces
cognitive
load,
and
by
that
we
mean
workload,
so
cognitive
load
is
all
about
thinking
way
too
much
on
things
that
aren't
necessarily
the
best
use
of
your
brain
power.
It's
about
stress
it's
about
anxiety
towards
things.
It's
about
managing
your
time.
Part
of
that
also
lends
to
this
idea
of
platform
engineering,
reducing
reducing
the
amount
that
someone
has
to
be
abstracted
away.
We
enable
obstruction
at
whatever
level
someone
feels
comfortable.
A
So
a
particular
individual
contributor
may
feel
more
comfortable
working
straight
in
their
IDE,
where
someone
else
may
feel
more
comfortable
working
in
their
console
via
command
line,
curl
commands
or
some
other
CLI
type
thing,
or
even
directly,
within
a
UI.
The
other
thing
that
happens
is
that
we
increase
psychological
safety
in
someone's
work
and
I
will
talk
a
little
bit
more
about
this
in
a
second
once
I
hit
on
what
happens
for
platform
engineers
and
sres.
A
For
these
guys,
we
allow
greater
standardization
by
Design,
which
greatly
reduces
ticket
based
Ops,
as
you
guys
all
probably
know.
That
is
a
big
big
drag
to
your
daily
productivity.
When
you're
constantly
doing
every
single
task
for
five
minutes
a
million
times
a
day,
it
allows
increased
focus
and
getting
people
back
to
what
they're
doing
best
and
for
platform
engineers
and
sres.
You
can
do
a
lot
things
a
lot
better
than
just
doing
ticket
office
all
day
and
finally
again,
it's
this
element
of
increasing
psychological
safety
so
really
quickly.
A
I
want
to
touch
on
that
subject,
because
it's
getting
talked
about
more
and
more,
and
it's
really
important
to
me
that
we
talk
about
it
as
well.
So
it's
the
ability
for
an
individual
contributor
to
feel
positively
about
contributing
within
their
workspace,
so
free
of
judgment,
open
feedback
culture
in
a
supportive
environment
that
really
encourages
people
to
take
risks
and
Lead
initiatives
on
their
own.
A
In
my
experience
with
guiding
the
implementation
of
a
platform
orchestrator
in
humanitech,
as
well
as
platform
engineering
as
a
whole
and
managing
engineering
teams,
this
is
such
an
important
thing
and
I
really
want
to
stress
that
today,
helping
people
feel
fulfilled
and
engaged
in
their
work
not
only
drives
productivity
and
efficiency,
but
keeps
people
happier.
A
It
grows,
loyalty
to
your
product
to
your
business
and
it
also
helps
people
establish
healthy
work-life
balance
when
you're
happy
in
your
job,
you're
more
likely
to
take
the
time
to
take
care
of
yourself,
because
you
have
the
time
to
do
so,
and
you
have
the
freedom
of
thought
to
be
able
to
be
comfortable
and
in
that
headspace.
This
is
really
really
important.
A
We've
noticed
some
interesting
Trends
in
how
organizations
Implement
devops,
now
we've
kind
of
talked
about
how
it
ends
up
impacting
people.
Let's
look
at
what
actually
happens
as
people
evolve
around
along
the
life
cycle
of
implementing
from
standard
devops
to
platform
engineering.
A
So
this
so
we
decided
to
use
a
car
analogy
for
this,
because
I
think
it
makes
sense
for
a
lot
of
people.
So
an
immature
organization
will
tell
teams,
hey
you
need
to
build
a
car
they'll.
Give
you
a
credit
card.
Tell
you
where
to
find
a
store
with
the
raw
materials
when
the
teams
struggle
with
this,
they
send
in
people
and
Implement
content
Concepts
to
help
them
organize
around
this,
and
we
call
this
devops
it's
a
sort
of
phase.
One
phase
two
is
a
more
mature,
more
organization.
A
They
tell
the
team,
we
need
you
to
build
a
car
they've
given
their
credit
card
and
tell
them
where
to
find
the
raw
materials.
Hey
I.
Need
you
to
go
to
Home,
Depot
or
I.
Need
you
to
go
to
this
steel
shop
to
get
the
steel,
they
specify
things
a
bit
more
when
the
teams
struggle
devops
helps
them
get
a
little
more
organized
and
Cloud
Ops
help
them
find
the
right
material
and
prep
those
for
them.
A
So,
hey
we'll
get
the
steal
for
you
and
we'll
hammer
it
out
into
the
right
shape,
but
you
still
are
responsible
for
building
everything
at
the
end
of
the
day,
the
most
advanced
organization
organizations
that
we
have
found
have
said
hey
team
time
to
build
a
car.
So
what
the
platform
team
does
is
prepare
the
platform
which
is
the
chassis
of
the
car
and
has
the
developers
build
on
top
of
the
work.
So
this
is
the
body
work.
This
is
installing
the
engine.
A
A
We
have
seven
key
steps
that
we've
identified
along
this
journey
and
I'd
like
to
go
through
these
and
show
you
how
this
works.
A
If
you
treat
it
with
this
context
in
mind,
you
will
have
a
much
more
successful
time,
adapting
a
platform
to
your
organization,
to
your
workflows
and
to
your
team
structure
so
assign
a
product
over
owner,
even
if
it's
only
part-time,
even
if
this
person
is
a
product
owner
for
another
product
or
another
aspect
of
the
application
have
them
also
work
as
a
p
as
a
PO
or
a
PM
for
this
project
as
well.
Your
platform
team
also
needs
to
have
Engineers
just
like
any
other
product
team.
A
A
roadmap
is
also
useful
and,
with
that
comes
user
interviews,
so
understanding
feedback
from
your
users
about
what
works
and
what
doesn't
is
going
to
be
really
important
and
remember,
your
users
are
actual
users,
so
the
people
that
use
the
platform
every
single
day
should
be
treated
just
like
a
customer
should
be
listened
to,
should
be
respected
and
their
opinion
should
count.
It's
really
important,
so
step
two
is
not
to
fall
for
the
prioritization
policy
and
it's
to
prioritize
your
platform.
Experience
appropriately.
A
If
you
take
a
step
back
and
analyze
the
net
getting
of
starting
an
app
or
service
in
relation
to
the
total
life
cycle
of
an
application,
it's
really
actually
not
negligible
in
our
research,
and
you
can
see
some
of
the
parameters.
We've
come
up
with
here.
Seeing
hundreds
of
setups
like
this
We've
shown
the
highlighted
areas
to
be
the
most
important
procedures
to
review
first,
but
every
organization
does
differ,
so
be
subjective
and
look
hard.
A
So,
for
example,
on
this
spreadsheet,
you
will
see
that
what
actually
ends
up
being
the
most
time
for
Ops,
including
weighting
and
errors,
is
onboarding
new
developers,
and
that
also
is
something
that
takes
a
lot
of
developer
hours
too.
So
that's
something
you
can
optimize
really
really
quickly.
So
that's
the
sort
of
thing
you
might
want
to
look
at
rather
than,
for
example,
spitting
up
an
entirely
new
environment.
It
takes
a
lot
of
time,
but
the
frequency
at
which
it
happens
is
fairly
low.
A
A
It's
a
little
bit
of
a
harsh
truth
to
see
on
a
screen
that
you
will
not
be
able
to
build
a
platform
for
everything,
but
we
as
Engineers
tend
to
over
complicate
things
and
want
to
go
all
the
way
100
from
the
start.
But
it's
important
to
know
that
you
need
to
start
with
agreeing
on
the
lowest
common
denominator.
Tech
stack
to
build
your
platform
around
it,
so
your
Baseline
likely
going
to
be
kubernetes
and
containers.
A
We
will
often
see
these
not
only
focused
around
a
super,
a
certain
kubernetes
distribution
and
related
Technologies
as
sort
of
the
Baseline,
but
also
often
container
Registries
databases
and
messaging
that
sends
to
be
fairly
common
across
an
organization.
Chances
are,
if
you
use
it
in
one
place,
use
it
multiple,
but
at
the
end
of
the
day,
what's
really
important
is
critical
review
of
your
Tech
stack
to
find
this
Baseline?
This
is
something
we're
always
happy
to
sort
of
advise
on
too
and
happy
to
to
look
at
and
answer
questions
on
step.
A
Four
is
we
need
to
identify
some
evangelists
within
the
teams,
especially
for
platforms.
So
generally,
this
is
a
team
of
innovators
with
an
app
that
exactly
hits
this
target
Tech
stack
this
common
denominator
or
most
of
the
pieces
of
it,
and
a
team
that
really
is
ready
to
move
towards
platform
engineering.
So
why
find
evangelists?
These
are
the
ones
that
spread
the
word
about
the
positives
of
platform
engineering
and
how
it
has
impacted
them
within
your
organization.
A
These
are
the
folks
that
are
going
to
show
and
tell
they're
going
to
educate,
they're
going
to
help
grow
the
platform
to
other
teams
and
applications
within
the
sphere
and
help
people
get
started
quickly.
They've
done
the
hard
work
of
making
a
skeleton
system
so
adapt
on
it.
That's
part
of
why,
starting
with
the
most
common
denominator,
Tech
stack
is
so
important
in
this
context.
A
So
creating
evangelists
is
another
way
of
promoting
this
psychological
safety
aspect.
I
mentioned
earlier
within
teams.
It
allows
contributors
to
contribute
novel
concept,
I
know,
and
it's
such
an
important
thing,
to
allow
people
to
do
in
this
industry.
Allow
someone
to
take
the
reins
and
be
a
leader
and
to
be
a
thought
leader
within
an
organization
and
give
them
the
power
to
be
able
to
grow.
That
way,
it's
pretty
cool.
A
What
happens
when
you
do
that
next
is
to
decide
what
pieces
of
your
application
need
to
be
pre-existing
versus
dynamic
I
could
spend
hours
doing
a
lecture
on
Dynamic
configuration
management
and
the
declarative
application
model,
but
we
have
tons
of
resources
on
this
available
at
the
Humana
Tech
blog
that
you
can
review,
but
really
to
put
it
quite
simply,
we
need
to
determine
what
components
will
remain
agnostic
across
the
platform,
so
between
different
environments
and
different
workloads
and
which
will
be
dynamic
to
a
particular
workload,
to
a
particular
resource
or
to
a
particular
environment.
A
At
the
heart
of
this
we
have
the
platform
orchestrator,
which
is
what
Humana
Tech
is
that
mixes
and
matches
the
components
based
on
the
definitions
you
set
out
earlier,
so
the
applications
get
deployed
with
very
little
overhead
from
manual
input,
custom
automations
that
break
all
the
time,
yaml
dumping
and
exhausted
devops
Engineers,
who
have
been
absolutely
worn
down
by
ticket
ops.
So
that
is
kind
of
what
the
process
ends
up
looking
like,
and
it's
why
it's
so
important
to
actually
follow
this
declarative
application
model
and
the
idea
of
dynamic
configuration.
A
We
can
always
follow
up
with
some
great
resources
on
this.
If
it's
new
to
you
but
I,
thoroughly
encourage
you
to
check
it
out,
because
it's
pretty
special
and
really
helps
this
whole
Model
come
together,
all
right,
so
step
number
six.
Finally,
it's
time
to
start
building,
our
core
recommendations
are
as
follows:
so
build
something
that's
just
10
times
better,
even
if
it's
small,
we
all
know
that
iteration
is
the
key
to
engineering
and
platform.
Engineering
is
no
different,
we'll
go
into
this
a
little
bit
more
shortly
and
build
where
your
Roi
is.
A
This
comes
back
to
effective
prioritization
from
day
one.
So
don't
fall
for
that.
Prioritization
fallacy
understand
where
the
biggest
return
on
investment
is
going
to
be
for
putting
in
the
time
to
build
a
platform
spend
way
too
much
time.
On
the
first
build
out
of
your
platform,
a
solid,
concrete
foundation
will
hold
up
a
house
better
than
one
made
of
glass
and
paper
make
sure
it
is
solid,
concrete,
it's
earthquake
proof
and
it's
ready
to
grow.
On
top
of
also
make
your
evangelist
team
love.
A
It
they're
there
for
a
reason,
build
it
and
they
will
come
making
your
evangelist
team
fall
in
love
is
absolutely
key
to
adoption
of
platform
engineering
within
your
organization
and
the
benefits
I
mentioned
earlier
for
people.
It's
it's
one
of
the
most
challenging
Parts,
but
it
is
also
one
of
the
most
rewarding.
So
I
encourage
you
to
think
deeply
about
that
one
finally
step:
seven.
It
is
a
very
long
journey,
but
it
is
incredibly
rewarding
one.
A
So,
like
Bilbo
Baggins
said
it's
dangerous
business
Frodo
going
out
your
door,
but
the
door
in
this
case
and
following
the
journey
is
a
very
valuable
one,
not
just
from
a
financial
perspective,
but
from
a
human
perspective.
The
end
of
this
process,
your
developers,
are
engaged
and
happy.
Your
platform
team
is
a
group
of
folks
who
are
now
out
of
ticket
ops,
hell
they're,
focusing
on
the
more
important
aspects
of
their
roles
and
they're
growing
as
thought
leaders
within
their
organization.
We've
also
reduced
cognitive
load
and
increased
psychological
safety
for
everybody
in
the
engineering
organization.
A
Remember
iteration
will
always
win.
There's
a
strong
Community
behind
you
when
you're
starting
to
do
this
platform.
Engineering.Org
humanitech
is
here
as
well.
We
are
happy
to
discuss
this
philosophy
more
with
you,
but
we
also
have
platform
Con
coming
out
soon.
You
guys
can
start
signing
up
for
that.
Now
is
also
if
you're
interested.
In
speaking,
we
do
have
a
call
open
for
speakers
and
we
also
have
tons
of
platform
engineering
meetups,
so
I
encourage
you
to
get
involved
in
those.