►
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
Hey
everybody.
Welcome
to
this
online
event
with
cncf.
We
are
going
to
speak
about
the
10
fallacies
in
platform,
engineering,
I'm,
kaspa
I'm,
the
CEO
of
humanitek
humanity.
Tech
is
a
platform
orchestrator
that
helps
many
teams
across
the
world,
build
their
internal
developer
platform,
orchestrating
application
and
infrastructure
or
configurations
I
encourage
you
to
get
in
touch
with
me.
I
love
debating
all
things:
Cloud
native
and
platform
engineering.
A
My
Twitter
is
Casper
official
and
my
email
is
cuspa
humanitake.com,
so
I'm
looking
forward
to
hearing
from
you
in
today's
talk,
we
are
going
to
briefly
cover
what
we
actually
mean.
If
we
speak
about
platforming,
about
platform
engineering
and
about
internal
developer
Platforms
in
particular,
and
we're
going
to
cover
the
top
10
fallacies
that
we
are
observing
in
platform,
engineering
I've
been
active
in
that
space
for
10
years
now,
I've
seen
many
many
many
teams
across
Atlanta,
Enterprises
and
scale
UPS.
A
Let's
actually
start
by
understanding
what
the
underlying
problem
is.
If
you
compare
the
applications
that
we're
building
today
with
the
applications
that
we
built
10
years
ago,
then
you
can
see
that
the
average
application
has
25
times
more
component
Services
resources
than
an
application
had
in
2010..
We
have
five
times
the
amount
of
specialized
tools.
The
digital
Factory,
if
you
want,
is
much
more
diverse,
much
more
tailored
two
specific
use
cases,
then
the
factory
floor
that
we
were
confronted
with
10
years
ago
and
the
ever
evolving
global
environment
really
drives
demand
and
complexity.
A
Today,
we're
shipping
applications
across
the
globe
with
vast
amounts
of
users
across
different
time
zones
with
huge
amount
of
traffic
because
of
that
teams
weighs
to
25
of
their
time
operating
applications.
As
the
complexity
increases
our
current
approach
to
trying
to
control
this
chaos
is
manual,
work
and
scripts.
A
The
current
pain
point
is,
and
second
the
second
Persona
that
we
are
speaking
about
here
is
the
platform
team
or
the
SRE
devops
Ops
Team,
whomever
you'd,
be
you
whatever
name.
Your
organization
is
currently
using
now
they
are
concerned
with
driving
standardization
by
Design,
reducing
ticket,
ops
and,
ultimately,
focusing
on
improving
the
status
quo,
rather
than
reacting
to
repetitive
requests
from
their
engineering
team
and
these
platform
Engineers
they
build
internal
developer
platforms.
A
An
internal
developer
platform
is
the
sum
of
many
components
that
form
a
golden
path
for
developers
to
enable
self-service
with
low
cognitive
load.
There
isn't
the
internal
developer
platform,
and
that
is
frustrating
for
many
people
that
ask
me
hey.
What's
an
internal
developer
platform,
the
platform
at
a
global
bank
will
look
very
different
to
the
platform
at
a
scale
up
in
San
Francisco,
and
that
me-
and
that
means
we
much
rather
have
to
look
at
what
are
the
building
blocks,
that
we
see
platforms
used
and
put
together
together
today.
A
The
modern,
dynamic
internal
developer
platform
from
a
flow
perspective
could
be
an
IDE
to
code
Version
Control,
to
merge
an
ECI
to
build
in
many
organizations.
We
have
many
different
components,
then
a
platform
orchestrator
to
actually
orchestrate
the
infrastructure
and
application
configurations,
and
you
have
different
interfaces
into
these
platforms.
It
could
be
an
API
git,
Ops
click,
Ops,
CLI,
observability
service,
catalogs
portals
the
Lena
X
campus
backstage
of
this
world.
That's
platform
engineering
that
is
internal
developer
platforms.
A
I'll,
give
you
a
couple
of
links
about
this
ever
growing
Community
around
platform
engineering
later
so
as
we're
now
actually
starting
to
platform
the
digital
world.
We
are
seeing
these
the
we
are
seeing
more
on
more
consistent
fallacies
that
teams
run
into
and
fall
for,
and
I
now
actually
want
to
guide
you
through
the
most
common
ones.
That
I
see
number
one.
Is
the
prioritization
fallacy
you're
starting
your
platforming
journey?
You?
A
You
are
convinced
that
hey
that's
exactly!
We
have
to
take
control
of
our
platform,
otherwise
the
platform
will
build
itself
and
we
want
to
now.
Actually,
you
know
build
our
first
golden
path,
reduce
cognitive
load
for
our
developers.
Now,
how
do
we
choose
where
to
start?
There
are
so
many
elements
we
could
look
at
configuration
management.
We
could
look
at
the
onboarding
experience
of
a
developer.
We
could
look
for
the
we
can
optimize
for
the
creation
of
a
new
service.
A
A
A
I
always
recommend
the
following
exercise
as
you're
looking
to
prioritize.
Take
a
blank
piece
of
paper
now
go
ahead
and
ask
yourself
what
are
the
things
that
developers
do
on
a
daily
basis
that
go
beyond
the
simple
update
of
an
image
just
list
those
things
that
could
be
adding
an
environment
variable,
adding
services
or
dependencies
refactoring,
changing
resources
waiting
due
to
blocked
environments,
spinning
up
environments,
onboarding
developers,
scaffolding,
new
microservices?
All
of
these
things
once
that
is
done
list.
How
often
you
do
that
and
standardize
this
against
100
deployments
so
100
deployments?
A
How
often
do
you
do
things
like
adding
a
new
environment
variable
then
list
the
developer
time,
so
the
time
developer
spend
per
individual
action
and
the
time
that
operation
spends
per
individual
action
and
once
this
is
done
actually
compute.
The
numbers
against
your
total
numbers
of
deployment,
and
you
have
your
prioritization-
follow
that
prioritization,
because
it
will
actually
ultimately
give
you
a
feeling
for
what
your
return
on
investment
on
your
platforming
Endeavor
will
be.
A
A
A
A
A
A
A
If
a
team
is
working
in
Jenkins
pipelines
and
they
do
the
job
and
all
of
their
tests,
all
of
their
things,
all
of
their
scripts
are
in
Jenkins
pipelines,
and
it
works
well
or
even
okay
is
the
biggest
impact
you
can
do
actually
standardizing
and
taking
things
away
from
teams
that
they're
used
to
maybe-
and
maybe
not,
if
you
think
you
will
meet
resistance
from
the
from
the
engineering
team
and
from
the
Developers
and
you
think
hey.
This
will
be
a
little
bit
of
a
war
to
actually
fight
this
through.
A
A
A
The
fourth
thing
is
the
everything
and
everybody
at
once-
fallacy
the
I'm,
often
seeing
platform
engineers
at
the
start
of
their
journey,
and
they
have
these
crazy
ideas
and
dreams
of
what
the
platform
could
do
and
they're
sitting
in
in
planning
meetings,
and
they
they
are
coming
up
with
this
creature.
That
can
you
know,
solve
all
problems
and
deal
with
all
Technologies
in
German
we
say
an
I
am
a
league,
so
that
means
a
sheep
that
can.
A
That
is
also
opaque,
but
it
can
also,
you
know,
lay
eggs
and
you
and
it
will
also
provide
milk
there's.
Obviously,
a
creature
that
doesn't
exist,
and
so
the
of
a
fallacy
that
is
really
we
really
have
to
be
aware
of
is
a
is
the
everything
and
everybody
at
one's
fallacy,
and
you
mitigate
that
by
again,
obviously
prioritizing,
but
also
by
starting
with
small
units.
A
Small
units
means
small
unit
means
you
are
looking
at
a
lighthouse
application
and
the
application
developers
in
that
Lighthouse
application,
and
you
are
just
focusing
on
that
subgroup.
That
subgroup
is
hopefully
on
the.
What
I
would
refer
to
as
the
lowest
common
denominator
of
your
technology
and
especially
of
your
future
technology
stack.
So
if
you're
saying
in
the
future,
we
are
going
to
standardize
on
and
I'm
just
making
something
up,
containers
and
kubernetes
and
that
subset
of
databases
you
want
that
initial
application
unit
to
be
representative
of
that
lowest
common
denominator.
A
You
want
to
focus
on
a
specific
set
of
Technologies
on
a
specific
type
of
future
approved
application
design
and
on
and
an
application
team
that
you
can
turn
into
evangelists,
and
then
you
want
to
prioritize,
and
you
want
to
look
at
the
smallest
little
thing
that
you
can
do
for
them.
That
has
a
large
impact,
and
then
you
want
to
iterate
and
iterate
and
iterate
there
is
this
quote
from
Paul
Graham
that
I
really
enjoy.
A
That
means
that
says,
do
small
things
that
don't
scale
for
to
start
with,
and
that's
exactly
what
you
need
to
do
right
here.
What
are
the
small
things
you
can
do?
They
don't
have
to
scale
yet,
but
that
really
will
make
this
team
fall
in
love
with
your
platform,
one
with
your
general
approach
of
platform
engineering,
because
these
people
will
be
your
evangelists
and
they
will
be
your
advocates.
A
The
next
fallacy
is
the
new
setup,
isn't
better
fallacy
and
that's
it.
It
ties
into
the
previous
fallacy.
If
you
are,
you
know
again
you're
sitting
in
a
room
and
you're
building
something
really
complex
and
then
you're
coming
out
into
the
world,
with
a
big
bang
and
you're
really
proud
of
what
you've
achieved,
and
it's
just
not
better
than
what's
already
there
and
what
people
are
already
used
to.
A
Then
you
will
not
find
any
adoption,
which
is
why
it's
so
important
that
you
start
small
and
that
you
iterate,
and
that
you
continuously
actually
treat
this
product,
treat
this
platform
as
a
product,
a
product
that
has
a
product
manager
and
a
jira
board
and
users
and
interviews.
You
do
to
really
come
up
with
something
that
is
better
and
better
doesn't
mean
larger,
it
doesn't
mean,
has
more
functionality.
A
The
sixth
one
that
is
very
dear
to
my
heart
is
the
abstraction
fallacy,
especially
in
the
2010s.
Many
teams
built
platforms
that
abstracted
developers
away
from
from
something
from
underlying
systems
or
that
took
away
context.
That
is
something
that
you
cannot
do.
It
cannot
happen.
It
is
very
important
that
developers
at
every
point
in
time
can
actually
understand
the
underlying
systems.
A
Can
dive
deep
can
gain
all
context
down
to
the
terraform
level
if
you
want
so,
if
you
give
them
a
CLI,
that
just
gives
them
an
S3
bucket
and
they
don't
know
how
it's
configured
or
how
it
was
specifically
set
up.
You're,
probably
not
really
helping
them,
and
even
if
what
you've
provided
for
some
reason
is
the
right
thing.
They
will
still
mistrust
and
that
will
ultimately
limit
adoption,
and
you
will
not
be
successful.
A
The
seventh
is
the
loudest
voice.
Fallacy
I
already
hinted
at
that.
I
dearly
recommend
treating
your
platform
as
a
product
team
topologies.
They
said
it
over
and
over
again,
but
it's
so
important,
and
if
you
treat
your
platform
as
a
product,
you
will
need
to
make
to
do
user
research
and
more
and
more
platform.
A
Engineers
are
actually
doing
this
and
if
you
are
doing
research,
be
aware
of
the
loudest
voice
fallacy,
if
you
have
your
annual
hackathon
and
you're
sitting
in
a
room
with
all
your
engineers,
there
are
the
Linux
kernel
hackers
in
there
there
is
the
junior.
There
is
the
mid-level
developer
and
you
ask
them
hey.
How
do
you
want
to
have
this
platform
designed?
A
Who
is
the
person
you
think
that
is
actually
going
to
drive
that
user
research?
Well,
it
will
probably
be
the
Linux
kernel
hacker
because
they
are
the
most
self-confident
and
they
will
want
to
go
low
level
and
you
will.
They
will
always
work
on
driving
the
platform
to
be
maybe
a
little
bit
too
complex.
A
The
next
one
is
the
freedom
fallacy,
and
that
is
slightly
contradicting
what
I
told
you
before
the
it
is
very
important
that
the
developers
can
go
under
the
hood
and
they
can
leave
the
golden
path
and
they're
not
abstracted
away,
but
that
doesn't
mean
that
we
need
to
end
up
with
a
stack
that
has
700
different
flavors
on
how
to
create
an
RDS
instance.
There
is
value
in
standardization
standardization,
not
at
the
risk
of
abstraction
standardization,
not
in
a
way
that
we
slow
anybody
down.
A
But
if
you
let
everything
you
allow
everything
to
happen,
every
cloud
every
product,
every
convention,
then
this
will
significantly
slow
you
down
and
so
I
encourage
you
to
have
a
conversation
with
the
team
about
the
value
of
a
certain
level
of
standardization,
a
certain
lowest
common
Tech
denominator.
Does
that
mean
you
cannot
use
the
fancy
Lambda
function?
No,
obviously
you
can.
But
the
question
is:
how
is
everybody
conscious
of
balancing
the
complexity
that
we're
driving
versus
the
actual
outcome
that
we
want
to
reach.
A
The
Google
Facebook
Netflix
fallacy
is
an
obvious
one
that
I
dearly
love,
but
it's
one
that
we
all
run
into
all
the
time.
All
of
the
HR
teams
at
these
companies
have
the
mandate
to
explain
how
amazing
their
engineering
organization
really
is,
and
that
means
the
engineers
at
these
companies
they
go
out
and
they
speak
about
the
practices
and
how
Netflix
is
doing
things
and
how
great
everything
is
and
how
much
resources
they
have.
A
If
you
listen
to
them
too
much,
you
will
probably
not
become
very
happy,
because
neither
you
nor
me
actually
have
the
resources,
the
money
or
the
head
count
to
pull
off
what
these
companies
can
pull
off.
And
if
you
follow
this
too
thoroughly
and
you
get
Blended
too
much
by,
they
are
frankly
HR
content.
A
You
might
actually
make
very
costly
decisions
that
will
hurt
your
productivity
and,
last
but
not
least,
the
compete
with
Amazon
web
services
fallacy
if
there
is
something
that
you
can
get
from
a
like
from
an
from
an
Amazon,
really
that
they
have
50
developers
focused
on
for
three
years:
don't
compete
with
them.
The
job
of
a
platform
engineer
is
to
bind
the
different
Tools
in
a
consistent
experience.
That
means
our
focus
is
much
rather
the
glue
between
these
systems
and
not
actually
competing
with
those
tools
themselves.
A
We
really
always
have
to
ask
ourselves:
is
the
you
know
the
the
time
and
the
Innovation
capacity
we're
putting
in
there
that
that
is
actually
keeping
us
away
from
doing
other
things
that
helps
help
the
business?
Is
that
actually
going
to
pay
off
all
right?
And
with
that?
Thank
you
very
much
for
listening
to
this
conversation.
I
hope
you
took
something
away.
A
I
encourage
you
to
check
out
the
platform
engineering
community
that
is
platformengineering.org
the
platform,
engineering,
slack
group
platform,
engineering,
meetup
groups
in
many
cities
in
North,
America
Europe
and
the
Pacific
region
platform
con
a
conference.
This
is
a
very
fast
growing,
healthy
Community.
If
you
have
any
questions
reach
out
to
me,
I'm
very
much
looking
forward
to
debating
this
topic.
That's
very
dear
to
my
heart.