►
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Cloud Native and Kubernetes Observability Panel: The State of Union - Bartek Plotka, Red Hat; Liz Fong-Jones, Honeycomb; Josh Suereth, Google; Frederic Branczyk, Polar Signals; Rags Srinivas, InfoQ
With microservices and Cloud-Native solutions adoption increasing, Observability is receiving heightened interest in Site Reliability Engineering (SRE) since it enables to chase down the “unknown unknowns,” do Root Cause Analysis and fix issues. InfoQ recently did a virtual panel with experts (URL: https://www.infoq.com/articles/cloud-native-observability/ ) to address fundamental concepts of Observability, including Cloud-Native Observability, some of the misconceptions, technical challenges and industry standards like OpenTelemetry that make it possible to incorporate vendor neutral solutions. Attend this panel to learn about Observability and how to incorporate the different signals from the ground up in a coordinated manner. After attending this panel, attendees will gain a holistic picture of Observability, understand the cultural and technical challenges and how to overcome them.
A
Hello
and
welcome
my
name
is
raghavan
srivas
and
welcome
to
this
observability
panel
on
cloud
native
and
communities
and
really
talk
about
some
of
the
observability
trends,
both
from
a
tactical
perspective.
How,
as
a
developer,
you
can
kind
of
start
using
them
right
now,
but
also
from
more
a
strategic
perspective
of
how
this
is
going
to
look
long
term.
Obviously,
as
all
of
us
know,
you
know,
observability
is
you
know,
probably
as
popular
as
communities
these
days.
A
So
a
lot
of
a
lot
of
you
know
interest
on
observability
a
lot
of
activity,
sometimes
a
lot
of
overlapping.
You
know
activity
as
well,
but
but
I
have
a
great
panel
with
me
who
can
help
clear
those
things
and-
and
you
know,
let
me
go
around
and
kind
of
introduce
the
panel
starting
with
myself.
I
work
for
you
know,
data
stack,
but
I
also
represent
info
queue
and
I
have
a
bunch
of
interests,
but
primarily
in
the
inner
loop
of
development.
A
B
A
C
Hi,
my
name
is
bartek
podca
and
I'm
principal
software
engineer
at
red
hat.
My
role
at
red
hat
is
to
really
bind
all
those
observability
silos
that
we
used
to
have
logging
metric
and
tracing
into
combined
and
uniform
experience,
but
I'm
also
interested
in
programming,
particularly
in
golang.
I'm
writing
my
book
with
aurelie
about
that
and
I'm
also
active
in
the
cncf
space
as
observability
technique
stack
observer
detected
and
prometheus
and
tunnels
maintainer.
A
D
Josh
hi
I'm
josh
ceret,
I'm
working
at
google,
currently
google
cloud,
I'm
responsible
for
telemetry
collection
within
google.
I
am
at
heart,
I'm
a
programming
language
nerd,
so
I
love
rust.
I
love
scala.
I
love
like
esoteric
languages
and
really
interesting
things.
I
read
lots
of
theories,
but
I
really
care
about
developer
productivity
and
that's
why
I'm
into
observability
I'm
a
open,
telemetry
technical
committee
member
and
maintain
a
lot
of
observability
components.
So
it's
pretty
exciting.
A
E
I'm
frederick
I'm
the
founder
of
polar
signals
where
we
do
continuous
profiling.
Maybe
we'll
talk
about
that
a
little
bit
later,
but
my
interests
are
anything
in
observability
really
and
kind
of
for
the
past
five.
Six
years,
I've
worked
on
everything,
that's
kind
of
the
intersection
of
kubernetes
and
observability,
so
I'm
also
a
prometheus
maintainer
and
so
a
lot
of
the
things
that
touch
both
the
prometheus
and
kubernetes
ecosystem.
E
I've
probably
had
my
hands
on
so
I'm
a
prometheus
maintainer,
I'm
also
the
tech
lead
for
kubernetes
instrumentation
and
yeah
I'm
in
a
past
life.
I
was
also
a
security
researcher,
but
that's
I
that
I
usually
just
observe
from
the
distance
these
days
and
yeah
anything
distributed
systems,
I'm
interested
in
as
well.
A
Essentially,
what
we
are
talking
about
is
forensics
in
terms
of
observability
and
yeah.
You
know
with
respect
to
that.
You
know
what
what
exactly
does
forensics
mean
in
the
context
of
observability
and
and
how
do
you
you
know,
kind
of
prepare
for
the
unknown
unknowns.
So
so,
if
you
can
go
around
the
table
and
and
talk
about,
you
know
some,
maybe
an
example
in
your
previous
life
or
now
which,
which
kind
of
help
you
clarify.
You
know
what
what
this
exactly
means,
because
a
lot
of
people
are.
B
How
can
we
understand
what
happened
under
the
hood
and
this
idea
of
not
needing
to
write
additional
code,
write
additional
instrumentation
and
to
have
insights
into
something
that
already
happened
in
the
past?
That
really
blew
my
mind
and
kind
of
got
me
started
down
this
journey
of
thinking
about
unknown
unknowns.
Thinking
about
how
we
answer,
questions
that
we
didn't
anticipate
when
we
originally
wrote
the
code.
D
Think
I
can
oh
yeah
sorry,
I
can
take
a
stab
so
for
me
also
a
a
google
example.
I
was
maintaining
a
project
on
google
assistant
actually,
and
we
were
having
issues
where
every
time
we
demo
to
our
vp,
it
was
very
slow
and
we
needed
to
go
figure
out.
Why,
specifically,
that
device
was
very
slow
and
so
actually
we
had
observability
signals
in
place
to
go
kind
of
identify
the
sub
component
in
this
giant,
complex
system
of
thousands
and
thousands
of
different.
D
E
Yeah
I
mean
I,
I
think,
a
lot
of
what's
already
been
said.
I
I
agree
with
and
there's
a
kind
of
a
saying,
also
in
the
in
the
prometheus
ecosystem,
that
I
think
kind
of
it
doesn't
really
just
apply
to
metrics,
but
the
the
saying
is
kind
of
like
instrument.
First
ask
questions
later
right
and
I
think
all
of
the
examples
that
we've
heard
so
far
already
kind
of
applied
to
this
right.
E
This
data
didn't
come
out
of
nowhere.
Someone
did
go
ahead
and
instrument
this,
but
the
really
interesting
thing
that
we
could
do
because
of
that
is
in
various
situations.
We
could
now
pull
up
this
data
that
we
didn't
even
anticipate
could
have
been
important
for
for
that
situation.
Right,
and
I
think
this
is
the
powerful
thing
about
observability.
C
C
I
believe
that
you
can
kind
of
define
set
of
patterns
set
of
good
methodologies
like
use
golden
signals
or
red
method,
where
every
component
has
those
basic
instrumentation,
either
out
instrumented
by
in
application
code
or
using
some
magic
tools
like
ebpf
or
some
auto
instrumentation
outside,
but
at
the
end
you
have
consistent
statistic
from
each
component
that
then
you
can
reuse,
you
can
rely
on,
but
it
doesn't
mean
you
need
to
know
about.
Every
single
function
call
all
of
the
time
in
the
past
right.
A
Perfect,
let
me
go
to
the
next
question,
which
is
really
you
know.
I
know
that
there
are
a
lot
of
you
know,
technical.
You
know,
efforts
that
are
happening,
but
it's
not
all
about
technology.
We
know
that
right.
You
know.
Sometimes
it's
about
culture
as
well,
but
but
a
couple
of
questions
here
again
one
is
you
know,
is
you
know,
kubernetes,
you
know
with
with
its
adoption.
You
know,
is
it
helping
the
open,
telemetry
efforts?
Or
is
it
really?
A
A
D
Sure
my
answer
is
going
to
be
that
I
think
kubernetes
is
actually
doing
both.
What
kubernetes
does
is.
It
makes
complex
systems
easier
to
create
and
it
kind
of
simplifies
them
so
that
you
can
actually
build
a
huge
distributed
platform
and
just
more
easily
manage
it,
and
so
what
that,
what
that
does?
Is
it
actually
puts
more
pressure
on
observability
to
actually
answer
the
complexity
of
these
systems
that
are
now
easier
to
create,
so
observability
is
that
natural
solution
of
okay?
I
have
a
system,
that's
now
more
complex.
D
How
do
I
observe
it,
and
kubernetes
is
also
trying
to
answer
that
challenge
via
various
technologies,
and
if
you
look
at
the
cncf
portfolio
of
observability
solutions,
I
think
you're
seeing
all
the
key
ones
in
there.
So
I
would
say
that
a
little
bit
of
this
is
both
we're
doing
more
complex
things
and
we
need
more
complex
observability
to
answer
the
answer
that
call.
B
I
think
there
are
a
couple
of
ways
that
kubernetes
makes
it
easier.
In
particular,
the
adoption
of
service
mesh
technologies
alongside
kubernetes,
has
really
accelerated,
making
distributed
tracing
available
out
of
the
box.
I
also
feel
like
the
easy
ability
to
run
agents,
as
sidecars
in
kubernetes
makes
again
adoption
and
standardization
a
lot
easier.
E
Okay
yeah,
I
would
agree,
especially
with
the
standardization
aspect
that
liz
was
just
saying.
I
think
kubernetes
essentially
has
given
given
us
a
common
language
that
we
can
talk
about
right,
and
this
is
not
even
just
about
observability,
but
this
is
just
kind
of
the
effect
of
kubernetes
in
general.
Right
kubernetes
is
kind
of
the
same
wherever
you
implement
it,
and
so
namespaces
are
the
same.
C
Yeah,
I
I
don't
have
very
much
to
add
on
those
those
words
like
it's
essentially
a
huge
opportunity
from
community
side
to
create
abstractions
that
allows
us
to
you
know,
standardize,
metadata
and
and
the
ways
we
observe
staff.
So
that's
incredible,
but
the
question
is
cuban
is
helping
standardizing
observing
the
effort
can
be
also
answered
in
obvious.
Yes,
because
it
makes
things
more
complex,
so
it
demands
more
observability.
C
A
A
Completely
get
the
fact
that
you
know
standards
definitely
help
here.
Obviously,
open
telemetry
is
like
the
second
most
popular
project
in
cncf
behind
communities
right.
We
all
know
that.
But
really
you
know
open
telemetry
is
so
broad
and
yet
application
development
is
so
narrow
right.
So,
in
other
words,
if
I
am
a
perl
programmer
right
and
as
strange
as
it
may
seem,
there
was
some
noise
about
kind
of
creating
a
per
language
working
group
right.
So
what
do
you?
How
do
you?
How
do
you
address
these
edge
cases?
A
You
know
standardization
is
great,
but
but
you
know,
unfortunately,
we
live
in
a
world
where
you
know
everything
is
not
standard
right
and
what
about
the
non-communities
language,
specific,
rust,
scholar,
josh?
I
know
that
you
know
you're,
a
scholar
fan
right.
How
do
you?
How
do
you
kind
of
support
those
different
development
platforms?
Personally,
let's
start
with
bartek
this
time.
If
you
have
any
thoughts,
sure.
C
Yeah,
I
think
it's
a
complex
problem
and
that's
why
we
see
a
lot
of
effort
from
open
telemetry
to
really
drive
into
supporting
so
many
different
languages
and
building
communities
around
that,
and
I
think
this
is
really
really
important.
You
know
one
way
is
to
just
maybe
reduce
the
number
of
languages
you
use
right.
That
would
be
nice,
but.
C
You
know,
fortunately,
fortunately
we
are
standardizing
the
data
format.
We
are
standardizing
how
back-ends
looks
like
how
the
queer
languages
looks
like
how
alerting
looks
like
so
we
already
abstracted
away
from
instrumentation.
That
instrumentation
is
the
only
thing
that
has
to
happen
in
a
specific
languages.
Usually
so
that's
you
know
already
smaller
piece
of
work
and
also
there
are
lots
of
tools
that
allows
us
to
be
very
implementation.
Code
agnostic,
like
service
meshes
ebpf,
which
is
emerging
all
those
are
opportunities
for
any
abstracting
that
away
so
making
sure
there's
less
work
there.
A
A
B
Yeah
sure
I
think
that
we
need
to
support
developers
in
adding
instrumentation
to
their
code
right,
like
no
matter
how
good
the
automatic
instrumentation
is
they're,
always
going
to
be
properties,
you
may
want
to
filter
or
break
down
by
that
are
specific
to
your
application
but
yeah.
So
it's
kind
of
this
balance
between
easy
and
out
of
the
box
which
service
meshes
can
do,
but
also
like
you
know.
B
Yes,
your
most
common
language
frameworks
should
support
open,
telemetry
or
other
open
standards
out
of
the
box,
and
you
should
be
able
to
kind
of
annotate
things.
You
know
it
should
be
unthinkable
to
check
in
code
without
experimentation,
in
the
same
way
that
it
would
be
unthankful
to
check
and
code
without
comments
or
tasks,
but
that
requires
all
of
those
languages
and
frameworks
to
support
the
standards.
A
D
You
know
agent
based,
but
what
what
I
think,
where
open
telemetry
wants
to
be
in
five
years,
is
kind
of
targeting
the
underlying
applications
underlying
open
source
frameworks
that
people
use
to
develop
applications
with
built-in
signals
with
built-in
standards
of
like
here's,
the
bare
minimum
for
observability.
Let's
make
sure
everybody's
at
that
bare
minimum
and
that
really
takes
targeting
developers.
So
the
developers
are
providing
the
observability
for
operations
as
opposed
to
starting
from
the
op
side.
A
D
I
think
I
think,
from
a
developer
standpoint,
there's
there's
a
lot,
there's
a
lot
less
unification
or
a
lot
less
common
standards.
You
know
if
you,
if
you
look
at
like
the
prometheus
ecosystem,
for
example,
there's
a
lot
of
things
targeted
at
ops
and
targeted
at
adapting
existing
applications
into
prometheus,
as
opposed
to
those
applications
directly
providing
say
a
prometheus
component
or
a
open,
telemetry
tracing
export,
or
something
like
that
right.
I
think
we're
going
to
start
to
see
applications
providing
the
observability
as
part
of
their
own.
D
B
Yeah,
this
has
coupled
a
lot
to
kind
of
this
devops
idea
of
shifting
effort
left
right
of
doing
this
earlier,
getting
quicker
feedback
cycles.
I'm
really
curious,
though,
to
hear
from
bartek
about
kind
of
the
prometheus
angle,
around
kind
of
how
has
prometheus
been
perceived
in
the
past
with
regard
to
kind
of
ops
and
dev
audiences.
A
E
So
I
I
actually
think
it's
kind
of
the
opposite.
The
the
other
way
around
right.
I
think
prometheus
adoption
happened,
because
so
many
people
built
exporters
and
the
like,
in-process
instrumentation,
followed,
and
so
I
think,
open
telemetry
is
kind
of
on
a
similar
path,
but
kind
of
is
starting
immediately
with
the
with
the
application
instrumentation.
I
think
the
we've
talked
about
service
meshes
a
couple
of
times
today.
E
I
think
that's
kind
of
a
parallel
here
where
service
meshes
do
the
automatic
thing,
that's
kind
of
the
parallel
to
the
exporter
and
prometheus,
I
would
say
where
someone
else
has
done
the
work
for
you.
It's
maybe
not
perfect,
but
it
gets
you
pretty
far
and
it
gets
adoption
going
and
then
the
the
in
process.
Instrumentation,
is
the
thing
that
actually
gives
you
really
powerful
insight,
and
so
I
think
this
is
not
necessarily
clashing.
E
E
For
example,
there
was
a
really
great
case
by
pingcap,
where
they
noticed
that
the
standard
rust,
open,
telemetry
library
was
just
not
performant
enough
for
them
and
they
could
cut
away
a
bunch
of
use
cases
from
that
library
to
make
it
much
more
performant
for
their
very
special
case
right.
But
they
were
still
speaking
the
same
protocol,
and
so
they
were
able
to
tailor
very
closely
to
their
use
case.
C
Maybe
maybe,
on
top
of
that,
like
some
small
works,
like
I
think,
yeah
standardization
helps
because
then
you
know
people
developers
can
build
their
own.
You
know
client
support,
but
I
think
the
one
maybe
advantage
what
promotes
used
to
have
or
like
already
has
still,
I
think
the
client
is
so
much
simpler
because
it's
just
http
endpoint
versus
you
know
telemetry.
You
need
to
have
like
much
more
complexity
built
with
the
client,
so
there
is
much
more
work.
That's
why
it's
so
hard
there
to
do.
C
A
Great
the
the
next
question
that
I'm
gonna
ask,
which
is,
I
think
we
kind
of
alluded
to
that.
Is
you
know?
What
do
you
say
to
folks
who
think
that
emitting
more
data
will
help
in
the
you
know
in
the
observability
forensics,
so
to
say
really
observe
more
than
what
you
need
you
know
seems
to
make
sense,
but
is
there
a
point
where
it's
too
much
data-
and
I
think
you
know
some
of
you
alluded
to
this-
you
know
observability
might
get
very
expensive
right.
A
B
B
C
I
want
to
do
like
plus
to
what
list
said
around
the
tooling
side.
So
developer
should
not
really
decide
about
that.
It
should
build
instrumentation
and
you
know,
negotiate
with
sysadmin
and
through
standard
tooling
into
how
much
data
we
want
to
get
from
in
particular
moment
from
particle
services.
So,
ideally
everything
is
dynamic.
I
wish
I
could
just
enable
some.
You
know
more
sampling
on
tracing
side
just
for
one
hour,
when
I
want
to
debug
right
now
right,
so
you
have
lots
of
flexibility
using
this
kind
of
tooling.
C
So
that's
the
answer
on
the
developer
part,
and
I
really
I'm
I
would
love.
I
love
the
idea
of
bringing
this
logging
metric
and
tracing
signals.
All
of
this
is
a
little
bit
duplicated
data,
so
if
we
could
just
reduce
and
maybe
the
site
either
you
use
logging
or
I
you
use
just
tracing
so
you're
ready
from
three
things.
You
have
only
two,
that's
already
a
significant
amount
and
some
mitigation
to
this
problem
of
overall,
too
much
data.
D
Yeah,
I'd
like
to
echo
into
that
with
what
we
see
in
open,
telemetry,
instrumentation
right
now
is:
there's
a
goal
to
have
an
instrumentation
api
that
will
extract
all
of
trace's,
logs
and
metrics
kind
of
with
with
a
single
hulk
if
you
will,
but
the
other.
The
other
problem
that
we
have
is
how
much
attributes
and
kind
of
data
to
attach
to
the
telemetry
that
you're
generating
and
how
configurable
does
that
need
to
be
right.
D
So
to
some
extent
the
instrumentation,
because
it's
expensive
to
write
initially,
should
have
everything,
instrumented
and
everything
as
possible
to
extract,
but
you
don't
want
to
pay
that
cost
all
the
time.
You
know
you.
You
only
want
to
turn
that
on
when
you
need
it,
because
if
we
did
everything
it'd
be
way
too
expensive.
So
I
think
what
you'll
see
going
forward
is
exactly
what
bartek's
talking
about.
B
I
think
the
synergy
of
future
flagging
and
observability
is
really
really
powerful
right
to
be
able
to
configure
your.
You
know:
debug
levels,
almost
whether
it
be
your
logging
debug
levels
or
whether
it
be
on
the
metric
side,
adjusting
the
frequency
of
collection
or
on
the
tracing
side
saying,
do
you
really
need,
like
all
of
your
hdb
client,
hey?
E
I
don't
think
I
have
much
more
to
add,
but
I
I
do
think
this
is
a
really
difficult
thing
and
I
don't
think
there
is
a
clear,
clear
answer
to
this,
even
because,
even
even
if
we
had
tools
like
we
just
described
where
we
can
switch
things
on
and
off,
we
don't
necessarily
have
that
for
the
past,
then
right
and
so
that's
kind
of
what
we
talked
about
observability
being
valuable
for
earlier
already.
So
it's
kind
of
a
paradox
almost
right,
so
I
think
it's
a
really
difficult
thing
to
make.
E
The
right
decision
on,
I
would
say,
there's
also
definitely
a
progression
of
of
people
and
their
observability
data.
What
I've
seen
often
I
maintain
a
project
called
coop
prometheus,
where
there's
a
a
very
large
amount
of
data
out
of
the
box
in
in
your
prometheus,
that
is
collected
from
kubernetes
components
and,
frankly,
most
most
users
that
are
just
starting
out,
don't
understand
much
of
this
data
right
and
as
they
use
it
more.
They
start
to
start
to
figure
out
which
data
is
useful
to
them.
E
A
Perfect,
I
had
a
couple
of
questions
more,
but
but
I
think
we
are
kind
of
hitting
you
know
the
end,
so
I
will
kind
of
combine
those
two.
You
know,
although
it's
probably
not
a
good
idea
to
combine
questions,
but
I'm
going
to
do
it
anyway
right
for
somebody,
you
know
who's
kind
of
starting
new
and
observability.
You
know
how
do
you
kind
of
you
know
get
them
to
walk
crawl
run
right.
The
second.
B
A
E
Yeah,
so
I
I
think
the
the
biggest
challenge
I
see
for
us
going
forward
is
mostly
a
cultural
one.
I
think
first
of
all,
like
we
like
observability,
is
definitely
still
growing
and
a
lot
of
companies
still
aren't.
Even
when
I
talk
to
people
in
the
community,
some
companies
still
don't
do
any
monitoring
right,
like
it's
pretty
crazy,
like
we're
all
in
kind
of
a
bubble
where
we,
we
think
everybody's
an
expert
in
all
of
these
things
and
I
think,
there's
still
a
lot
more
education
of
the
market.
E
That
needs
to
be
done,
and
I
think
there's
also
kind
of
that.
This
culture
change
that
needs
to
happen
in
the
entire
community,
where
yes,
like
logs,
metrics
and
traces,
are
really
useful
signals.
But
I
think-
and
this
is
partly
why
I
found
polar
signals-
I
think
there's
so
much
more
data
out
there
that
we
may
be
missing
out
on
that
can
shed
a
light
on
different
nuances
of
our
systems.
Right,
like
logs,
metrics
and
traces,
have
certainly
been
extremely
valuable,
but
I
think
it's
primarily
humans
liking.
D
So
you
know
it
am
I
going
to
do
metrics
I'm
going
to
do
logs,
I'm
going
to
do
traces,
maybe
pick
one,
and
my
recommendation
is
actually
logs
and
metrics
are
logs
and
traces
specifically
because
you
can
monitor
kind
of
slos
and
and
understand
when
systems
are
going
slow
and
then
dive
into
root
cause
and
that's
a
decent
start
right
and
then
from
there
kind
of
expand.
You
know
event.
If
you
talk
about
crawl
walk
run
crawling
is
just.
Can
I
deal
with
a
system
that
goes
down
and
running
is?
D
Can
I
evaluate
whether
or
not
a
feature
I
just
released
improved
my
business
right
and
like
to
go
from
a
to
b?
Is
a
journey
and
you
shouldn't
expect
to
be
able
to
answer
b
just
because
you
have
observability,
you
need
to
actually
go
through
all
the
steps
to
go
from.
You
know
just
doing
kind
of
ops
based
reactionary
actions
to
getting
to
those
business
based.
I
can
actually
understand
features
that
I
released
and
how
they
impact
my
bottom
line
with
the
same
kind
of
instrumentation
anyway,.
C
C
I
would
say
so
and
and
we're
talking
about
the
large
amount
of
data
data
and
different
collection
pipelines
and,
and
who
knows,
maybe
different
signals
but
being
able
to
to
use.
You
know
similar
systems,
similar
method
methodologies,
that
everyone
knows
that
works
for
those
variety
of
different
cases
and
with
amount
of
the
data
that
we
we
collect.
Every
day,
this
requires
lots
of
innovation
and
and
work.
B
Yeah,
I
think,
actually
the
thing
with
regard
to
crawling
that
many
people
are
not
doing
yet
is
shortening
their
release
cycles.
It's
really
challenging
to
get
good
observability
if
you're
not
able
to
get
the
instrumentation
that
you
need
deployed
into
production
alongside
your
alongside
your
code,
right
like
if
it's
taking
months
for
you
to
release
new
software,
you
need
to
focus
on
that
first,
and
not
necessarily
on
observability
would
be
my
advice
with
regard
to
kind
of
the
future
challenges.
B
I
think
the
main
thing
that
we're
grappling
right
now
with
is
this
proliferation
of
definitions
of
observability
kind
of
of
observability
washing,
and
I
really
worry
that
the
word
observability
is
going
to
be
confused
in
the
market
in
the
same
way
that
the
word
devops
gets
applied
to
everything
and
I
think
that'll
really
hold
people
back
from
achieving
these
best
practices
around
being
able
to
debug
unknown
unknown
problems.
So
I
think
that's
what
we
need
to
focus
on
as
an
industry
over
the
next
couple
of
years
is
really
kind
of
standardizing.
A
Thank
you
liz.
I
think,
that's
a
wrap.
I
really
want
to
thank
you
all
for
listening
to
this
panel
and
I
really
want
to
thank
all
the
panelists
for
their.
You
know
esteemed
opinion.
You
know,
I
know
this
is
a
space.
That's
going
to
grow
quite
a
bit
and
again
thanks
for
listening
and
have
a
good
rest
of
the
conference.