►
From YouTube: Driving Adoption of your Backstage IDP
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
Hey
everybody
welcome
to
this
webinar.
You
have
heard
of
Backstage.
Perhaps
you
have
even
already
set
up
a
POC
of
your
developer
portal
using
backstage
now.
The
next
crucial
question
is:
how
do
I
make
my
developers
use
it?
I
am
your
host
Jorge
Le
Fiesta,
author
of
The,
Linux
Foundation,
introduction
to
Backstage
certified
familiar
and
I
work
at
brody.io
Backstage
as
a
service
and
to
address
the
present
topic
of
adoption.
I
have
here
with
me
to
experts
who
have
succeeded
at
widespread
in
their
backstage
instance
within
the
organization.
A
B
A
C
C
We've
been
using
backstage
for
about
a
year,
we've
been
we've
been
seeing
it
on
a
lot
of
you
know:
circling
the
internet,
circling
a
developer
experience
conferences,
and
you
know
it's
one
of
the
things
that
we
wanted
to
to
try
and
Tackle
ourselves
with
the
large
engineering
organizations.
So
we've
been
leveraging
Roadie
for
about
almost
a
year
now-
and
it's
been,
it's
been
great-
it's
been
a
great
journey.
A
B
So
yeah
I
I
can
go
ahead
and
start
so
right
now
we
are
approximately
120
full-time
developers
at
lunar
and
I
would
say
all
of
them
uses
backstage
I
just
had
a
look
at
our
Google
analytics
from
the
past
couple
of
months
and
I
see
that
we
have
around
60
unique
users
every
week.
So
it's
a
everybody
is
sort
of
getting
in
there
from
time
to
time,
depending
on,
of
course,
what
tasks
they
have
but
we'll
come
back
to
that
later.
C
Yeah
and
then
on
our
side,
I
I
think
I've,
seen
about
a
hundred
unique
users
week
over
week
with
about
almost
I,
think
we're
approaching,
like
400
total
contributing
users
in
our
in
our
backstage
instance.
So
you
know
we're
trying
to
get
more
get
more
usage
out
of
it,
but
trying
to
prevent
those
those
use
cases
where
teams
are
fine,
you're,
invaluable
and
organically
kind
of
get
them
in
there
day
after
day.
So,
like
I,
said
it's
a
journey
yeah.
A
C
Wanna
I
can
I,
can
I
can
take
this
one.
So
so
we've
kind
of
seen
usage
vary
across.
You
know,
team
to
team,
depending
on
you
know
how
they
want
to
use
it
and
and
and
leverage
backstage
what
what
I've
kind
of
seen
is
teams
that
have
been
more
regularly
using
it
like
really
like
to
Leverage
The
Tech
talks
functionality
and
having
their
docs
live
alongside
the
code
as
well.
C
As
you
know,
the
workflows
that
that
live
alongside
with
it
in
the
in
the
in
the
code
itself,
it
makes
managing
it
a
lot
easier
having
it
every
everything
in
one
place
and
then,
of
course,
the
the
tech
talk
renders
you
know
nicely
in
in
backstage,
and
then
that
content
is
searchable.
C
We
we
typically
you
know,
pre,
have
a
lot
of
our
documentation
stored
in
Confluence
and
that
information
can
get
outdated
very
quickly.
You
know
people,
you
know
either
copy
something
slightly
modify
it
and
then
someone
you
know
later
down.
The
road
comes
searching
for
that
document,
which
has
the
same
title.
All
those
things
can
add
to
cognitive
load
because
they
aren't
sure
which
one
they
should
be
reading.
B
C
That
one,
the
right
one
and
then
you're
kind
of
looking
at
like
when
was
it
last
edited,
so
there's
really
no
good.
There
was
no
really
great
place
to
really
understand.
Where
is
the
formalized
documentation
for
the
systems
that
I
am
looking
for?
Information
for
and
and
backstage
is
a
really
good
way
to
kind
of
make
that
that
formalized
documentation
live
and
then
another
kind
of
use
case
that
I've
really
seen
people
get
excited
about
when
we
show
them
off
backstage
and
generate
a
lot
of
excitement.
C
Is
software
templates
and
I
can
probably
get
into
that
afterwards,
but
we've
definitely
seen
a
lot
of
kind
of
interest
and
software
templates
at
our
organization.
B
Yeah
I
can
definitely
relate
to
the
to
to
documentation
and
Conference
being
like
a
pain
for
developers
just
having
it
decouple
from
where
you
work
and
not
having
your
standard
tools
available,
not
being
able
to
write
in
markdown
or
whatever
you
prefer
as
a
developer
is,
has
been
a
really
big
pain.
We
before
we
found
backstage
researched
for
markdown
documentation
Pages.
We
were
also
on
conference
and
didn't
really
find
the
good
solution
until
we
saw
backstage
we.
That
was
one
of
the
selling
points
of
our
adoption.
B
Is
that
now
we
can
actually
co-locate
everything
within
the
repository
so
that
we
can
provide
a
really
nice
developer
workflow
so
that
they
don't
have
to
go
into
multiple
different
places.
They
can
just
sit
in
the
git
repository
and
do
whatever
they
need
to
do.
Write
that
code
write
a
documentation
and
everything
should
be
centered
around
that
repository,
so
that
was
at
least
one
of
the
the
reason
for
why
we
adopted
the
backstage
in
in
the
beginning.
B
We've
also
have
a
lot
of
developers
visiting
our
backstage
installation
due
to
the
fact
that
we've
been
building
a
lot
of
plugins
ourselves.
It's
actually
been
like
a
an
inner
sourcing
movement
within
lunar,
so
it's
actually
one
of
the
the
two
most
used.
Plugins
is
actually
something
that's
not
coming
out
of
the
the
centralized
platform
team,
it's
more
developers
that
saw
a
need
for
creating
a
plugin
that
solved
a
particular
problem.
One
of
these
problems
was
they
needed
a
front
end
for
doing
reconstitutions.
B
So
whenever
a
new
service
needed
to
be
spun
up
and
needed
to
get
events
from
a
certain
time
in
order
to
populate
its
new
database
or
whatever,
so
we
actually
had
a
squad
that
built
out
a
plug-in
for
for
doing
pre-constitutions
to
our
rapid
installation,
which
is
now
being
used
widely
at
lunar.
We
also
have
a
dead
lettered
plug-in
that
basically
developers
use
to
handle
whenever
a
message
it's
not
or
an
event,
is
not
able
to
be
delivered
to
some
service.
B
For
some
reason
it
ends
up
in
this
queue
that
developers
can
inspect
figure
out.
What
is
wrong
and
resend
the
events?
If,
if
that's
the,
is
what
they
want
to
do
or
just
discard
them
so
getting
a
UI
for
for
some
of
the
things
that
are
really
critical
to
to
our
developers.
Workflows
has
been
one
of
the
ways
we
sort
of
get
a
lot
of
developers
in
there,
because
now
they
prefer
to
do
it
using
this
UI.
B
That's
now
been
built,
so
that's
at
least
two
of
the
things,
and
maybe
you
can
continue
on
the
the
scaffolder
and
and
the
templates,
because
that's
also
a
thing
that
I
can
comment
on
afterwards,
then
because
we
also
use
that
or
not.
C
Yeah,
yeah
and
and
like
when
we
show
off
our
the
kind
of
like
the
first
template
that
we
built,
especially
to
like
the
platform
teams
that
are
building
kind
of
like
the
foundations
and
the
tools
that
other
engineering
teams
use
you
can.
You
can
really
see
start
seeing
the
wheels
spinning
like
oh,
how
could
I
use
this
ooh
like
I?
Have
this
workflow
that
and
and
so
like.
C
As
an
example,
we
had
a
process
that
was
taking
engineering
teams
about
six
to
eight
weeks
to
build
a
new
microservice
without
even
being
able
to
work
like
on
the
actual
business
logic
of
their
service.
This
was
just
a
process
that
kind
of
involved.
You
know
multiple
tickets
to
different
teams
manually,
creating
resources
in
certain
places.
Getting
you
know
that
repo
set
up
with
that
that
boilerplate
code
and
setting
up
your
CI
CD,
workflows
security
and
compliance
stuff.
All
these
things
took
time
and
each
one
of
them
had
a.
C
You
know
a
chunk
of
lead
time
that
added
up
whether
it
was
in
like
you
know,
planning
sessions
or
refinements.
All
these
things
had
a
different
kind
of
onboarding
document.
They
needed
to
read
they
needed
to
familiarize
themselves
with
they
needed
to
interact
with
a
different
team.
C
If
there
was
questions
that
were
open,
they
had
to
conduct
a
spike,
a
whole
host
of
things
and
then,
on
top
of
all
that,
there's
a
number
of
manual
steps
you
had
to
go
through
and
then
you
know
there's
a
chance
that
you
miss
one
of
those
steps.
All
that
adds
up,
and
you
multiply
that
across
you
know
a
50
60
70
engineering
teams
that
are
that
are
going
through
the
process
and
it
was
really
slowing
us
down,
and
so
what
we
essentially
did
is
we
looked
at
that
entire
process
and
identified?
C
Where
are
all
these
manual
steps?
What
are
each
step
that
these
developers
have
to
go
through
in
that
process?
And
what
can
we
automate
away?
What
can
we
eliminate?
What
can
we
abstract
away
and
bundle
it
into
that
template,
and
so
now
all
they
have
to
do
is
enter
in
those
handful
of
parameters
that
we've
defined,
that
are
that
are
important
and
critical
to
to
spinning
up
that
service
and
now
something
that
took
six
to
eight
weeks.
C
They
can
have
a
micro
service
kind
of
endpoint
live
like
that
hello,
world
endpoint
live
within
like
15
minutes
right
and
so
that
that
process
is
much
more
simplified.
There's
you
know,
obviously
things
that
we're
still
working
through
and
and
we're
learning
the
best
way
to
kind
of
manage
it.
But
it's
really
like
the
first
use
case
that
was
really
eye-opening
to
to
the
value
that
the
developer
portal
can
provide,
especially
with
like
a
larger
engineering
organization.
C
There's
a
lot
of
complexities
that
you
have
to
deal
with
compliance
regulations,
those
kinds
of
things
and-
and
so
it
just
manage
it.
Balancing
all
that
and
simplifying.
It
is
really
a
huge
benefit
to
those
developers,
because
there's
so
much
complexity
that
they
have
to
like
navigate
on
a
daily
basis,
and
if
you
can
make
that
a
lot
simpler
for
them
and
and
give
them
a
lot
of
that
tooling
out
of
the
box.
C
So
they
can
focus
on
building
out
that
new
feature
for
the
customer
and
and
reinvest
that
time
and
whether
it's
learning
opportunities.
You
know
different.
You
know
hygiene
code,
hygiene,
documentation,
making
sure
that,
if
you're
having
your
documentation
well
well
thought
out,
those
kinds
of
things
was
usually
an
afterthought
right.
It's
usually
something
that
comes
after
you
get
everything
done
and
you
got
to
move
quickly,
but
now
that
time
can
be
reinvested
in
those
areas
which
is
which
is
amazing
and
I.
C
B
Yeah
I
can
definitely
relate
to
that
as
well.
We've
also
been
been
using
the
scaffold
and
all
the
templates
for
for
quite
a
while,
now
and
and
all
the
things
you
mentioned
is,
is
also
what
we
have
been
seeing
that
we,
we
also
had
like
a
a
process
that
required
a
lot
of
manual
steps.
You
need
to
create
a
Docker
registry.
C
B
You
need
to
go
in
and
do
this
and
this
and
this
in
order
to
get
a
database
and
all
those
things.
Now
it's
it's
a
matter
of
filling
out
a
form
of
I
think
it's
five
steps
or
something
five
Fields.
You
need
to
put
in
some
some
stuff
and
get
a
lot
of
data
using
GitHub
as
well
to
sort
of
fetch
what
teams
are
available.
B
Even
build
something
where
you
can
basically
click
a
box
that
say:
do
we
want
to
have
your
service
deployed
directly
to
production
and
you
can
click
that
box
and
if
you
do
that-
and
you
create
a
repository
like
you
also
said,
like
I
had
a
simple
application
will
be
built,
it
will
be
released
and
you
will
have
an
endpoint
depending
on
endpoint,
in
our
case,
ready
to
to
go
so
for
for
for
developer.
That
means
that
everything
is
just
set
up
for
them.
Everything
is
ready.
They
are
everything
is
instrumented.
B
The
repo
is
configured
using
best
practices,
it's
compliant
and
we've
enforced.
You
know
Revenue
Branch
protection
we
enforce
signed
commits
all
of
those
things
are
just
set
up
from
the
get-go,
so
developers
don't
have
to
think
about
any
of
those
things.
It's
it's
just
stock
coding
and
solve
the
problem
that
you
need
to
solve
in
order
to
yeah
fulfill
the
the
business
values
of
whatever
you're
doing.
B
We
also
seen
so
so
we
started
out
very
simple,
microservice
setup
using
a
template,
but
now
we
have
15
or
something
different
templates.
So
we
have
docs
templates.
We
have
CLI
templates.
We
have
microservices
templates,
we
even
have
we
use
a
Robot
Framework
to
automate
some
tasks
in
all
systems,
so
we
even
have
like
a
template
for
how
you
create
a
robot
to
actually
you
know
press
the
buttons
in
in
in
these
old
systems.
B
That
is
completely
controlled
through
the
process
that
we
enforce
using
using
backstage,
which
is
super
nice
as
a
financial
substitution
that
we
can,
you
know,
check
those
boxes
and
then
we
are
now
compounding
in
this
regard
as
well.
B
Use
Tech
insights
to
to
sort
of
provide
some
some
features
on,
or
some
some
insights
for
developers
in
2R.
We
actually
following
the
right
processes.
Is
things
configured
as
it's
supposed
to
so
you
sort
of
get.
You
know
the
green
check
mark
everything
looks
good
I'm
good
to
go.
C
B
Have
like
Squad
pages,
so
every
team
has
like
a
page
that
sort
of
provide
the
most
interesting
stuff
for
them.
Usually
that
consists
of
the
GitHub
pull
request,
plugin,
which
is
pretty
nice,
so
they
get
that
from
the
entire
Squad,
something
that's
that's
what's
relevant
to
them,
but
also
if
they
have
their
letter
messages
for
some
of
their
services
or,
if
they're
missing,
to
set
a
domain,
for
example
on
particular
services
or
whatever
it
might
be.
B
You
just
you
know,
surface
all
the
important
stuff
on
the
overview
page
or
the
team
page,
so
they
actually
use
that
in
in
the
daily
work,
which
is
nice
and
and
the
last
thing
that
we
sort
of
seen
when
you
get
this
software
or
catalog
and
everything
up
and
running,
we
also
have
a
lot
of
other
stakeholders
Now
using
backstage
for
for
other
things.
B
B
Basically,
our
software
assets-
this
is
the
create
calendar
that
this
domain
has,
which
means
that
if
something
goes
wrong,
it's
on
call
that
will
be
triggered.
So
all
of
these
things
are
sort
of
being
visualized
and
and
also
used
in
backstage,
to
also
tell
that
story
to
to
other
stakeholders
than
just
Developers.
B
A
That's
certainly
quite
impressive.
You've
gone
a
long
way
to
be
able
to
stop
like
what
you
mentioned
about
developers
not
being
able
to
create
repositories
directly
on
GitHub
I.
Think
that's
really
powerful,
because
then
it
means
that
you
have
already
centralized,
as
you
said,
the
processes
and
everything
they
need
to
be
productive
and
it's
under
your
control.
That's
really
great
yeah
that
you
you've
already
gotten
into
the
question
that
I
want
me
to
ask,
and
that's
great
because
it's
about
how
did
you
widespread
taxation
across
the
organization?
A
Because
now
that
you
have
these
features,
it
is
evident
for
developers
that
they
get
a
lot
of
value
to
get
to
your
portal
and
they
they
have
to
do
it
all
in
in
the
case
of
Casper.
They
don't
have
a
choice.
They
have
to
go,
but
earlier
status.
How
did
you
convince
people
these
people
start
using
it
or
what?
What?
How
was
the
beginning
like?
A
Because
now
it's
like
really
a
great
picture
and
both
of
you
have
scaffolder
templates
that
are
really
calling
people
in
what
was
the
process
for
embroidering
entities
or
or
all
these
like
more
kind
of
tedious
work.
That
happens
in
the
beginning.
B
B
To
add
the
thing
into
the
to
to
Backstage
and
all
that
we
didn't
want
to
deal
with
any
of
that
developers
shouldn't
they
shouldn't
care
about
that
at
all
that.
That
is
something
that
should
just
work
out
of
the
box.
We
spend
a
lot
of
time
in
on
actually
building
all
the
processing
and
all
that
yeah.
So
right
now
we
are.
We
were
kind
of
lucky
because
a
couple
of
years,
before
adopting
backstage,
we
built
something
that
we
call
Shadow,
which
is
basically
a
file
that
lives
in
all
our
repositories.
B
Also
defines
how
does
this
service
look
in
different
environments,
so
we
could
fairly
easily
create
a
preprocessor
that
read
this
file
and
created
all
the
backstage
components
based
on
this
file.
So
we
were
able
to
fairly
quickly
get
all
of
our
GitHub
repositories
in
there
and
and
then
basically
starting
adding
small,
more
and
more
stuff
to
this
file
so
that
you'll
be
able
to
put
on
we
have
domains
or
whatever
it
might
be.
So
we
are
utilizing
our
old
tooling
to
instrument
and
ensure
that
we
get
all
the
data
in
backstage.
B
So
whenever
your
credit
reposits
are
written
next,
it's
within
five
minutes
and
everything
is
automated.
Nothing
needs
to
be
added
by
hand
which
I
think
was
a
if,
if
we
have
forced
developers
to
to
do
like
a
copy
paste,
the
insert
you
need
to
have
this
backstage
component
in
your
repo.
We
wouldn't
have
succeeded
at
all.
C
C
Yeah
yeah,
at
the
end
of
the
day,
we
ask
developers
and
team
those
teams
to
do
a
lot
of
different
things,
especially
I'm,
assuming
with
tech,
insights
right.
That's
there's
always.
B
C
You're
playing
catch-up
all
the
time,
you
know
whether
it's
a
migration
or
an
upgrade,
and
that's
something
that
we
were
trying
to
balance
too
it's
like.
Do
we
take
a
heavy-handed
approach,
or
do
we
take
a
more
you
know,
soft
approach,
where
we
prove
out
the
value
and
have
people
organically
come
into
backstage
and
we've
kind
of
tried,
both
right
now
and
I,
I've
kind
of
seen
more
excitement
around.
C
You
know
the
the
like
I
said:
the
software
templates,
the
part
where
we're
proving
out
like
the
the
value
that
it
can
provide,
and
that's
really
getting
people
excited
about
it
and,
and
so
like
our
first
approach
was
we
we
have
a
very
complex
kind
of
technical
ecosystem
internally
and
ownership
was
something
we
were
trying
to
juggle.
C
It
wasn't
entirely
clear
who
owned
what,
and
so
our
adoption
Journey
really
started
off
with
the
software
catalog,
and
what
we
decided
to
do
is
couple
that,
with
the
ability
to
begin
tracking,
your
Dora
metrics
and
the
way
that
you
could
identify
your
you
as
the
owner
of
a
service
that
was
sending
you
know,
you're
building,
deploy
events
that
were
being
calculated
into
it.
C
Door
metrics
was
to
register
those
components
into
the
software
catalog,
and
so
that
was
kind
of
like
our
approach
to
getting
people
into
the
software
catalog
and
onboarding
their
services
in
there,
and
we
started
to
see
some
Fidelity
by
the
time
to
our
our
ecosystem
and
what
the
teams
own,
what
teams
are
being
what
components
within
relativity
are
being
actively
developed,
and
that
was
like
our
first
kind
of
attempt
there.
Then
we
started
to
see
some
organic
usage
of
like
Tech
docs
people
were
like.
Oh,
this
is
interesting.
This
is
cool.
C
Let
me
check
this
out.
Maybe
we'll
move
our
documentation
over
from
you
know,
Confluence
into
here
the
more
formalized
documentation
and
the
stuff
that
we
want
people
to
see.
Not
necessarily,
you
know
like
the
spike
pages
and
stuff
but
yeah.
C
That
was
like
we
kind
of
seen
an
extension
of
a
use
case
that
that
we
first
kind
of
started
out
with
we're
and
we're
really
trying
to
close
the
gap
on
both
sides
like
the
old
stuff
that
was
pretty
backstage
and
the
new
stuff
that
that
we
want
to
kind
of
like
start
out
in
backstage
and
I.
Think
that's
similar
to
kind
of
like
what
Casper
and
and
and
his
his
order
are
doing.
C
Is
that
they're
they
want
every
they
having
or
having
people
guide
people
through
backstages
like
that
that
starting
point
and
that's
what
we're
trying
to
do
as
well
and
we're
starting
to
see
kind
of
like
a
shift
in
teams,
thinking
about
how
they
can
offer
more
self-service,
workflows
and
and
backstage
can
almost
like
provide
that
front
door
to
that
experience
for
them,
and
you
know
integrating
those
tools
in
those
templates.
So
you
get
it
out
of
the
box,
so
they
don't
even
have
to
like
think
about.
C
We
want
to
make
it
easy
for
them
to
not
even
have
to
think
about
that,
and
they
can
get
it
out
of
the
box
and
then
you
know
I
think
it's
it's
our
way
of
effectively
trying
to
stop
the
bleeding
so
to
speak
and
and
over
time
those
systems
that
were
built
before
backstage
will
eventually,
you
know,
make
their
way
in
over
time
because
we
don't
want
to
say
you
know
you
need
to
do
this
today,
because
we're
all
moving
fast,
we're
all
super
busy.
C
C
So
we've
we've
kind
of
tried
both
both
approaches,
we're
still
trying
to
figure
it
out,
but
definitely
I
would
say,
like
the
the
approach
with
the
templates,
especially
if
you
have
a
lot
of
complex
workflows,
is
a
good
route
to
take
to
show
the
value
that
it
can
provide.
A
All
right
great
great
discussion
today,
thank
you
so
much
for
coming
I'm,
afraid
we
are
running
out
of
time,
but
I
think
you
were
very
generous
during
your
Insight
and
your
experience.
Do
you
guys
have
any
thoughts
mentioned
before
we
wrapped
up.
B
Maybe
if
you
are
around
a
coupon
I
have
a
talk
on
on
Friday
I.
Think
right
after
you,
maybe
so
11
55
Friday
at
kubecon,
come
see
me.
If
you
are
there.
C
I
think
it's
like
one
of
the
the
best
things
that
can
you
know
improve
your
developers
day
to
day.
So,
if
you're
thinking
about,
if
if
this
has
been
a
discussion
with
your
with
your
teams,
definitely
look
into
getting
into
a
hackathon,
get
it
in,
get
it
in
front
of
people
that
make
those
decisions
and-
and
you
know,
prove
out
that
that
value
I
think
it's
I,
think
you'll
be
have
a
happier
engineering
organization
overall,
once
you
once
you
go
down
the
journey,
but.
A
Yeah
excellent
all
right,
thank
you
guys
for
everybody
going
to
cubecon
Amsterdam
I'll,
see
you
there
thank.