►
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Backstage: Restoring Order To Your Chaos - Dave Zolotusky, Spotify
The CNCF Landscape is a complex ecosystem of frameworks, technologies, and platforms. Your teams have their own implementations of these technologies. Onboarding new developers is super confusing, and docs are scattered around the place. In short: chaos. The solution to this might be… another portal? Backstage (https://backstage.io), a platform you can use to build your own developer portal. It is highly customisable and adopted by companies like Expedia, Netflix, American Airlines, and Epic Games. Dave will share why Backstage was developed at Spotify, how it became the core of their developer experience, and a CNCF project. You’ll get a quick tour of Backstage, the plugin ecosystem, and some of the key use cases for Backstage. Then he will dig into the Software Templates feature. How templates can help developers quickly get started with new code repositories. He will also cover how you can create custom templates to have your organizations best practices built-in, right from the start!
A
C
B
Try
harder
cool!
Well,
thanks
gospel
for
the
intro
see.
I
think
this
is
one
of
the
first
times.
It's
not
the
first
time
that
any
of
us
are
talking
about
backstage
to
the
cubecon
audience.
So
I'm
going
to
try
to
do
kind
of
a
quick
intro
go
through
a
little
bit
of
what
backstage
is
why
it
even
exists
and
then
do
a
quick
demo.
Then
I'm
going
to
dig
into
one
of
the
features
in
backstage
that
we're
pretty
excited
about,
but
I
haven't
talked
a
lot
about
this
thing.
Called
software
templates.
B
B
So
we
call
backstage
an
open
platform
for
building
developer
portals
and
we
created
at
spotify
a
few
years
ago
and
we
open
sourced
it
in
march
of
2020
and
then
a
few
months
later
we
donated
to
cncf
and
then
just
a
few
weeks
ago
it
moved
from
the
sandbox
to
the
incubation
stage
and
at
spotify.
We've
always
believed
that
the
speed
and
innovation
that
our
company
depends
on
can't
really
exist
without
our
development
teams
having
a
fair
amount
of
autonomy
to
decide
what
they
want
to
do
and
how
they
want
to
do
it.
B
But
as
we
learned
when
we
were
growing
the
faster
we
grow
and
the
more
autonomous
teams
like
this,
we
have
the
more
fragmented
and
really
complex
our
ecosystem
becomes,
and
then
everything
really
slows
down
again
and
this
we
really
started
analyzing
this
back
in
2016
when
the
company
was
in
hyper
growth
mode.
We
were
hiring
a
lot
and
trying
to
onboard
engineers,
but
it
was
really
confusing
and
it
was
hard
I
might
just
die
and
it
took
us
longer
and
longer
we
good
all
right.
It
took
us
longer
and
longer
to
onboard
people.
B
Our
headcount
went
up,
but
our
develop
developer
effectiveness
was
kind
of
going
down.
Specifically,
we
were
measuring
a
metric
that
was
the
time
to
the
10th
pr
so
from
when
the
person
started
till
the
10th
time
they
made
a
pr
to
our
internal
github
and
in
2016
that
metric
hit
about
60
days,
and
we
somewhat
panicked
and
set
out
to
figure
out
what
to
do
about
it
and
what
we
did
was
build
backstage
outside
of
spotify.
Of
course,
we,
the
same
sort
of
thing,
is
happening.
B
B
B
B
But
it's
also
much
more
than
something
like
a
service
catalog
to
us.
The
developer
portal
is
one
front
end
for
your
entire
platform
for
all
the
tooling
that
your
developers
need
things
like
ci,
cd
and
monitoring
security,
tooling
testing
and
whatever
tooling,
that
you're
accessing
daily
as
a
developer
should
live
in
this
one
place.
It's
also
a
place
where
your
services,
your
applications,
your
data,
your
machine
learning
models,
kind
of
whatever
the
actual
software
you're
running
is
should
be
managed
through
and,
of
course,
documentation,
whether
it's
for
components
or
apis
or
tutorials.
B
Even
things
like
org,
charts
and
strategy
docs
can
live
in
this
one
place
to
make
it
easy
to
find
everything
you
need
to
build
software,
and
we
think
that,
regardless
of
where
these
components
are
coming
from
or
who
manages
them,
they
still
are
in
one
place.
So
in
a
nutshell,
to
us,
it's
a
place
that
lets
developers
focus
on
creating
features
and
keeping
your
business
running
by
consolidating
everything
they
need
into.
B
This
one
place,
so
they
can
perform
all
the
daily
kind
of
basic
tasks
they
need
from
here
without
constantly
learning
another
new
tool
and
figuring
out
another
new
interface,
and
we
think
that
every
shop
development
shop
wants
roughly
the
same
few
things.
They
want
speed,
they
want
scale,
but
they
don't
want
to
compromise
safety
or
quality.
B
And
of
course,
they
want
to
tame
a
lot
of
the
chaos
in
their
software
ecosystem.
That
comes
from
all
that
speed
and
all
of
that
scale
and
spotify
was
no
different.
So
we
built
this
developer
portal
that
we
now
know
as
backstage
to
tame
all
of
that
chaos
and
that
changed
things
for
us
a
lot.
It
aligned
a
lot
of
these
different
autonomous
distributed
teams
and
brought
together
hundreds
of
them
thousands
of
engineers
and
tens
of
thousands
of
software
components
of
all
different
types
and
backstage
enabled
much
better.
B
You
need
to
know
that
it's
working
all
of
that
day-to-day
stuff
and
then
explore
is
really
the
collaboration
piece.
You
might
be
working
on
a
team
that
builds
a
couple
of
components
that
owns
some
piece,
but
then
it
needs
to
interact
with
something
else,
or
it
needs
to
get
data
from
somewhere
else,
and
you
might
not
know
what
that
something
else
is,
or
you
might
have
a
rough
idea
so
at
spotify.
B
The
more
to
like
backstage
becomes
critical
because
you
need
to
handle
all
this
growth
of
the
people
into
the
software
complexity,
and
the
other
thing
backstage
brings
is
the
open
source
community
around
backstage
for
extensibility,
for
both
support
of
all
of
the
tools
that
you
have,
that
other
companies
have
or
that
other
companies
may
help
you
with
the
way
that
we
know
open
source
does,
but
also
for
support
in
the
human
sense
like.
If
you
have
a
problem,
you
have
someone
to
talk
to,
you
can
get
some
help.
B
So
when
we
open
source
backstage,
we
really
focused
on
that
last
piece:
the
extensibility
and
making
it
possible
to
make
for
different
organizations
to
work
with
all
of
their
tools.
We
think
that
backstage
is
power
and
its
uniqueness
in
this
ecosystem
is
from
this
highly
extensible,
plug-in
architecture
and
backstage
plugins
are
effectively
just
additional
functionality.
To
make
your
backstage
instance,
customized
to
your
company
in
your
software
ecosystem
and
plugins
can
come
from
anywhere.
B
We
have
examples
of
people
that
have
internal
plugins,
very
highly
customized
or
something
that
only
their
company
does
and,
of
course,
they
have
open
source
ones
that
are
shared
across
many
of
the
adopters
of
backstage
in
the
spotify
central
backstage.
Even
before
we
ever
open
sourced
it,
we
had
a
very
similar
model.
We
had
contributions
from
all
over
the
company
into
this
one,
single,
unified
experience
and
plug-ins,
with
this
similar
model
that
came
from
other
teams.
B
So
the
model
looked
a
little
bit
like
like
the
bullets
here
I'll
get
to
the
picture
in
a
second,
but
we
have
the
team
that
maintains
the
core
of
backstage,
which
used
to
be
internal.
Now
is
the
open
source
maintainers.
Then
we
have
a
team
that
owns
the
spotify
instance
of
backstage.
Just
kind
of
makes
makes
it
run,
keeps
ensures
that
it
keeps
running
hand
responds
to
pages
things
like
that
for
our
internal
one.
B
Then
we
have
experts
on
the
individual
components
that
need
to
be
in
backstage
that
they
have
plug-ins
for
that
own,
that
plug-in
end-to-end
and
the
central
team
isn't
really
involved.
It's
just
an
extensible
piece
of
backstage
and
then
of
course
we
have
feature
teams
that
own
the
features
of
spotify
that
our
users
know
and
love.
Like
the
playlisting
feature
that
I
just
mentioned,
and
of
course
I
have
tight
feedback
loops
between
all
of
those
teams
to
ensure
that
these
things
keep
moving.
B
Then
I
want
to
talk
a
little
bit
about
what
plugins
actually
are
and
what
they
can
be
and
that's
the
picture
on
this
slide.
So
we
have
a
a
lot
of
customization
in
plugins
lots
of
different
types
of
plugins.
For
example,
we
have
this
tech
radar
plug-in
at
the
bottom.
I'm
gonna
see
if
I
can
make
this
work
yeah
this
guy
nope.
I
can't
find
it
and
that's
really
just
the
front
end
piece.
So
it's
it's
a
lot
of
ui
and
there
isn't
much
behind
it.
B
Then
we
have
plugins
like
the
service
catalog,
which
has
its
own
database
and
has
a
back-end
service.
So
there's
much
more
to
this
plug-in
than
just
something
like
a
simple
ui,
and
we
have
things
like
the
circle.
Ci
plugin,
which
instead
of
a
database
and
a
big
backend,
just
has
a
proxy
that
goes
out
to
actual
circle
ci
so
that
you
can
get
circle
ci
ux
in
backstage,
but
not
having
to
replicate
any
more
of
circle.
Ci
specifically
for
the
plug-in.
B
And
I
couldn't
find
a
better
slide
than
this,
but
really
our
goal
with
plug-ins,
and
especially
our
goal
with
this
ecosystem
with
being
in
cncf,
is
to
make
backstage
the
front
end
for
all
of
these
cncf
tools,
at
least
for
a
bunch
of
graduating
projects,
hopefully
incubating
projects
as
much
of
the
landscape
as
we
can
cover.
So,
if
you
own
any
of
these
tools,
you
work
on
any
of
these
tools.
You're
interested
in
working
with
us
on
backstage,
please
swing
by
our
booth.
B
And
then,
of
course,
I
can't
help
but
show
off
some
of
these
numbers
because
we're
incredibly
proud
of
the
community
we
have
around
backstage
and
the
support
that
we've
gotten
from
cncf
overall
open
source
community
and
everyone
else.
I'm
not
going
to
read
all
the
numbers
to
you,
but
one
number
that
I
want
to
point
out
that
isn't
on
this
board
is
20..
So
I
said
when
we
started,
we
were
at
about
60
days
to
our
10th
pr,
since
we
introduced
backstage
and
started
iterating
on
it.
B
We've
gotten
that
number
to
stay
below
20
pretty
much
always,
and
it's
average
for
these
past
few
years,
that's
somewhere
between
10
and
14
days.
So
I'm
sure
backstage
isn't
the
only
thing
responsible
for
that,
but
it's
a
huge
part
of
it
and
then
beyond
these
numbers
backstage
has
a
proven
track
record
across
many
different
industries.
B
We
have
adopters
of
over
100
doctors
across
tons
of
different
industries
at
very
different
levels
of
technical
maturity
in
very
different,
even
kind
of
parts
of
the
tech
ecosystem,
and
this
is
just
a
small
collection
of
them,
but
of
course,
we're
continuing
to
see
more
and
more
companies
to
talk
backstage
and
just
like,
I
said,
with
plugins
we'd
love
to
see
more
adopters,
more
companies
that
are
comfortable
sharing,
more
companies
that
want
to
kind
of
come
speak
with
us,
be
in
our
public
adopters
list.
Jump
onto
this
slide.
Anything
like
that.
B
So
the
flip
side
of
the
thing
I
just
said
for
project
owners
any
end
users.
Any
companies
that
see
value
and
stuff
like
what
we're
talking
about
here
again
kind
of
swing
by
our
booth
come
talk
to
us
slack
us
later,
whatever's
easiest
for
you.
But
let's
talk
and
let's
see
if
we
can
make
backstage
work
for
you.
B
So
I
want
to
quickly
talk
a
little
bit
about
some
of
the
kind
of
core
philosophies
that
we
view
make
backstage
successful
and
that
we've
really
built
around
the
first
one
is
this
interface
and
we
think
that
backstage,
like
I
said,
is
kind
of
the
interface
for
all
of
your
platform
tooling,
but
it's
more
of
just
an
aggregator.
The
idea
is
that
there
are
many
tools
and
this
one
interface
unifies
them,
but
backstage
isn't
there
to
replace
them
and
the
simplest
example
I
can
give-
or
maybe
it's
not
the
simplest.
B
But
one
of
my
favorite
examples
I
even
give
for
this
is
something
like
ci
cd,
where
there
are
a
lot
of
things
that
as
a
developer,
you
want
to
see
in
your
ci
pipelines
and
about
your
deployments
and
but
you
don't
necessarily
everyday
need
to
go
super
deep
into
every
single
detail.
So
the
idea
with
backstage
and
with
the
ci
cd
plugins
that
we
have
at
spotify
is
to
give
any
developer
a
quick
of
one
glance
like
are
the
build
succeeding?
B
Maybe
if
they're
not
what's
going
on?
What's
the
latest
commit
that's
running
in
production
things
like
that?
But
if
there's
a
problem-
and
if
you
really
need
to
dig
in
then
we
don't
want
backstage
to
be
a
duplicate
of
all
of
the
details
of
your
ci
cd
system.
We
then
give
you
a
way
to
click
through
from
that
plug-in
to
that
build
in
your
ci
cd
system
and
debug
it
there
rather
than
debugging
from
backstage.
B
B
We
have
over
150
plugins
that
are
produced
by
about
100
other
teams
that
are
outside
of
the
backstage
organization,
and
these
plugins
provide
like
I
was
saying
it's
like
cacd
the
status
of
the
build
and
a
way
to
click
in
to
see
the
details
of
it
or
for
data
pipelines.
We
provide.
What's
going
on
with
your
pipelines,
we
show
things
like
the
schema
kind
of
coming
into
the
pipeline
coming
out
of
the
pipeline.
B
Backstage
has
a
software
catalog
and
one
of
the
primary
roles
that
serves
at
spotify
and
for
a
lot
of
our
adopters
is
enforcing
ownership,
because
we
believe
that
for
each
piece
of
software
there
should
be
a
single
owner
and
especially
at
spotify,
but
I
think
at
most
places
by
a
single
owner.
I
mean
a
single
team
that
owns
it,
so
you
can
have
a
primary
contact,
but
it's
not
necessarily
a
single
human
point
of
failure
and
that
team
should
own.
That
service
should
be
an
easy
team
to
find.
B
So
in
the
playlist
example
I
gave
earlier.
If
I
don't
know
who
to
talk
to,
I
can
go
to
backstage,
I
can
find
the
playlist
system.
I
can
find
the
team
that
owns
it
and
then
I
can
slack
them
or
email
them
or
walk
over
their
desk
depending
on
how
far
away
from
me
they
are.
But
the
flip
side
of
that
too,
is
that
team
owns
all
the
metadata
for
the
service.
B
So
there
are
things
that
I'll
show
you
in
a
minute
where
we
know
we
have
life
cycle
states
like
production,
ready
or
experimental,
or
we
can
declare
some
dependencies
and
all
of
those
things
are
up
to
that
team.
That
team
can
say
we're
operating
a
tier
one
service
and
it's
I
don't
know
production
or
it's
a
tier
three
service
and
it's
still
experimental
or
whatever
and
put
that
in
the
catalog.
B
B
Cool,
I
can
actually
load
it
and,
of
course,
I'm
showing
a
different
thing
on
my
screen
on
that
one.
So
I'm
going
to
turn
around
so
I
can
see
what's
going
on,
but
this
is
just
a
simple
view
of
the
software
catalog
and
by
default
we
go
to
a
very
developer,
focused
view.
So
you
see,
the
default
is
just
showing
me
things
that
are
owned
by
me,
so
I'm
logged
in
as
this
guest
user-
and
you
see
here
everything
I'm
seeing
is
owned
by
the
the
guest
user.
B
So
this
is
kind
of
the
managed
version
of
what
I
was
talking
about
before.
If
I
want
to
see
everything,
then
I
can
click
on
all
and
I
see
things
owned
by
other
users
by
other
teams
and
I
see
all
different
types
of
things
and
then
I
can
quickly
click
into
one
of
these
and
you
can
see
some
more
details
and
there's
things
like
links
to
the
source
code
in
github.
This
is
what
I
mean
where,
like
backstage
wants
to
be
an
aggregator,
but
not
the
owner
of
everything.
You
click
through
to
see
more
things.
B
B
You
can
see
dependencies,
you
can
see
docs
kind
of
whatever
your
company
needs
to
show
its
developers
every
day
can
be
here,
and
this
is
just
what
we
have
in
the
default
demo
and
we
have
a
significantly
richer
demo
at
the
booth.
So
if
you
want
to
see
a
little
bit
more
of
this
or
dig
in
or
ask
a
bunch
of
questions
and
watch
someone
click
around
it,
I
would
highly
recommend
going
there
and
if
you
just
want
to
click
around
this
ui
more,
this
is
demo.backstage.io.
B
B
So
the
idea
with
software
templates,
like
I
was
saying
before,
is
you
can
create
things
and
bake
all
of
your
company's
best
practices
into
these
components.
And
of
course
you
continuously
update
these
components
and
you
can
continuously
update
the
templates
so
that
every
next
thing
created
is
created
with
whatever
today's
or
this
minutes
best
practices
are
and,
of
course,
these
components
are
automatically
registered
in
the
software
catalog.
B
So
you
see
them
in
backstage
and
one
of
the
things
that's
really
useful
about
this,
but
is
that
you
have
these
templates,
and
so
you
don't
have
to
have
all
the
boilerplate
things
done
every
time
by
any
of
your
developers.
If
it's
a
bunch
of
kubernetes,
yaml
or
configuration
for
ci
cd
or
whatever
else
you
can
just
fill
out
the
level
of
form
and
backstage
and
it'll
create
what
you
need.
B
But
this
is,
of
course
much
more
than
just
about
that
yaml.
The
thing
that
I
was
saying
before
about
your
company's
best
practices
has
been
really
important
for
us
and
we
found
that
a
lot
of
people
end
up
having
to
have
some
sort
of
enforcement
or
some
sort
of
like
like
stick
or
punishment
or
whatever,
for
teams
that
aren't
adhering
to
all
the
best
practices
when
they're
creating
new
things,
and
this
way
we're
giving
people
a
way
to
do
that,
but
we're
really
doing
it
by
giving
them
the
path
of
least
resistance
to
creation.
B
B
B
Some
of
the
things
I
just
showed
like
the
service
catalog
and
some
of
the
manage
and
explore
capabilities
require
a
lot
of
your
components
to
already
be
in
backstage,
or
for
you
to
have
good
metadata
on
your
services
or
at
least
have
a
way
to
generate
that
metadata
and
a
lot
of
companies
have
that.
But
plenty
of
companies
don't
have
easy
ways
to
do
that.
They
might
either
manage
this
in
people's
heads
or
manage
it
in
like
spreadsheets
or
docs.
B
B
B
B
All
right,
I
wonder
if
it's,
because
this
is
full
screened
yeah.
So
now
yes,
so
now,
if
I
go
here,
this
is
what
the
template
looks
like
and
effectively
what
it's
going
to
do.
This
is
going
to
be
hard
for
me
to
be
looking
over
my
shoulder,
but
effectively.
We
just
have
all
the
all
the
form
fields
at
the
top
and
then
at
the
bottom.
The
actions
that
does
things
like
registering
in
the
service
catalog,
creating
the
repository
and
there's
a
few
links
that
it
ends
up
showing.
B
So
I
can
dig
a
little
bit
more
into
this,
but
I'm
guessing
that
this
thing
will
be
close
enough
to
done.
So
you
see
some
of
the
links
that
I
was
talking
about.
It's
like
here,
you
can
go
straight
to
the
repository
and
see
that
it
created
the
code
repo
for
me
and
again,
this
is
like
backstage
showing
you
the
high
level,
but
if
you
want
to
get
into
the
details
you
certainly
can
and
then
you
can
open
in
the
catalog
and
see
more
details
about
what's
going
on
with
it.
If
it
was
working.
A
B
All
right,
I
can
do
another
one
and
we'll
see
if
it
is
happier
and
if
it's
totally
not,
then
I
can
show
you
a
video
of
a
time
when
it
actually
worked
while
I'm
at
it,
let's
see
if
it
did
work
yeah.
So
I
have
no
idea
why
it
didn't
register
in
the
catalog.
I
might
need
to
restart
my
local
instance,
but
you
can
see
all
the
work
it
was
doing
it.
It
uses
github
actions
and
it
deploys
to
gke,
and
so
I
have
this
kubecon
demo
deployed
here
and
at
least
those
parts
worked.
B
But
let
me
restart
this
thing
locally
to
make
sure
that
that's
not
my
problem
and
then
I
will
do
another
one
or
a
second
cool.
So
I
can
show
you
that
and
then
once
this
thing
starts,
I
want
to
also
show
that
we
can
do
much
more
like
we
can
do
custom
actions
within
these
things.
So
this
is
kind
of
a
typical
workflow
within
spotify,
where
you
create
a
repository
and
you
create
some
things
along
with
that
service.
B
And
let's
see
if
it
does
any
better,
and
so
here
you
see,
there's
a
new
step
for
create
crafts
and
grafana,
and
then,
if
I
can
get
back
yes,
I
can
get
back
over
to
my
yaml.
You
see
there's
this
graph
section
and
the
graph
section
it's
pretty
simple,
so
how
to
create
graphs
in
grafana,
but
then
it
has
this
action
and
the
action
is
defined
in
this
create
typescript
file
and
this
action.
B
Cool
so
yeah,
I
have
the
dashboard.
My
unexpected
error
is
my
ad
blocker
and
I
don't
have
cpu
data
yet,
but,
as
I
just
deployed,
if
we
want
to
prove
that
it
worked
I'm,
I
can
certainly
show
that
in
a
minute,
but
I'm
hoping
that
this
time
I'll
actually
have
this
thing
in
the
catalog.
Yes,
so
this
is
what
the
last
one
should
have
looked
like.
B
Nothing
like
restarting
it
to
fix
everything,
but
here
it's
basically
the
same
thing
you
saw
from
the
the
sample
date
I
had
before,
but
it's
in
the
catalog
and
it's
the
thing
I
just
named.
So
I
can
go
here
and
click
view
source
and
see
that
same
repo
and
I
can
go
through
all
the
other
tabs
are
not
going
to
have
a
whole
heck
of
a
lot
because
they're
fairly
simple,
the
only
interesting
one
is
the
cicd
one,
because
this
is
showing
me
the
work
that
I
was
actually
doing.
B
So
I
can
click
on
the
commit
and
I
can
see
some
high
level
details
of
what
it
was
doing.
I
could
even
scroll
and
see
the
steps
here
and
then
again,
like
I
kept
saying
with
my
cicd
example
if
something's
wrong
and
I
want
to
go
into
the
details-
I
can
click
through
and
now
it's
showing
me
in
github
the
github
actions
details
and
I
can
click
on
that
and
click
through
I
mean
here
again
it
all
works.
So
it's
not
super
interesting
to
click
through
every
detail
of
it.
B
But
this
way,
if
it
fails
backstage,
gives
you
a
way
to
dig
into
the
details
and
then
maybe
I've
waited
long
enough
to
have
metrics
no
like
well.
I
won't
bore
you
all
by
waiting
long
enough
for
me
to
get
metrics,
but
we
can
always
come
back
to
that
later
so
yeah.
So
that's
the
scaffolder,
that's
our
software
templates
and
now
I
need
to
make
the
other
window
be
on
top
again.
B
And
this
thing
wants
to
be
full
screen
cool
all
right.
So
then
I
promised
everyone
time
for
questions
I'll
quickly,
talk
about
manage
and
explore
in
a
little
bit
more
detail
and
then
I'll
stop
talking
and
let
people
ask
stuff
so
manage
and
explore
really
depend
on
the
software
model
and
we
found
this
model
to
work
fairly
well
for
all
the
companies
we've
worked
with,
but
of
course
we're
always
learning
new
things.
The
place
I
want
to
start
on.
B
This
is
in
the
middle
of
the
entities
right
here
on
components,
because
that's
the
easiest
part
to
understand.
In
the
beginning,
a
component
test
is
effectively
just
something
that
has
some
code
like
a
service
or
a
library
or
a
data
pipeline
kind
of
whatever
it
is
that
your
key
code
is
and
these
components
they
belong
to
systems
which
belong
to
domains.
So
a
system
might
be
many
services,
it
might
be
services
and
databases
and
memcache
and
whatever
it
is
so.
B
B
A
domain
is
really
a
collection
of
systems
that
might
live
in
one
space,
so
you
might
say
spotify
you
might
have
like
the
podcast
systems,
our
domain
or
the
music
playback
system
is
our
domain
and
then
going
in
the
other
direction.
Of
course
components
will
expose
apis
or
depend
on
resources,
and
then,
of
course,
because
we
have
ownership
and
things
like
that
on
here.
B
There's
users
and
groups
as
well,
but
those,
I
think,
are
fairly
self-explanatory
and
then
all
of
these
things
can
have
types,
so
components
can
be
services
or
websites
or
libraries
like
I
was
saying.
Apis
can
be,
I
don't
know,
proto
grpc,
apis
or
graphql
or
whatever
they
are.
A
database
can
be
cassandra
or
dynamo
or
whatever,
and
all
of
that
is
also
stored
easily
in
the
service
catalog.
B
And
then
the
thing
that
I
think
is
really
important
is
this
concept
of
relations
between
these
components
so
like
who
owns
a
piece
of
software
so
like
this
service,
or
this
component
belongs
to
this
group
or
this
api
is
exposed
by
this
service
or
this
collection
of
services?
Maybe
all
expose
the
same
api
for
different
reasons
and,
of
course,
what
groups,
the
user
is
a
member
of
for
the
ownership
conversation.
B
So
all
of
this
builds
a
pretty
kind
of
complex,
but
incredibly
important
and
useful
graph
of
software
knowledge
within
your
systems
and
then
the
last
thing
is
just
annotations
is
a
way
to
kind
of
add
additional
data
that
isn't
necessarily
critical
to
anything
backstage
does,
but
you
might
want
additional
data
about
your
components,
annotated
and,
of
course,
it's
spotify.
We
put
all
of
this
in
yaml.
In
our
case
the
yamo
lives
in
the
repo
with
each
service.
So
when
you
make
a
change
to
your
service,
you
can
make
a
change
to
the
ammo.
B
Maybe
you
made
some
change
that
puts
it
in
production.
You've
changed
the
metadata
in
production,
that's
in
yaml,
thankfully
it's
not
required
for
everyone
else.
There
are
plenty
of
other
ways
to
get
stuff
into
a
catalog
and
we
have
a
lot
of
adopters
that
aren't
using
yaml
and
then
just
for
fun.
Let's
show
some
yaml.
This
is
the
an
example
of
catalog
info.
This
is
a
really
simple
thing.
This
is
a
component,
that's
its
kind.
I
mean
most
of
us.
I
think,
can
read
this:
it's
a
service.
B
You
can
see
its
lifecycle,
its
owner
things
like
that
and
then,
of
course,
there's
soft
links
as
urls,
and
with
that
this
qr
code
gives
you
a
bunch
of
links
to
various
other
backstage
things
like
backstage.io,
some
additional
information
about
our
community
places.
You
can
ask
questions,
we
have
a
pretty
active
discord
community
and
then
on
the
left,
that's
pretty
self-explanatory.
B
We
have
a
booth
at
the
project
pavilion
where
booth
number
two,
I
think
now
I,
where
I
forget,
but
we're
on
the
back
side
of
like
the
far
left,
closest
to
the
door
booth
so
come
by
check
it
out,
ask
for
a
more
detailed
demo
from
the
demo.
That's
set
up
there
or
just
come
by
and
say
hi
and
talk
about
cool
things.
You
want
to
do
with
backstage
and
with
that
I'm
done
I'll
leave
the
qr
code
up,
but
I
guess
until
we
get
kicked
out,
I'm
happy
to
answer
questions
or
talk
to
anybody.
A
A
B
There
are
plans,
but
there
isn't
really
a
good
road
map,
so
it
that's
very
much
one
of
the
things
that
people
talk
to
us
about
or
a
few
people
have
asked
for,
and
then
it's
just
a
matter
of
either
when
we
get
time
for
it,
or
I
mean
if
anybody
from
the
community
wants
to
help
we're
more
than
happy
to
have
those
conversations
too.
I
think
on
that
specific
point.
B
Right
now,
backstage
is
100
maintained
by
spotifiers
and
we're
kind
of
trying
to
get
more
community
involvement
on
the
maintainer
side
in
code
ownership
and
get
much
more
activity
there.
So,
like
that's
a
perfect
example
of
a
thing
that
isn't
critical
to
us,
but
we're
trying
to
do
for
the
community,
but
if
somebody
steps
up
and
wants
to
kind
of
be
an
active
maintainer
own,
a
part
of
backstage
and
build
that,
I
certainly
don't
think
anybody
on
the
team
would
mind.
C
Hi
one
concern
or
question
I've
had
looking
at
backstage
is
we're
talking
a
lot
about.
We
looked
at
the
cloud
native
like
landscape
and
there's
so
many
tools
out
there.
What
happens
when
it's
all
in
one
place
and
then
does
that
make
it
then
harder
for
a
developer
potentially
to
find
the
thing
they're.
Looking
for,
I
understand
that
it's
an
aggregate
and
it's
not
the
tool
itself,
but
if
you're
putting
a
lot
of
place
things
in
one
place,
is
that
not
going
to
get
then
overwhelming.
B
I
think
that's
certainly
a
concern.
I
think
it
largely
comes
down
to
how
we're
collecting
those
things
I
mean.
We,
of
course,
don't
want
to
be
the
xkcd
combat
of
where
just
the
15th
place
and
the
biggest
reason
why
we
have
confidence
that
this
works
was
because
of
how
well
it's
worked
at
spotify
like
we
like,
I
said
we
have
the
slides
at
150,
but
it
might
vary,
will
be
closer
to
200
plug-ins
by
now,
so
we
have
like,
like
I
said,
we
have
org
charts
in
backstage.
We
have
all
of
our
data
stuff.
B
We
have
all
of
our
backend
stuff
like
there's
so
much
in
there,
and
it's
worked
really
well
for,
for
us
at
least
so.
I
think
you're
completely
right
that
it
can
get
overwhelming
and
there's
just
like
too
many
buttons
and
too
many
things
or
it
can
just
become
the
15th
place
you
go,
but
at
least
for
us
at
spotify.
B
D
B
Yeah
the
the
metric
that
I
like,
of
course
most
easily
had
is
the
one
I
talked
about
this
kind
of
time
pr,
but
that's
entirely
an
onboarding
metric.
We
have
a
small
team
that
does
engineering
satisfaction
and
collect
a
bunch
of
metrics
across
our
team,
like
I
don't
know,
mean
time
to
recovery
or
deployments
per
day
like
all
of
this
stuff.
B
So
I
don't
have
a
real
answer.
I
don't
I'm
not
sure
if
suzanne
or
emma
at
the
booth
would
have
a
better
answer
because
they're,
I
think
closer
to
that
stuff.
But
I
can
probably
find
it
for
you
or
I
can
just
kind
of
hand
wave
and
say
we
have
a
whole
bunch
of
people
that
did
metrics
and
I
trust
them
and
it
worked
pretty
well.
But
I
couldn't
tell
you
what
exactly
they
did.