►
From YouTube: A step by step guide to platforming your delivery setup
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
Really
quickly
about
me,
I
have
been
doing
platforming
for
the
last
10
years
I
am
working
with
and
on
the
communities,
internal
developer,
platform.org
platformengineering.org,
I'm
organizing
platform,
engineering,
slack
platform,
engineering
meetups
with
many
others,
obviously,
platform
com,
the
largest
conference
in
that
space,
and
I'm
also
working
with
the
team
at
humanitec,
a
platform
orchestrator.
A
A
The
benefits
of
this
are
pretty
obvious,
but
finding
that
starting
point
and
designing
your
journey
and
setting
yourself
up
to
success
is
non-trivial,
because
there
is
not
that
much
material
out
there,
and
I
want
to
make
a
small
contribution
to
this,
and
I
hope
I
can
help
you
on
your
path
now.
What's
the
actual
problem
statement,
let's
frame
this
problem
set
a
little
better.
A
But
that
makes
developers
drown
in
the
complexity
and
operations
as
well,
and
everybody
is
waiting
nobody's
really
making
any
progress
nobody's
really
satisfied
there
is
this
constant
tension
between?
Do
I
offload
too
much
to
my
engineers?
Do
I
shift
a
lot
of
things
left
or
do
I
abstract
them
from
stuff
which
works
which
takes
away
context?
That's
also
dangerous.
So
how
do
you
actually
navigate
in
this
uncertain
environment?
A
My
answer
is
you
build
platforms,
you
build
internal
developer
platforms,
because
these
platforms
help
application
developers
to
self-serve
things
without
waiting,
while
even
reducing
cognitive
load.
There's
no
value
in
shifting
things
left
when
the
person
on
the
receiving
end
of
that
shift
left
is
drowning
in
complexity
and
cannot
actually
do
the
job
that
she's
she's
paid
for
at
the
same
time
again,
you
want
to
do
that
without
abstracting.
It's
very
important,
I'm
always
comparing
that
to
natural
language
processing.
A
A
We
call
that
I
call
that
abstracting,
but
without
actually
taking
context
having
golden
paths,
you
can
rely
on
that's
platforming,
that
is
the
value
for
application
developers
and
for
the
platform
and
sre
and
devops
teams,
or
whatever
name
you're
using
these
days.
It's
about
driving
standardization
by
design.
It's
about
maybe
trying
to
prevent
180
different
ways
of
spinning
up
rds,
but
giving
these
five
ways
that
are
securely
vetted
and
work
well
and
setting
starting
points
from
which
the
teams
can
actually
expand
and
build
on,
and
it's
about
reducing
ticker
tops.
A
Many
of
you
are
in
a
situation
where
you're
bombarded
with
jira
tickets.
I
need
a
new
environment
here.
I
need
a
new
database
there.
Can
you
help
me
debug
that
deployment
that
is
not
very
productive?
We've
had
that
situation
throw
over
the
fence
operations.
If
you
want
a
decade
two
decades
ago,
it
is
not
something
that
we
want
to
go
back,
because
you
should
actually
be
able
to
focus.
You
should
able
to
focus
on
further
automation
on
making
sure
our
delivery
approach
is
secure.
A
A
Now,
a
mature
organization
would
tell
teams
to
build
a
car
and
they
would
give
them
the
credit
card,
and
they
would
tell
them
where
to
find
the
raw
materials
and
then,
if
teams,
struggle,
devops
helps
them
organize
and
cloud
operation
teams
helps
them
to
find
the
right
materials
and
then
prep
those
for
them
and
the
next
evolution.
You've
guessed
it
advanced
organization,
tell
teams
to
build
a
car,
and
then
the
platform
team
prepares
a
platform
and
the
developers
build
on
top.
A
A
It
is
the
sum
of
all
things
that
form
a
golden
path
for
developers,
one
that
developers
can
take,
but
they
don't
have
to.
They
can
deviate
from
that.
There
are
many
tools
these
days.
That
say,
we
are
an
out
of
the
box
idp
and
what
these
tools
actually
are
are
a
platform
as
a
service.
Think
of
it
like
heroku
a
platform,
an
internal
developer
platform
is
what
you
build
for
the
specific
needs
of
your
organization.
A
If
you're
looking
at
this
from
a
flow
perspective,
it
encompasses
your
ide
where
your
developer's
code,
that
is
then
connected
to
your
version
control
system.
Where
you
merge
your
code,
it
is
connected
to
your
ci
pipelines.
Where
we
build
to
your
registries,
then
you
might
be
using
something
like
a
cd
controller
or
more
modern
platforms,
maybe
a
platform
orchestrator
and
then
all
the
way
to
your
infrastructure.
All
of
that
is
part
of
your
platform,
and
then
there
are
many
interfaces
that
your
platform
might
have.
A
There
might
be
an
api
into
parts
of
the
controller
or
orchestrators.
It
might
be
fully
github
space,
it
might
be
a
ui,
it
might
be.
A
client
is
definitely
wired
up
with
your
observability
suite.
You
might
have
something
like
a
service,
catalog
or
portal,
such
as
backstage
or
x,
or
any
of
these
tools.
A
A
With
all
that,
with
all
of
this
new
information
thrown
at
you,
where
do
you
actually
start?
And
I
want
to
give
you
a
step-by-step
guide-
that
is
a
little
more
reduced
than
all
of
the
flood
of
information
that
is
usually
thrown
at
you?
Let's
actually
start
with
what
I
would
propose
you
do
as
a
step
number
one.
A
A
A
platform
can
start
very
small.
You
don't
have
to
start
with
a
big
bang,
so
maybe
you
don't
need
a
full-time
position
there,
but
you
want
to
have
somebody
who
makes
sure
that
there
is
a
road
map
and
then
there
are
user
interviews,
and
you
understand
that
you
have
users.
These
are
your
internal
developers
and
a
platform
team.
Has
software
engineers
people
that
actually
build
stuff?
It
is
not
enough
to
build
a
group
of
cultural
practitioners
and
call
it
a
platform
team.
You
want
to
have
people
that
actually
build
products.
A
Now
then
step
second
prioritize.
That
is
the
most
common
fallacy
that
I
see
in
platform
engineering.
I
wrote
a
long
article
around
this,
the
10
fallacies
of
platform
engineering,
that
I
encourage
you
to
have
a
look
at
as
well
prioritization
and
what
people
often
get
wrong
is
that
they
think
about
the
application
lifecycle
and
maybe
the
journey
of
a
developer
and
then
say
well,
why
don't
we
start
at
the
start?
A
All
of
these
things
sound
fairly
obvious,
but
just
because
something
is
at
the
beginning
doesn't
necessarily
mean
it's
actually
giving
you
the
return
on
investment
that
would
move
the
needle,
which
is
actually
what
you
want
with
a
platform.
A
platform
only
makes
sense
if
you
save
time
for
your
users
now
think
about
this
example:
optimizing
how
to
spin
up
a
microservice.
What
would
you
probably
do
you
would
set
a
baseline
microservice?
A
That
would
already
contain
the
way
you
want
to
have
a
python
flask
service
configured
and
then
you
might
want.
Then
you
would
maybe
build
because
you
think
that
looks
more
beautiful,
a
nice
ui
where
you
would
hit
a
button
and
it
would
clone
the
repository
and
maybe
run
a
pipeline
that
will
take
you
a
good
amount
of
time.
You'll
throw
together
an
angular
product
like
front
end
whatever,
and
it
will
feel
not
that
complex
for
the
start,
but
it
will
you'll.
Add
this
and
you'll
add
this
in
your
others.
A
A
How
often
do
you
do
things
that
go
beyond
the
static
case
of
updating
an
image
right
I
mean
for
updating
an
image.
Everything
is
in
place,
you
do
your
git
push,
your
ci
pipelines
runs
and
you
push
your
images
somewhere
and
you
update
your
power.
That's
probably
the
part
you
figured
out,
but
how
often
in
standardized
against
100
deployments,
do
we
do
things
that
go
beyond
the
simple
update
of
an
image
things
where
we
might
introduce
errors
where
we
might
need
the
help
of
others
where
having
a
golden
path
is
actually
great?
A
This
could
be
things
like
you
want
to
change
configurations.
You
want
to
change
the
architecture
you
want
to
onboard
a
new
colic.
You
want
a
refactor,
you
maybe
want
to
spin
up
a
new
microservice.
You
want
to
spin
up
a
new
environment.
You
want
to
roll
back
any
of
these
things.
How
often
do
you
do
them
so
here?
A
These
numbers
are
an
exercise
that
I
made
with
a
team,
a
team
that
was
fairly
fast
scaling
and
you
can
see
that
they're,
adding
an
environment
variable
every
20
deployments
and
then
all
of
that
and
they
need
a
new
environment
every
300
deployments.
All
of
that
doesn't
feel
like
a
lot,
but
then,
if
these
individual
things
happen,
they
eat
a
lot
of
time
from
development
and
a
lot
of
time
from
operations
teams.
A
Now,
if
you
add
all
of
that
up,
you'll
come
up
with
a
pretty
considerable
amount
of
time
that
is
wasted
on
just
these
things
that
go
beyond
the
simple
update
of
an
image.
It's
almost
like
a
hockey
stick
function.
Everything
is
fine,
everything
is
fine,
and
then,
if
you
do
these
things
that
go
beyond
the
update
of
an
image,
you
actually
produce
a
huge
amount
of
overhead
and
cost
now
do
that
exercise.
A
A
A
We
don't
support
you
you're
on
pager
duty
and
you
have
to
deal
with
the
consequences
now,
whatever
you
come
up
with,
stick
to
it,
it's
very
likely
that
you're
going
to
standardize
on
containers
and
kubernetes
and
one
or
two
managed
providers
and
a
couple
of
databases,
but
find
that
lowest
common
denominator
and
the
smaller
you
make
your
tech
stack,
the
better
you
will
actually
do
as
the
platform
team.
You
have
a
very
high
interest
on
keeping
your
tax
deck.
A
One
of
the
fallacies
that
I'm
seeing
is
that
people
want
to
do
this
big
bang.
They
want
to
do
everything
at
once.
I
call
it
the
everything
at
once
fallacy,
not
a
very
good
idea,
identify
this
one
team
that
is
bursting
from
joy
of
doing
something,
innovative
that
really
feel
the
pain
that
want
to
get
better.
A
A
A
You
are
building
what
we
call
a
declarative
application
model
like
a
baking
recipe
on
how
your
application
should
look
like
across
all
environments,
and
they
are
then
taking
that
declarative
application
model
and
execute
this
against
a
platform.
Orchestrator
which
reads
this
model
and
creates
a
dynamic
dynamically,
creates
a
representation
of
this
configuration
and
actually
deploys
that
as
an
application
into
your
infrastructure.
A
A
That
is
a
static
configuration
management,
and
that
means
you
have
your
workload
and
you
have
static
yaml
files
per
environment,
and
then
you
have
static
infrastructures,
code
elements
and,
and
you
have
a
cd
controller
like
an
argo
cd,
that's
just
taking
these
files
and
syncing
them
with
your
with
with
the
infrastructure.
A
A
It
has
to
fit
to
your
team
of
evangelists
right,
the
folks
that
are
that
love
you
so
much
or
are
supposed
to
love
you
so
much,
and
it
has
to
be
on
your
lowest
common
denominator,
techstick,
and
then
you
want
to
build
an
experience
that
is
10x
better
than
what
everything
anything
that
your
team
has
seen
before.
Many
of
these
platforms
fail
because
they
promise
a
lot
and
what
they
deliver.
A
As
the
future
platform
is
even
has
more
edges
and
is
more
raw
and
is,
is
not
actually
making
a
difference
for
the
individual
contributor,
I
call
that
the
tragedy
of
the
commons
problem
right.
It's
like
climate
change.
If
you
build
something,
that's
great
for
the
organization,
but
it
doesn't
move
the
needle
for
the
individual
contributor
nobody's
gonna
use
it
right.
You
win
nothing.
A
On
this
first
project,
I
encourage
you
to
spend
way
too
much
time
way
too
much
time
over
allocate
too
much
time
in
getting
this
one
thing
to
a
degree
where
people
look
at
this
and
say
wow.
This
is
really
nice,
that's
10x
better
than
what
we've
been
using
before
and
then
make
sure
your
evangelist
team
loves
it,
because
only
if
they
love
it,
they
will
do
something
that
will
make
you
long-term
successful.
They
will
go
to
all
of
their
colleagues
in
the
organization
and
say:
hey
we're
using
this
product.
Now
we're
using
this
platform.
A
A
A
When
you
have
your
first
project
and
that
is
10x
better,
even
if
it's
only
doing
this
tiny
little
thing
getting
you
a
new
namespace
better
than
what
you
had
before,
then
you
take
the
next
approach
and
you
again
look
at
your
arrow.
I
and
you
again
do
user
interviews
and
you
again
treat
your
platform
as
a
product
and
again
you're,
going
into
the
details
and
you're
figuring
out.
What
are
you?
A
What
what's
the
next
best
thing
to
work
on
and
yours
continue
building
golden
paths
you
continue
winning
over
the
evangelists
that
then
create
a
pull
factor.
That
is
the
way
how
you
make
platforming
and
building
an
internal
developer
platform
long
term
successful,
there's
also
a
growing
community
of
practitioners
around
platforming
you're,
not
alone.
With
this,
there
are
channels
just
for
product
owners
of
platforms.
There
are
even
job
boards
just
for
platform
engineers,
there's
a
very
vivid
conversation
going
on.
A
We
have
platform
con
coming
up
thousands
of
fellow
platform,
engineers
or
people
that
are
interested
to
doing
that
or
becoming
such
joining
us
on
the
I
think,
9th
and
10th
of
june
2022,
and
I
encourage
you
to
take
part
in
that
as
well.
There
are
platform
engineering
meetups,
I'm
sure
there
is
one
next
to
you
or
you
can
start
your
own
and
there
are
learning
materials
on
sites
like
platformengineering.org.
A
I
encourage
you
to
become
part
of
this
community
to
to
join
me
in
in
yeah
and
taking
this
category
and
taking
this
way
of
working
forward.
I
am
convinced
that
in
five
years
almost
every
team
has
these
platforms,
and
I
would
also
encourage
you
to
get
in
touch
with
me
and
let's
chat
about
these
things.
Ask
me
questions.
I'm
always
happy
to
help.
A
I'm
personally
working
on
humanitarian
and
with
humanity,
tech
and
humanity
is
a
platform
orchestrator
that
is
optimized
for
dynamic
internal
developer
platforms.
It's
a
component
that
can
help
you
build
reliable
platforms
that
developers
laugh
really
fast
and
it's
fairly
widely
used.
If
there
is
anything
I
can
show
you
around,
that
also
feel
free
to
reach
out.
For
now,
thank
you
so
much
for
listening
to
that
talk.
I
hope
to
see
you
soon
online
or
offline.