►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. 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.
What is This Tech Insights Anyways? - Jussi Hallila & Irma Solakovic, Roadie
Demos of tech insights show how you can track and visualize the engineering standards using Backstage and what benefits those can provide for your company. In this talk, we’ll take a deep dive into the tech insights present in the open source Backstage codebase to show you how to set it up to enable it to help manage your tech health. You will learn what are the moving parts that build up the whole concept of tech insights. Jussi will demonstrate what are the possibilities with the current architectural design of the feature. You will also learn how to extend the built-in functionality to provide your own data sources, your own components to visualize tech insight data and how to drive your company’s engineering standards with tech insights. At the end of the talk, you will have seen practical examples of the capabilities of the tech insights functionality and how those are built. With the knowledge gained from this presentation, you should be comfortable extending the functionality present in the open source project and mold it to satisfy your needs.
A
So
how
many
in
here
is
actually
used
to
take
this
plug-in
on
the
open
source
backstage
how
many
has
deployed
it?
We
have
two
hands:
it's
nice,
maybe
maybe
a
few
more
after
this
talk,
so
we're
going
to
talk
about
deck
insights
a
little
bit
we'll
show
why
we
build
it
for
Audi.
First
of
all,
because
we
wanted
to
roll
that
out
for
our
customers.
What
are
the
components
that
are
now
available
in
Roti
and
how
you
can
Implement
those
yourself
in
the
open
source
backstage
as
well?
A
Everyone
will
go
through
what
we
have
currently
in
place
and
why
we
built
it
and
then
I'll
jump
in
and
I
will
talk
about
what
is
in
the
open
source
backstage
how
it
was
architected.
Initially,
what
are
the
ideas
behind
it
and
then
we'll
go
through
what
you
can
do
to
actually
use
that
your
advantage
in
the
open
source
project
or
your
own
backstage
deployment,
so
maybe
maybe
more
than
two
people
after
this
talk
good,
okay,.
B
B
So
when
we
first
started
using
backstage
everything
was
great.
We
didn't
have
a
lot
of
Services.
Of
course
it
was
maybe
around
10
services
that
we
needed
to
check.
So
we
were
able
to
manually
Trace
progress
in
all
of
these
services
and
we
were
able
to
kind
of
do
all
sorts
of
tasks
and
see
if
some
of
those
Services
were
successful
and
some
of
them
were
not.
However,
over
the
time
the
number
of
our
services
increased,
so
we
started
having
more
than
100
services.
B
B
So
we
were
looking
for
an
automated
way
to
keep
us
happy,
because
we
figured
out
that
we
weren't
as
efficient
as
before,
of
course-
and
we
had
couple
of
mingles
in
our
mind,
so
I
will
just
guide
you
through
them.
So,
firstly,
we
wanted
to
measure
the
quality
of
software.
Now
software
quality
may
be
a
term
that
is
not
I
mean
it
is
a
common,
but
a
common
understanding
of
this
may
not
be
the
same
for
all
filter
engineers.
B
So
by
introducing
scorecards,
we
were
able
to
just
kind
of
reflect
on
those
checks
that
matters
to
us,
the
most.
So,
for
example,
here
you
can
see
several
checks,
such
as
presenting
sneak
or
number
of
critical
severities
or
if
none
of
them
are
found,
but
basically
check
themselves
are
a
single
unit
of
computation
and
they
produce
result
based
on
that
value
now
scorecard
result
would
be
like
a
accumulation
of
all
of
those
results
and
whether
you
decide
to
use
it
on
an
entity
level,
as
shown
here
or
catalog
level.
B
Okay,
secondly,
we
wanted
to
visualize
what
matters
the
most,
so
we
strongly
believe
in
the
power
of
visual
components
in
order
to
provide
better
visualization.
We
kind
of
developed
a
graph
card
which
you
can
see
here
and
this
card
gives
you
and
provides
you
the
information
about
fact
value
over
the
time
range.
So
here
it's
one
month
period,
but
of
course
it
can
be
anything
else.
B
What
matters
to
you,
but
apart
from
that,
we
have
also
developed
a
big
number
card
and
the
main
difference
is
that
the
discard
will
give
you
a
current
value
for
the
facts
now.
Both
of
these
are
quite
handy
and
we
use
them
because,
like
the
biggest
power
they
have
is
that
you
can
combine
multiple
facts
from
multiple
fact
retrievers
and
display
all
of
them
in
these
cards.
B
And
lastly,
but
of
course,
not
least
important,
we
know
that
in
organizations
different
teams
will
be
working
on
different
parts
of
the
platform.
So
by
developing
Team
level
report
we
have
emphasized
emphasized
the
accountability
for
services
within
teams
so
that
they
know
which
Services
they
own
and
what
they
need
to
do
in
order
to
increase
the
quality
in
those
services
and
to
meet
requirements
set
in
the
scorecards.
B
However,
since
we
know
that
we
don't
live
in
a
world
where
all
developers
can
jump
in
on
the
task
as
soon
as
it
kind
of
pops
up
currently,
we
are
working
in
on
a
feature
that
will
provide
real-time
feedback
alerts
and
subtly
nudge
developers
and
teams
in
general,
so
they
know
what
they
need
to
do
in
their
services,
so
the
requirements
are
met.
So
these
nudges
can
be
whether
on
slack
or
GitHub
or
whatever
tool
you
use,
but
these
will
be
used
like
as
I
said
kind
of
nudging
the
team
in
a
subtle
way.
B
So
they
know
what
they
need
to
do.
I
have
mentioned
several
terms
in
my
part
of
presentation
and
those
are
checks,
facts
and
faculty
tubers,
so
I'm
sure
that
you
will
wonder
how
they
all
fit
into
place.
So
now
I
would
like
to
say
take
over
and
he
will
tell
you
more
about
architecture
behind
Tech
insights
and
hopefully,
you'll
have
like
a
big,
better
idea
how
it
all
fits
you
into
a
place.
A
Cool
thank
you.
So
if
we
think
about
tech
insights
in
general,
it
is
plugging
that
needs
a
lot
of
work,
because
data
sources
that
you're
using
to
actually
retrieve
the
king
size
data
is
usually
something
custom.
You
can
think
about.
Data
sources
being
GitHub
or
in
our
guest
snake
is
very
good
data
source
for
us.
A
So
we
have
data
layer
which
contains
like
the
storage
of
the
data
as
well
as
the
retrieval.
How
do
we
get
the
data
into
the
storage
space?
Then
we
have
calculation
which
I
usually
divide
into
two
different
bits:
checksand
and
manipulation,
other
aggregation
stuff
and
finally,
visualization.
We
saw
a
few
visual
visual
elements
here
already
that
we
have
developed
for
Audi
and
there
are
a
component
on
the
open
source
backstage
as
well
that
you
can
use
to
visualize
your
scorecards.
A
So
yeah
we'll
go
through
this
one
by
one
now
you
will
see
some
code
as
well.
First,
let's
think
about
data.
So
if
you
think
of
Backstage
plugins
a
lot
of
the
implementations
that
we
have
seen,
they
usually
fetch
the
data
from
some
third-party
source
and
then
display
that
so
you've
had
the
current
data
available
for
you,
and
that
would
be
pretty
much
it
you've
had
started
runtime
and
show
that
immediately
there
might
be
some
cash
at
the
store
today
than
the
database.
A
A
The
schema
this
defines
the
shape
of
the
data
that
you
want
to
store
in
decade
designs.
So
if
you
take
a
look
at
the
Json
blob
in
there
or
actually
it's
Java
and
typescript
code,
the
schema
itself,
it
actually
has
multiple
fact
items
within
it,
so
you
have
a
fact
schema
that
encompasses
multiple
Factor
items,
and
this
can
be
considered
that
okay,
all
of
these
fact
items
come
from
the
same
data
source,
whether
it's
Nick
or
GitHub,
or
your
internal
cicd
solution
or
something
else
all
of
these
Factor
items
within
the
scheme.
A
They
have
a
type
So.
Currently
the
types
available
on
the
open
source
package.
We
have
a
few
numerical
types
of
integer
and
floats
and
then
string,
sunsets
and
timestamps
and
in
some
cases
you
might
want
to
store
like
complex
serializationable
objects
like
Json
blobs
as
facts
as
well.
So
when
we
have
this
fact
data
available,
then
we
can
work
with
that
one.
A
The
second
table
that
we
have
is
then
the
fact
itself.
So
this
is
a
pure
one-to-one
mapping
to
the
fact
schema
that
we
saw
earlier.
You
can
see
on
the
last
three
lines.
We
have
the
same
same
shape,
but
now
we
have
the
actual
values
in
there
as
well.
The
two
other
kind
of
interesting
bits
in
here
are
the
timestamp.
A
In
this
case,
the
reference
is
a
component
called
sample
service,
but
the
reference
can
be
anything
else
that
you
can
think
of.
It
can
be
a
resource
you
may
want
to
do
analytics
on
your
AWS
resources
that
you
have
mapped
in
the
backstage,
or
maybe
you
want
to
do
analytics
on
your
employees.
You
have
user
entity
and
you
want
to
see
how
many
lines
of
code
they
have
committed
over
the
last
two
weeks.
Maybe
the
race
is
based
on
that.
No
don't
do
that.
You
can
it's
possible
to
do,
but
don't
do
that.
A
The
top
field
there
ID.
That
is
then
the
last
terminology
that
we'll
introduce
here
so
Factory
driver.
In
this
case
we
are
calling
it
sneak.
Factory
driver,
Factory
driver
itself
it.
It
is
a
logical
concept
that
encapsulates
encapsulates
both
the
schema
itself.
We
see
that
on
line
three,
as
well
as
the
logic
that
we
need
to
use
to
actually
get
the
data
from
third
party
and
map
it
into
some
kind
of
shape
that
we
have
defined
in
the
scheme
itself.
A
These
Factor
retrievers
that
we
have
in
backstage
the
shape
of
them
is
usually
like
this.
You
need
to
define
a
schema
and
create
the
angular
function
for
it
and
then
register
it
to
have
some
kind
of
schedule
for
it,
so
it
can
run
on
a
loop
contact,
third
parties,
fetch
date
or
store
it
in
the
backstage
big
database
and
the
big
database.
The
whole
data
model
looks
a
little
bit
like
this,
so
we
have
the
factory
Traverse
the
schema
for
it
and
then
a
big
database
that
stores
all
the
facts.
A
If
you
screentart,
you
might
see
some
similarities
star
schema
in
there,
but
we
are
in
very
denormalized
world.
So
it's
not
really.
You
need
to
squint
like
really
hard
to
actually
see
that
the
database
implementation
in
backstage.
Currently
it's
using
whatever
you
want
to
use.
It
is
sqlite
or
postgres,
but
it
is
open
to
extension.
So
if
you
want
to
actually
dump
it
into
Cassandra
or
a
dynamodp
or
anywhere
else,
you
can
bring
your
own
because
the
API
API
surface
of
these
interfaces
that
implements
these
database
calls
is
very
small.
A
There's
like
five
six
methods
that
you
actually
need
to
implement
that
it's
just
mostly
dumping
Json
into
somewhere
else
or
retrieving
it
cool.
So
that
is
data
layer.
We
are
repeating
the
slides
next
one.
We
can
talk
about
calculations
now
that
we
have
the
data
available
for
us.
We
need
to
do
something
with
the
data.
There
are
two
categories
of
calculations
that
I've
identified.
A
A
Checks
are
simple
checks,
so
you
you
have
a
Target
value.
You
have
a
fact
value
in
here.
In
fact,
it's
called
severe
vulnerabilities
and
Target
is
one,
and
then
you
have
an
operator
that
compares
those
two.
So
the
default
implementation
in
there
is
Json
rules,
engine
that
always
produces
a
true
or
false
value.
This
is
by
Design.
A
You
can
query
ranges
of
that
and
then
run
calculations,
aggregations,
run,
arithmetics
calculate
like
averages
over
time
window
or
min
max
values,
or
most
common
value
or
percentile
certain
stuff
like
that,
and
then
store
that
back
into
the
same
Tech
insights
database
as
a
second
layer
of
this
fact
data
that
way
when
you
want
to
see
that
what
was
the
average
over
one
week
period
today,
you
can
see
that,
but
you
can
also
go
four
weeks
back
and
see
what
the
what
the
actual
value
was.
At
that
point,
you
don't
need
to
do
additional
calculations.
A
Neither
one
of
these
is
actually
necessary.
They
are
available
there.
So
if
you
want
to
use
checks,
there
are
endpoints
where
you
can
dump
in
a
check
identifier
and
fact
identifier.
It
will
it'll
give
you
a
result
or
if
you
want
to
do
all
the
aggregations
or
other
other
calculations
with
the
fact
data
you
can
just
create
the
factory
driver
and
dump
it
back
into
the
database.
A
But
you
don't
have
to
do
that
because
you
can
use
the
fact
the
data
directly
from
the
database
and
visualize
that
so
the
last
layer
visualization,
and
we
saw
a
few
of
the
elements
that
we
have
built
for
Audi.
There
are
few
others
that
we
have
ideated.
Currently,
the
implementations
that
are
available
on
the
open
source
backstage
side
are
limited
to
scorecard
implementation,
so
scorecard
we
saw
that
or
already
and
as
a
concept.
It
is
fairly
simple.
It
is
a
full
end-to-end
solution
that
you
can
use
nowadays
already.
A
So
if
you
want
to
see
how
secure
your
service
is,
you
can
create
checks
that
checks,
okay,
I,
have
less
than
five
vulnerabilities
or
similar
items
like
that
and
then
create
the
scorecard
out
of
that.
One.
Try
that
to
an
entity
show
that
on
the
catalog
page
of
your
entities
and
teams
will
be
able
to
see
if
they
are
getting
a
good
grade
or
not.
A
The
next
item
is
then
using
the
fact
data
directly,
so
endpoints
are
available
in
there.
We
see
a
talk
about
visualization
in
two
hours,
I
think,
which
will
be
very
interesting,
because
I
I
believe
that
the
tech
insights
database
and
the
facts
that
are
stored
in
there
will
be
very
good
source
of
data
for
these
visualizations
that
we
will
be
seeing
and
I
think
there
will
be
a
lot
of
a
lot
of
good
coming
out
of
that
one.
A
When
we
combine
these
two
jokes
together
so
yeah
you
can
do
ranges,
you
can
do
charts
and
whatnot.
Also
aggregate
visualization.
It's
it's
the
same
same
thing
of
a
same
thing
using
the
fact
data
directly
but
different
kind
of
items
to
be
displayed.
So
you
can
do
pie
charts
you
can
do
you
can
do
average
numbers
or
the
big
number
card
that
we
saw
earlier.
You
can
even
create
infographics
based
on
the
fact
data
that
you
have
calculated
for
your
Tech
insights.
A
All
of
these
three.
These
are
very
tight
to
the
counter.
Look
right,
so
you
usually
display
these
ones
that
are
typed
on
entity.
You'd,
see
that
on
the
catalog
page
and
you
would
maybe
create
roll
up.
So
we
saw
or
lots
of
scorecards
earlier
at
a
team
view
through
scorecards,
but
mostly
these
are
very
tied
to
the
catalog
itself.
A
The
other
bits
that
I
called
others.
Simply.
You
can
actually
do
more
with
the
tech
inside
data
that
we
have
in
the
database.
So
if
we
think
about
the
original
demo,
video
that
is
on
Backstage,
I
o
slash
demo
right
in
there.
We
saw
migration
from
I
can't
remember
what
it
was.
Let's
call
it
python,
2
to
python,
3.
and
tracking
that
how
teams
were
faring
what
was
the
score
of
the
team
and
how
the
migration
was
going
or
our
organization
wide.
A
The
other
bits
that
we
saw
in
the
demo,
video
as
well,
is
to
actually
display
the
fact
data
directly
in
a
pure
format.
So,
on
the
demo
video,
we
saw
a
table
view
that
displayed
some
service.
What
were
the
dependencies
of
that
and
what
were
the
versions
of
those
dependencies?
So
you
can
think
about.
Okay,
I
want
to
map
all
of
the
dependencies
of
my
node.js
microservice.
What
you're
doing
there
is
you
retrieve
the
fact
data
for
the
docker
file?
A
There
are
three
steps
that
you
need
to
implement.
I
said
earlier
that
it
is
very
cold
heavy
to
actually
get
Tech
insights
up
and
running.
A
lot
of
Backstage
is
because
you
do
need
to
implement
your
own
code,
scaffold
the
code
to
the
dependencies
up
and
to
wire
things
up.
Maybe
the
backend
system
will
help
with
that.
I
hope
it
will.
It
looks
very
good
already,
but
back
to
deck
insights,
we
create
Tech
insights.
We
want
to
create
three
different
items.
First,
one
is
Factory
driver.
A
You
find
out
what
your
third
party
source
is
for
the
data,
whether
it
is
GitHub
or
sneak
or
internal
cicd
tool.
Then
you
identify
what
is
the
shape
of
the
data,
so
you
create
a
fact
schema
for
that
and,
finally,
you
create
the
actual
Logic.
The
simplest
bit
make
a
call.
The
third
party
modify
the
data
and
dump
it
into
the
fact
that
in
such
database,
so
now
that
we
have
the
data
inside,
we
can
create
checks.
A
A
The
default
implementation
currently
is
called
Json
rules,
engine
that
was
chosen
because
it
is
kind
of
powerful.
It
gives
you
easy
tools
to
get
started,
so
you
can
create
easy
checks.
Like
okay
number,
two
is
less
than
my
fact,
which
is
simple
to
understand,
but
you
can
also
do
Boolean
logic
in
there.
You
can
do
and
and
or
combinations
on,
Json
rules
engine
and
the
kind
of
the
most
interesting
bit
that
I.
A
Think
of
when
I
think
about
Json
rules
engine
is
that
it
has
the
ability
to
actually
compare
one
fact
against
another
fact,
so
you
can
imagine
an
implementation
where
your
devsecops
team
maintains
a
Google
sheet
where
they
store
values
of
okay
log
JS.
Look
for
J
version
needs
to
be
a
little
higher
than
whatever
the
vulnerable
version
was.
A
You
can
use
that
as
your
fact,
Source
called
the
API
of
Google
Sheets
and
store
that
as
a
fact,
and
then
you
can
create
the
check
that
compares
that
devsec
Ops
provided
fact
against
the
actual
dependency
version
in
your
entity.
That
way,
you
will
have
completely
Dynamic
checks.
You
don't
need
to
modify
code
anymore.
You
create
the
check
once
and
then
you
need
to
modify
whatever
Google
sheet
or
maybe
another
GitHub
repository
with
file,
values
and
stuff
like
that.
A
And
finally,
when
we
have
these
checks
available
for
us,
we
can
create
scorecards
based
on
those.
So
there
is
a
plugin
to
create
scorecards.
It
is
displaying
these
check
results.
It
makes
all
it
makes
automatic
calls
to
the
back
end
to
check
end
points
and
gives
us
the
values
displays.
What
is
the?
What
is
the
grade
of
the
scorecard
that
we
want
to
see.
A
Cool
I
think
with
those
you
should
be
able
to
get
started
so
three
items
to
think
about
creating
Factory
trailers,
creating
checks.
Factor
drivers
are
typescript
code.
Checks
are
Json
structure
more
or
less
so
you
can
create
those
outside,
maybe
store
them
in
the
database,
because
that
way
it
might
be
easier
to
handle
and
you
don't
need
to
modify
code.
And,
finally,
when
you
have
those
two
available,
you
can
start
creating
your
scorecards.
B
Okay,
I
believe
that's
all
what
we
have
prepared
for
today,
however,
keep
in
mind
that
this
project
is
still
like
in
its
early
stage,
so
contributions
are
very
welcomed.
So
here
are
a
few
ideas.
How
can
you
all
get
involved
and
how
can
you
contribute,
but
we
hope
that
we
have
sparked
the
interest
in
Tech
insights,
plugin
and
that,
if
you
haven't
so
far,
you
will
kind
of
try
it
out
now.
Unfortunately,
we
don't
have
any
more
time
but
we'll
be
having
I
think
time
for
a
couple
couple.
B
Questions
so
make
sure
to
raise
your
hands,
but
if
there
are
still,
if
there's
like
interest
or
you
need
to
know
something,
make
sure
to
stop
by
our
booth,
we'll
be
here
whole
week,
so
both
me
and
UC
will
be
there
most
of
the
time
and
we
will
be
happy
to
answer
all
your
questions.
Thank
you
for
your
attention.
A
B
C
A
Let
me
see
if
I
understood
the
question
correctly,
so
how
it
compares
to
like
kubernetes,
metrics
or
data
doc,
or
something
similar
like
that
yeah
deck
inside
isn't.
So,
if
we
think
about
those
metrics
in
general,
the
Cadence
for
those
is
usually
much
smaller.
So
you
can
talk
about
like
minutes
or
whatnot.
When
you
think
about
tech
insights,
it's
usually
creating
checks
or
retrieving
facts
that
might
take
days
to
change
and
visualizing.
Those
is
something
that
I
mean
you
can
do
in
kubernetes,
for
example,
but
actually
having
the
historical
data.
A
What
it
was
10
months
ago
is
useful,
because
you
can
see
that
okay
over
time,
our
team
gained
the
scorecard
from
20
to
93
percent
or
they
their
severe
vulnerabilities,
dropped
from
80
to
3
over
the
last
two
month
period,
or
so
it's
similar
solution,
but
mostly
data
source,
would
be
different
and
then
because
you
have
data
sources
from
different
third-party
places,
so
you
can
have
data
talk
and
the
kubernetes
metrics
in
the
same
database.
You
can
merge
those
together
and
maybe
compare
them
more,
create
aggregations
based
on
them.