►
From YouTube: Services Don’t Have to Be Eight-9s Reliable with Liz Fong Jones from Honeycomb | Kongcast Episode 1
Description
In this Kongcast episode, Liz Fong-Jones, principal developer advocate at Honeycomb, introduces us to the concept of error budgets for service-level objectives (SLOs) and demonstrates how to accelerate software delivery with observability.
Learn more about service reliability and observability on Honeycomb’s blog: http://hny.co/blog
Check out the preview version of Liz's new book "Observability Engineering" https://www.oreilly.com/library/view/observability-engineering/9781492076438/
Follow Liz on Twitter: https://twitter.com/lizthegrey
Subscribe to get email alerts for the latest new episodes and see which guests are coming on the show next: https://bit.ly/3zQV71e
▬▬▬▬▬▬ TIMECODES ▬▬▬▬▬▬
0:00 Kongcast Show Intro
0:28 Welcome Liz!
1:56 SRE vs. DevOps
5:08 How to Measure Site Reliability
7:00 SLO vs. SLA
9:33 Structuring SLOs
12:27 Liz's Take on "Move Fast, Break Things"
15:34 Liz's Take on Continuous Delivery
18:10 Observability and What to Measure
23:00 More About Distributed Tracing and Tools
25:15 Keeping Developer Communities Healthy
28:33 Software Is Everywhere
30:13 Demo: Honeycomb Service-Level Objectives
34:37 Book Recommendations from Liz
36:23 Thanks for Joining, Liz!
37:00 Kongcast Show Outro
▬▬▬▬▬▬ ABOUT KONGCAST ▬▬▬▬▬▬
Hosted by @ViktorGamov and Kaitlyn Barnard, we interview software developers and technology leaders at the top of their game every other week. We’ll also give you the tools, tactics and strategies you need to take your distributed architectures to the next level. Kongcast goes beyond the buzzwords and dissects real-life applications and success stories so that you can tackle your biggest connectivity challenges.
▬▬▬▬▬▬ KONG COMMUNITY ▬▬▬▬▬▬
⭐ https://github.com/Kong/kong
🐦 https://twitter.com/thekonginc
🌎 https://konghq.com/community/
🍻 https://www.meetup.com/pro/kong
❓ ️https://discuss.konghq.com/
💯 https://konghq.com/kong-champions/
#SRE #DevOps #Microservices
B
B
You
are
known
from
you
know,
observability,
community
and
sre
community
very
well.
I
I
follow
you
for
a
while,
given
my
time
at
the
confluent,
I
heard
some
of
the
good
things
about
you,
so
I'm
super
excited
that
to
have
you.
Finally,
in
the
show,
if
you
are
not
me,
and
you
don't
know
who
liz
is,
can
you
please
tell
us
our
listeners
a
little
bit
about
yourself.
C
B
C
B
So,
let's,
let's
talk
a
little
bit
about
this,
so
the
people
know
there's
like
a
devops
thing
and
different
people
have
a
different
definition
about
this.
Tell
us
what
is
your
definition
and
how
it's
different
from
sre
for
those
of
you
who,
for
some
reasons,
were
not
following
the
the
recent
trends
for
last
like
10
years
or
so
you
would
say.
C
C
What
happens
if
the
software
that
we
write
is
really
really
critical
and
one
of
those
movements
was
devops,
which
was
a
cultural
movement
that
really
aimed
to
make
it
possible
for
software
engineers
to
run
their
own
software
to
kind
of
practice,
continuous
delivery,
kind
of
practicing
agile
operations
and
the
other
phenomenon
that
we
saw
was
devops
or
sorry
was
sre,
which
happened
at
google,
where
ben
traynor
schloss
the
founder
of
sre,
said.
You
know
we
need
to
take
a
different
approach
to
running
google
systems.
B
C
Constraints
and
almost
a
similar
solution
to
the
problem,
just
encoded,
at
least
to
start
with
in
google's
particular
organization
structures
right,
like
of
having
particular
management
structures
of
having
particular
philosophies
around
measurement
of
reliability
and
over
time.
What
happened
was
these
two
communities
were
initially
a
little
bit
at
each
other's
throats
of
you
know
who
came
first,
you
know
who
has
approaches
the
right
approach,
yeah.
B
C
As
one
of
the
people
from
google
who
had
a
lot
of
interactions
with
the
outside
community,
I
looked
at
this
and
I
was
like
wait.
A
second
like
devops
principles,
every
single
one
of
them
that
it's
implemented
in
site,
reliability,
engineering.
We
might
call
it
something
different,
but
it's
like
a
concrete
opinionated
implementation
of
the
devops
principles
right,
whereas.
C
Of
stu,
you
know
how
do
you
do
this?
Well,
you
know
it's
up
to
you.
There
are
some,
you
know
best
practices
from
the
community,
but
I
think
what
I
see
happening
more
and
more
is
that
both
the
devops
and
the
site,
reliability
engineering
communities
actually
are
turning
into
this
kind
of
one
community
that
is
starting
to
become
known
in
the
field
as
kind
of
platform
engineering
right
like.
C
That,
instead
of
having
you
know,
specialists
in
operations
necessarily
right
like
you,
instead
have
this
idea
of
building
infrastructure
for
chronic
teams
at
your
company
figuring
out.
What's
the
right
platform,
how
do
we
contribute
to
it?
How
do
we
make
developers
productive
so
it
kind
of
encompasses
more
than
just
you
know:
production
operations
it
encompasses
things
like
continuous
delivery,
encompasses
things
like
like
like
build
infrastructure,
it
encompasses
things
like
reliability,
measurements
right,
like
it's
kind
of
this
broader
field
that
I
think
has
a
little
bit
more
leverage.
C
Yeah,
I
think
that
when
I
introduce
people
to
the
idea
of
a
service
level
objective
of
an
error
budget,
it
kind
of
blows
their
minds
a
little
bit
right,
but
the
way
that
I
concretely
anchor
it
is,
I
point
out
that
it
doesn't
matter
how
reliable
you
make
your
service
right.
It
doesn't
make
sense
to.
You,
know,
spend
billions
of
dollars
launching
satellites
into
space
in
order
to
make
your
product
more
reliable
right
to
get
that
additional
nanosecond
or
femtosecond
of
up
time
right.
C
A
C
Why
would
you
make
your
service
six,
nine
seven
nines,
eight
nines
reliable?
It
just
doesn't
make
sense.
It's
a
poor
investment
of
money.
It's
a
poor
investment
of
your
energy
too
right.
All
the
energy
that
you're
investing
in
over
investing
in
reliability
could
have
been
spent
towards
innovation
right.
So
that's
kind
of
my
view.
It's
like
figure
out.
What
are
the
customers
minimum
requirements
for
reliability?
B
B
B
Is
it
somehow
related
to
like
the
sales
service
level
agreement
that
we
have
with
our
customers,
and
we
you
know
stating
that
this
is
our
level
of
service
that
we
provide,
and
this
is
what
you
pay
in
our
us
money,
but
what
about
like
a
it's,
a
kind
of
like
external
metric?
What's
what
about
like
internal
metric
that
the
team
should
employ
inside
the
when
they're
running
this
platform
running
this
product?
B
For
you
know
for
the
you
know,
for
the
we
we're
talking
mostly
about
the
sas
teams,
but
it's
also
applicable
to
teams
who
run
some
internal
software
in
the
companies.
Maybe
it's
not
available
to
outside
the
internet,
but
there's
a
lot
of
companies
who
run
internal
platforms
and
systems.
This
needs
to
be
also
reliable.
C
Yeah,
that's
a
really
great
question.
I
think
that
service
level
objectives
do
not
necessarily
require
you
to
have
a
service
level
agreement
and
in
fact
often
your
slo
and
sla
will
be
different.
Even
if
there
is
an
external
customer
with
an
sla
right,
you
have
to
think
about
from
the
sla.
That's
a
legal
construct
right,
that's
a
sales
contract,
that's
a
legal
function.
C
C
So
I
think
that
that
concept
of
thinking
about
you
know
what
are
we
defining
as
a
good
user
experience
that
translates,
regardless
of
whether
you're
serving
internal
or
external
customers,
so
kind
of
interview,
your
customers
figure
out
what
they
need
right:
product
managers,
user
experience,
researchers.
These
people
can
be
very
very
helpful
when
you're
trying
to
understand
what
are
your
users
needs,
whether
they
be
internal
or
external.
B
Yeah
and
the
important
thing
for
me
for,
like
you
mentioned
this,
is
like
a
very
interesting
point
like
we
want
to
our
users
to
be
delighted,
but
we
don't
want
our
users
to
sue
us.
So
that's
a
very
important
thing:
how
the
engineers
and,
for
example,
sales
organization,
look
at
the
things
you
know
engineers
want
to
build
the
systems
that
user
will
enjoy
to
use
and
the
the
sales
people
will
make
sure
that,
like
everything
is,
would
be
you
know
they
will
pay
us
money.
We
will
be
in
a
good
relationship.
They
will.
C
C
C
Both
of
those
are
published
by
o'reilly,
but
I
think
that
you
know
when
it
comes
down
to
actually
concretely
understanding
it.
Let's
talk
through
an
actual
example,
so
at
honeycomb
we
are
a
company
that
understands
your
production
systems.
We
have
to
ingest
telemetry
from
your
production
systems
that
encapsulates
transactions
that
are
flowing
through
your
microservices
and
flowing
through
your
application.
C
That
does
not
mean
that
we're
aiming
for
perfection
right,
but
it
also
means
that
it
is
a
stricter
threshold
than
one
in
a
hundred
or
one
in
a
thousand
events
that
can
that
can
be
dropped
right.
So
it's
kind
of
this
striking
this
balance
that
enables
us
to
innovate
to
make
production
changes
while
at
the
same
time
preserving
your
trust
in
the
fidelity
of
the
data
that
we're
giving
you
right.
C
C
Up
or
down
right
like
the
answer,
sometimes
it's
kind
of
up
and
kind
of
down
right.
So
sometimes
you
know
basically
at
steady
state
we
might
expect
to
serve.
You
know,
maybe
one
out
of
every
one
out
of
every
ten
to
the
you
know,
ten
to
the
fifth
right,
like
one
out
of
every
hundred
thousand
requests.
C
Might
just
you
know
time
out
or
get
dropped
right,
like
that's
just
natural
noise
in
the
system
or
we
might
accidentally
serve
like
one
percent
errors
for
a
little
while
right
and
if
we're
serving
one
percent
errors,
we
can
tolerate
that
for
a
little
bit
longer
than
4.3
minutes
right
like
we
can
tolerate
that,
for,
I
think
400
minutes
right,
like
that,
gives
us
enough
time
to
respond
to
correct
the
anomaly
so
kind
of
we
stop
thinking
about
things.
As
kind
of
you
know,
black
and
white
up
or
down,
we
think
about
things
and
changes.
B
The
internal
ability
to
you
know
to
make
the
changes
the
when
we
want
when
we
like
to
make
those
changes.
So
it's
not
like
a
oh
okay,
so
we
were
down
already
this
this
month
for
two
minutes
like
can
we
afford
to
be
down
another
minute
just
to
do
like
a
quick
deploy
of
some
very
important
feature
right?
B
That's
something
that
you
were
talking
correct
me
if
I'm
wrong
when
we're
talking
about
the
error
budget,
so
you
know
you
can
afford
to
fail,
and
it
should
be
kind
of
like
a
in
the
mindset
that
it's
okay
to
fail,
because
the
computer's
notoriously
unreliable
people
even
more
notoriously
unreliable,
so
the
mistakes
will
happen.
So
we
can.
B
We
can
work
around
this,
but
there
should
be
some
threshold
and
to
the
point
of
this
threshold
and
this
innovation
like
what's
your
take
on,
I
don't
want
to
call
it
like
a
move
fast
break
things,
but
essentially
that
mindset
that
was
emphasized
in
the
facebook
back
in
the
day
and
some
people
use
this
as
they
are
like
a
marching
order.
So
yeah,
let's
do
this,
but
probably
there
is
a
middle
ground
somewhere
right
that
you
know
you
cannot.
C
Yeah,
that's
where
I
think
we
were
formally
reformulating
honeycombs
values
recently
and
one
of
the
things
that
I
kind
of
stuck
and
stuck
around
was
this
idea
that
fast
and
close
to
right
is
better
than
perfect
right.
You
still
have
to
be
close
to
right.
You
know
you
can't
just
be
fast,
but
you,
but
you
know
you
don't
necessarily
have
to
put
perfect
polish
on
every
single
thing
because
you
do
have
to
you
do
have
to
innovate.
So
I
think
that's
kind
of
that
encapsulates
a
lot
of
our
thinking
around.
B
B
C
C
B
B
You
know
the
the
continuous
delivery
like
how
often
how
often
you
deploy
the
production
system
at
honeycomb
like
how
many
times
per
day,
I
remember
there
was
some
of
the
you
know
some
magical
numbers
from
the
bigger
the
companies
like
netflix
amazon.
They
deployed
thousand
times
per
day
in
production.
Things
like
what's
your
deployment
cadence
at
hancom,.
C
Right
now,
we're
deploying
to
production
about
12
to
14
times
per
day,
and
we
would
like
to
make
that
faster
to
us.
It's
not
necessarily
the
number
of
times
that
we
deploy
per
day.
That's
really
what
matters!
What
matters
is
the
latency?
How
long
does
it
take
between
a
developer
writing
a
change
laying
it
in
production?
How
long
does
that
take
and
for
us
it
is
less
than
two
hours
typically
less
than
an
hour
even
and
we
think
that
that's
really
the
sweet
spot.
C
I
think
that
that's
kind
of
the
critical
number
right,
like
obviously
the
kind
of
netflix's
and
the
and
the
facebooks
right
like
they,
they
have
many
many
more
engineers
than
we
do
so,
of
course,
they're
going
to
need
to
deploy
to
production
many
more
times
per
day
than
we
do
right,
like
I
don't
think
that's
the
meaningful
metric.
I
think
it's,
the
kind
of
you
know.
I
look
at
the
dora
metrics
the
scene
of
devops
report
by
accelerate.
I
think
that
those
dura
metrics
are
a
more
precise
encapsulation
right.
C
Which
ones
can
you
bring
like
and
and
a
failure
is
okay.
As
long
as
you
have
some
kind
of
rollback
mechanism
right,
you
have
the
ability
to
route
traffic
via
blu
ring.
You
have
the
ability
to
to
quickly
turn
off
a
feature
flag
right
like
I
think
that
those
things
can
really
mitigate
the
like
allowed
amount
of
failure
in
in
your
releases.
B
When
I,
when
I
was
when
I
was
in
consultancy
like
there
was
a
consultancy
business
before
and
after
that,
I
work
as
a
solutions
architect
in
my
previous
jobs.
I
all
when
we
talk
about
the
things
about
regression
and
how
to
we
will
make
sure
that
we're
not
actually
doing
the
worst
to
our
system.
I
usually
tell
people
that
you
know
before
you
start.
You
know
doing
this
like
establish
this,
like
a
baseline.
C
B
B
C
Yes,
I
often
point
to
time
to
recovery
right
slos
cover
time
to
meaningful
detection
of
how
long
does
it
take
until
you
detect
something?
That's
impacting
customers,
but
I
think
it's
equally
important
to
pay
attention
to
making
sure
the
signals
and
telemetry
coming
out
of
your
system
that
will
enable
you
to
understand.
Why
are
things
broken?
How
are
things
broken
for?
C
Who
are
things
broken
because
often
problems
relate
these
days
to
complex
interactions
of
specific
services,
at
specific
versions
for
specific
customers
and
you're,
never
going
to
turn
that
up
if
you
kind
of
have
bulk
aggregate
statistics.
So
when
we
talk
about
measuring
the
right
things,
I
think
the
primary
source
of
data
that
I
encourage
people
to
have
is
distributed
tracing
data,
that
if
you
have
a
service
mesh
or
if
you
have
the
ability
to
instrument
your
code,
that
ability
to
trace
the
execution
of
requests
flowing
through
your
system
really
helps.
You
understand.
C
Where
is
this
latency
coming
from
right?
If
I'm
in
danger
of
blowing
my
service
level
objective
right,
if
I'm
supposed
to
be
achieving,
you
know
200
millisecond,
page
loads,
instead,
I'm
starting
to
serve
a
lot
of
500
millisecond,
page
loads
to
be
able
to
track
down.
Where
is
that
extra
300
milliseconds
coming
from
is
super
super
powerful
and
it
gets
even
more
powerful
when
it's
not
just.
C
You
know
anonymous
traces
in
the
system
right
where
you
can
figure
out
which
microservice
right,
maybe
but
also
to
have
things
like
you
know,
region
like
language
pack
right
like
you,
have
all
of
these
fields
that
are
meaningful
attached
to
your
traces,
so
that
you
can
then
kind
of
slice
and
nice
and
iteratively
explore
and
understand
what
are
the
commonalities
right?
You
know
what
changed!
I
think
that
that
really
helps
you
debug
things
faster,
because
the
old
approach
to
kind
of
you
know
this
measure.
Everything
was,
let's
monitor
everything.
B
C
B
Exactly
it's
like,
like
a
boy
who
was
screaming
about
the
wolves
and
all
of
a
sudden,
you
don't
care
about
the
rules
anymore,
because
the
you
know
it
just
happened
too
often,
it's
just
kind
of
like
a
get
used
to
it.
I
think
one
of
the
the
important
things
to
people
to
understand
they
need
to
establish
what
the
metrics
are
actually
actionable
or,
like
some,
some
of
the
you
know
threshold.
So
in
this
case
they
can
react
with
something,
and
maybe
there's
a
some
threshold
it.
B
B
Yeah
yeah,
I
agree
so
in
terms
of
so
distributed
tracing
is
the
things
to
implement
into
into
the
system.
Let's
talk
about,
like
actual,
like
pro
there's
a
plenty
of
different
the
products,
some
open
source,
some
of
the
sas
companies
that
implement
like
I
know
that
you
are
participating
in
some
of
the
like
open,
telemetry
initiative
where
it's
it
exists
to.
First
of
all,
it's
actually
the
merge
two
two
projects.
As
far
as
understand.
C
One
of
them
was
to
go
with
your
vendor's
proprietary
solution
and
then
the
other
two
were
open,
tracing
and
open
census,
which
were
one
of
them
was
found
kind
of
by
the
yeager
and
zipping
communities.
The
other
one
was
founded
by
google
and
kind
of.
Basically,
all
these
folks
came
together
and
said:
you
know
what
it
doesn't
make
sense
to
have.
You
know
this
plethora
of
different
vendors
and
also
open
senses
and
open
tracing.
Let's
just
make
it
into
one
project.
C
Let's
make
it
so
you
can
instrument
your
code
once
and
also
have
all
these
common
integrations
and
no
longer
need
to
worry
about.
You
know
if
I
change
vendors.
If
I
want
to
change
from
an
open
source
solution
to
a
vendor
solution,
or
vice
versa,
do
I
need
to
change
everything
right
like?
Can
we
just
make
it
simple
and
easy
for
everyone
so
yeah?
I
think
that
that
is
a
approach
that
has
now
paid
off.
C
C
Right
like,
but
we
have
hundreds
of
companies
participating,
we
have
hunt
hundreds
to
thousands
of
of
engineers
who
have
contributed
at
one
point
in
the
past.
Right
like
I
think
that
it
is
a
sign
of
project,
health
and
interest
that
so
many
people
have
said
you
know
what
instrumentation
is
table
stakes
right.
Our
users
are
complaining
about
how
much
effort
it
takes.
Let's
just
make
it
simple
for
everyone
right,
so
that
that
way,
everyone
can
instead
focus
on
innovating
on
the
kind
of
data
analysis
bit
which
is
kind
of
the
more
interesting
bit.
C
B
Yeah-
and
I
was
always
wondering
how
how
what's
the
what's
a
good
sign
or
like
how
to
steer
this
community
to
keep
it
healthy
to
keep
it.
You
know,
keep
everyone
involved
and
but
not
make
it
like
a
too
much
someone
will.
You
know
the
try
to
drag
the
stuff
on
their
way,
some
vendors.
They
might
have
some
great
ideas
and
they
have
some
great
implementation.
They
want
to
do
this.
Some
other
vendors
will
have
a
pushback.
C
But
ultimately
we
anchor
things
in
like
what
is
the
right
thing
to
do,
for
a
customer
base
right
like
what
best
suits
our
mission
and
while
there
may
be
perspectives
that
are
represented
right,
like
all
of
us,
are
trying
to
represent
those
perspectives
in
order
to
better
serve
our
customers
right.
So
here's.
B
C
There's
kind
of
a
lack
of
clarity
around
what
does
it
mean
to
provide
like
a
number,
for
you
know
for
sampling
rate
right?
What
what
does
it
mean?
Can
we
make
it
unambiguous
right,
like
what
purpose
is
serving?
Is
it
adding
excessive
complexity
right?
And
there
were
some
folks
who
were
like
you
know?
Yes,
we
need
sampling
and
open
telemetry
prior
to
it,
reaching
a
back
end
and
other
folks
were
like
our
backend
can
handle
it
we'll
handle
all
the
sampling
on
our
end.
C
Like
you
know,
please
don't
add
sampling
right,
so
we
had
a
constructive
discussion
about
it
and
we're
now
kind
of
finalizing
a
lot
of
these
recommendations
in
the
sampling
working
group
right.
So
I
think
that
that's
kind
of
an
example
where
people
from
diff
from
different
perspectives
and
backgrounds
came
together
to
figure
out
what
was
going
to
best
serve
our
customer
needs
and,
I
think,
most
crucially,
we
didn't
necessarily
put
it
directly
into
the
1.0
release
of
the
open,
telemetry
specification
right.
C
B
By
the
end
of
the
day,
it's
not
about
tech,
it's
about
how
we
can
communicate
our
ideas
in
a
civilized
way
without
like
implying
the
egos
implying
some
of
the
you
know,
some
of
the
the
selfish
interests
and
things
like
that
to
make
the
world
like,
I
don't
know
it-
will
sound
cheesy
but
to
make
the
world
a
better
place
by
you
know
having
the
civil
civil
conversation
about
certain
things.
Yeah.
B
Yeah
exactly-
and
I
would
I
would
drink
to
that,
because
it's
a
also
responsibility
of,
I
feel
this
responsibility
of
myself
to
help
showing
the
right
ways
right
tools,
and
so
the
people
can
build
the
better
software.
I
always.
I
will
always
consider
the
the
the
software
then
software
engineers
developers
they
may
be
not
serving
they
always
serving
business.
You
know
it's
not
like
something
that
like
makes
money.
B
Usually
you
know
development
as
a
co-centric
slave,
but
by
the
end
of
the
day
in
2021,
without
developers
we
cannot
run
the
business
successfully
because
everything
is
digital
right
now
and
everything
is
software
and
software.
It's
it's
it's
everywhere,
and
it's
in
that
inevitable
to
do
something.
Without
this
you
can
do
the
sell
lemonade,
and
probably
you
don't
need
to
do
any
software,
but
still
you
need
to
fail
your
like
the
taxes
from
your
income
in
this
is
where
the
software
will
help
you.
So
it's
still.
C
Right
or
other
things
like
you
know,
during
the
pandemic,
honeycomb
actually
signed
one
of
our
customers,
which
is
heb,
which
is
a
groceries
chain
in
texas
right
and
part
of
the
reason
why
they
realized
that,
and
if
software
was
so
critical
was
in
that
moment
when
they
shifted
towards
digital
purchasing
right
to
have
people
check
out
online
and
have
groceries
loaded
into
the
trunks
of
their
cars
right.
Yeah.
C
Yeah,
so
I
wanted
to
share
with
you
a
little
bit.
We
talked
about
how
honeycomb
service
level
objectives
are
set
up,
and
I
wanted
to
show
you
what
those
actually
look
like.
So
as
I
mentioned,
we
have
our
beta
ingest
service
and
we
want
to
maintain
a
49ers
availability
target.
So
what
you're
looking
at
here
is
honeycomb
measuring
honeycomb
itself.
C
This
is
our
dog
food
instance,
so
you're
looking
at
real
life
production
data,
that's
flowing
in
and
you
can
see
us
defining
our
service
level
objective
in
terms
of
criteria
on
the
events
that,
for
each
data
point
that
we
receive,
it
should
take
no
more
than
five
milliseconds
to
ingest.
So
this
is
our
mechanism
of
visualizing.
How
are
we
doing
with
our
service
level
objective
and
what's.
C
The
most
right,
so
we
can
see
this
particular
user-
is
contributing
most
of
our
failures.
So
what
honeycomb
lets
us
do
is
not
just
measure
our
service
level
objective,
but
actually
dive
in
right,
so
instant,
for
instance.
We
can
see
here
that
something
like
ten
percent
of
this
five
to
ten
percent
of
this
users.
Traffic
is
failing.
So
that's
something
that
I
might
want
to
let
the
user
know
about.
So
let's
have
a
look
just
at
the
failures
and,
let's
zoom
in
even
further.
C
So
this
is
something
that
honeycomb
really
really
enables
you
to
do,
is
kind
of
to
interactively
slice
and
dice
your
data
and
to
understand
what's
happening
inside
of
the
system.
So,
for
instance,
I
can
drill
down
into
an
individual
application
trace-
and
I
can
see
what's
happening
here,
for
instance,
where
is
the
time
being
spent?
Is
the
time
being
spent
in
our
backing,
or
is
the
time
being
spent
waiting
to
receive
traffic
from
this
particular
customer?
C
So
this
is
an
example
of
how
we
debug
things
with
honeycomb
kind
of
starting
from
the
user,
starting
from
the
utilization
saturation
errors
perspective
and
then
going
to
individual
service
level
objectives
and
then
being
able
to
understand
where
those
service
level
objectives
encountering
problems.
I
think
there's
another
interesting
dimension
to
consider,
which
is.
C
In
addition
to
going
wrong
with
your
application
code
and
it's
really
cool
to
be
able
to
have
that
kind
of
one
interface
to
look
at
everything
from
you
know
your
api
gateway
to
your
elb
to
your
left,
your
lambda
executions,
and
to
see
it
side
by
side
with
what
your
application
is
doing
so
yeah.
That's
that's.
My
demo
is
of
honeycomb
being
used
to
debug
honeycomb
itself
and
how
it
really
enables
us
to
ship
code
quickly.
B
Thank
you
so
much
liz
and
great
to
see
how
the
company
use
their
own
software,
for
you
know
the
monitoring
their
own
software,
a
huge
believer
of
of
the
dog
footing,
and
if
engineers
don't
use
the
work
of
other
engineers
in
the
company
they
they
cannot
create.
This,
like
empathy
to
you,
know
what
the
work,
what
they
do
and
they
would
not
be
able
to
emphasize
with
users
and
that
most
important
thing
to
it
to
to
point
out,
I
would
like
to
you
already
provided
a
couple.
A
couple
good
reads
for
our
listeners.
B
Usually
I
like
to
ask
my
guests
about.
I
I
like
to
read,
or
rather
listening
the
the
books,
and
I
usually
like
to
ask
about
something
that
you've
written
recently
or
maybe
not
recently,
but
like
maybe
something
that
impacted
you
somehow.
So
you
can
share
this.
It
not
necessarily
needs
to
be
technical
book.
It
can
be
fiction
and
science
fiction
or
whatever.
So
what?
What
would
you
recommend
to
to
our
listeners.
C
You
know
I
did
recommend
the
door
report
earlier.
I
think
that
kind
of
from
a
technical
perspective,
it's
a
good
encapsulation
of
what
are
the
principles
of
being
able
to
be
sure
that
you
have
a
resilient
system
that
you
can
ship
software
quickly
to.
But
I
think
that
it's
much
more
important
to
pay
attention
to
the
people
and
interpersonal
aspects,
and
you
know
it's
a
little
bit
of
a
an
old
classic
right,
but
kind
of
you
know
how
how
to
make
friends
right,
dale
carnegie
right,
like
very
oh.
B
C
Yeah
how
to
make
friends
with
influence
people
right
like.
I
think
it
is
important
to
build
interpersonal
relationships,
especially
in
environments
where
you
have
teams
where
you
have
to
collaborate
across
team
boundaries
to
get
things
done
right
like
you,
it's
not
it's
not
just
you
know.
I
write
software.
You
know
I
work
on
feature
requests.
I
go
home
right,
like
it's
kind
of
we.