►
From YouTube: Open Source Summit: Service Mesh
Description
“What is the performance impact that a service mesh has?" "What overhead does being on the mesh incur?” By far, this is the most common questioned by engineers coming to with the value of functionality provided by a service mesh. Generally, this question goes unanswered.
In this session, the methodology and results of performance testing research done in collaboration with a university and through the lens an open source service mesh benchmark tool will be shared and discussed. The benchmarking tool will provide a common benchmark across service meshes (their control planes, like Istio) and modern proxies (their data planes, like Envoy) and will review a number of service mesh projects. In addition to performance, we’ll discuss the landscape of service meshes, characterize and contrast their functionality as well as their data plane and control plane architectures.
Speaker:
Lee Calcote - Founder, Layer5
William Morgan - CEO, Buoyant, Inc.
Manish Chugtu - CTO, Cloud Infrastructure and Microservices, Avi Networks
Zack Butcher - Founding Engineer, Tetrate
Haim Helman - CTO, Octarine
Spike Curtis - Senior Software Engineer, Tigera
A
We've
got
a
good
decent
show
for
you
today,
change
change
my
mind,
mid-flight,
that's
because
I'm
opening
up,
but
we
do
have
a
good
second
half
of
the
show.
We've
got
a
panel
full
of
folks
that
really
know
what
they're
talking
about
some
of
them
are
per
year
within
a
heckling
range,
so
you'll
you'll
get
your
turn.
Oh
very
pleased
to
be
very
pleased
to
be
here.
A
A
Two
things
to
take
away
from
this
I
make
corny
jokes
and
like
to
be
social,
so
please
be
social
I'm
here
to
share
what
I
know
on
this
subject
and
in
a
couple
of
others.
The
only
other
thing
maybe
take
away
from
this
is
the
the
link
to
the
slides
is
the
URL
there
in
yellow
I?
Don't
think
that
the
slides
are
up
just
yet
for
this
one,
but
they
will
be,
and
so
look
at
that
I'm
already
sharing.
A
A
So,
if
you're
a
know
Riley
so
finally,
Safari
subscriber
you
can
go
see
the
uncut
version
now
and
but
you
can
subscribe
at
that
URL
for
to
be
notified
or
to
find
out
more
about
what
the
book
is
and
and
actually
at
that
URL
layer,
5,
dot,
IO
you'll
find
it's
something
of
a
service
mesh
community
and
there's
a
fair
bit
of
info
there.
We
might
talk
about
that
a
little
bit
later,
I.
A
It's
the
environment
in
which
you
probably
have
the
biggest
return
on
investment
for
a
service
mesh
you'll
find
that
when,
if
you're
running
a
lot
of
micro
services,
you
deploy
a
service
mesh,
sometimes
you
might
find
that
the
blinders
come
off
and
you
you
actually
have
you
comprehend.
What's
going
on,
you've
got
a
lot
more
visibility,
probably
find
you
have
a
lot
more
control,
and
maybe
things
become
a
bit
more
secure
does
and
by
the
way,
whether
we
begin
to
get
interactive
right
now
or
a
little
bit
later.
A
A
You
consider
that
they
might
have
value
about
outside
of
that
for
the
other
70%
of
our
world's
workloads
in
VMs
or
on
bare
metal
or
mainframes,
or
they
do
what
they
do.
You
may
not
gain
as
many
benefits
as
you
would
if
you
were
running
lots
and
lots
of
cameras
and
we're
having
to
track
those
and
secure
them
in
a
different
way.
A
That's
actually
one
of
the
advantages
that
we're
gonna
talk
about
what
the
service
mesh
that
these
things
are
a
service
mission
and
there's
a
variety
of
them.
We're
going
to
look
at
some
of
those
today
are
applicable
not
only
in
containerized
environments,
but
also
outside
of
containerized
environments.
As
a
matter
of
fact,
it's
a
way
in
which
some
might
or
many
will
come
to
a
service
mesh
and
find
value
in
it
without
having
containerized
anything
which
is
now
that
I'm
sort
of
articulated
in
this
way,
I'm
beginning
to
feel
uncomfortable.
A
It's
almost
heresy
at
docker
con,
specifically
since
I'm
a
docker
captain,
and
so,
if
we
could
add
out
that
part
later,
I'd
like
to
I'd
like
to
continue
to
be
a
docker
captain.
That
wasn't
my
point.
My
point
was:
is
that
you'll
find
lots
of
value
in
both
worlds,
so
there
is.
This
is
a
burgeoning
and
really,
in
my
mind,
sort
of
a
third
step
that
some
take
within
their
cloud
native
journey.
I'm
gonna
do
some
tongue-in-cheek
things
here
today
and
that's
one
of
them.
This
isn't
necessarily
your
third
step.
A
Maybe
maybe
your
first
step
is
containerization,
maybe
if
you're
doing
something
very
meaningful
with
a
lot
of
containers
that
second
step
is
container
orchestration
and
then
maybe,
when
you
can't
figure
out
what's
going
on
and
you
need
some
control,
you
bring
in
this
third
phase
of
of
a
service
mesh
that
isn't
the
only
path
to
cloud
native
that
there's
lots
of
of
those
different
ways.
Point
here
that
that
is
to
be
made
is
that
this
is
a
there's,
a
burgeoning
ecosystem
of
not
only
service
meshes
themselves,
but
some
other
things
that
look
pretty
well.
A
A
If
somebody
could
compare
that
to
something
that
compared
the
new
thing
that
I'm
trying
to
learn
to
the
the
thing
that
I
already
understand,
that
really
helps
my
my
small
minded
and
one
of
those
that
I
feel
like
I.
Really,
you
know
understand
pretty
well,
is
a
container
Orchestrator,
a
high
level
I've
already
mentioned
kind
of
at
least
at
least
in
today's
service
meshes
the
sort
of
top
three
categories
of
value
that
you
would
derive
for
them.
I
had
said:
I,
think
I'd.
A
If
I
said
I
said,
take
the
blinders
off
and
by
that
I
meant
gain.
Some
visibility
gain
a
lot
of
observability
gather
a
lot
of
new
or
additional,
and
some
new
telemetry
that
you
are
maybe
not
likely
to
be
gathering
today
from
your
container
orchestration
system.
Let
that's
one
another
one
is
some
fine
grained
control,
specifically
at
the
application
layer
at
layer,
seven,
the
third
one
here
being
security
and
fine,
fine,
grained
security-
that
maybe
you
don't
have
in
your
environment
today
and
we'll
ask
this
question
of
some
of
our
panelists
later.
A
But
in
my
mind
there
are
other
categories
of
capabilities
things
you
might
come
to
expect
from
your
network
from
your
service
mesh
network.
Today.
Those
are
the
three
if
you're
saying
to
yourself,
you're
asking
this
question.
Well,
hey
of
those
think
you're
right
but
I'm,
running
swarm
where
I'm
writing
no
matter.
Bassist
marathon,
I'm
running
kubernetes,
I
I've
got
some
visibility.
I've
got
some
metrics
I've
got
telemetry
I've
got
something
control,
there's
Network
policies,
there's
other
types
of
control
to
be
put
in
there.
Well
yeah.
This
is
entirely
accurate
and
we
hence
the
confusion.
A
The
I
would
put
it
as
that
containers
and
well
or
container
Orchestrator,
specifically
and
here's
another
bit
of
tongue-in-cheek
for
you,
but
have
had
to
focus
necessarily
on
infrastructure
concerns,
layer,
four
sort
of
on
downs
centric
that
doesn't
clearly
that
doesn't
technically
mean
that
kubernetes
and
other
container
orchestrators
aren't
doing
things
at
later,
seven
and
taking
care
of
some
of
those
concerns,
but
that
they've
had
those
projects
they've
had
to
focus
on
nodes
clusters
forming
them.
You
know
a
lot,
you
know
providing
an
admission
to
them.
Managing
you
know,
scheduling
very
efficiently.
A
Yes,
there
are
some
health
checks
that
you
would
consider
like
hey
if
it's
container
Orchestrator
scheduled
as
a
container,
they
would
do
a
health
check
and
that
health
check
is
possible
to
do
it
later.
Seven,
it's
also
kind
of
I,
often
times
by
default,
just
at
a
container
level,
not
necessarily
for
the
number
of
processes
or
that
you're
running
inside
and
whether
or
not
you
know
it'll
check
if
they're
up,
but
maybe
not
whether
or
not
they're
actually
responding
in
the
right
way,
and
so
by
way
of
just
a
quick
example
there.
A
My
point
being
is
those
lower
levels
have
been
lower,
layers
have
been
fairly
well
considered
for,
but
at
an
application
level
they
maybe
haven't
been
all
the
way
considered
for
so
I'm
gonna
make
a
couple
of
statements
today
that
you're
welcome
to
beat
me
up
on
Twitter
about
or
or
our
esteemed
panelists
can
can
take
a
crack
at
later.
One
of
those
is
that
my
perspective
is
that
you
know
container
Orchestrator
or
that
you
can't
call
something
in
a
container
Orchestrator
unless
it
has
these
three
capabilities.
Cluster
management,
which
I
just
talked
about
forming.
A
You
know
establishing
nodes,
forming
clusters,
taking
care
of
them
service,
discovery
and
scheduling,
and
you
can
see
that
container
orchestrators
do
these
other
things
very
well
and
and
provide
a
little
bit
for
applications
and,
as
the
years
have
gone
by
more
and
more
application
level,
concerns
have
been
considered
for,
but
there's
a
lot
more
left,
hence
still
still
a
place
for
the
service
mesh
to
play
and
service
meshes
generally
rely
on
operate
at
a
higher
level.
I
would
I
would
argue
sort
of
layer,
five
and.
A
A
There
are
others
that
attack
on
an
additional
I
was
gonna,
say
an
additional
marketing
nuance,
but
I,
don't
I,
don't
believe
it's
just
a
marketing
nuance
there.
There
are
those
of
a
classic
kind
of
micro
services,
API
gateways-
and
these
are
the
ones
that
are
fairly
developer
friendly,
got
API
friendly
and
also
are
have
native
integrations
with
modern
infrastructure
like
container
orchestrators.
A
Okay.
Well,
if
those
other
systems
are
providing
those
things
like,
what
else
is
it
that
we
need
and
we
need?
You
know
each
of
these
things
the
things
that
I've
just
mentioned-
I
didn't
say
resiliency,
but
you
need
well
clearly
you
need
a
service
mesh,
which
is
why
you're
here,
but
to
describe
a
service
masta
a
little
bit
better.
A
First
network,
a
network
that
is
there
to
provide
you,
the
things
that
you
would
need
to
handle
within
a
distributed
systems
environment,
to
understand
the
fact
that
the
network
is
now
part
and
parcel
to
potentially
every
single
interaction.
Every
single
piece
of
functionality
that's
happening
within
your
distributed
system
within
your
distributed
application
service
meshes,
aren't
going
to
give
you
everything
that
you
need
think
if
you've
read
a
if
you've
been
introduced.
Briefly,
if
you've,
what
you
know
write
a
30-second
description
of
the
service
message,
you've
heard
things
like
and
these
are-
these
promises
are
true.
A
There
are
some
asterisks
in
some
in
some
cases,
but
that
you'll
you'll
gain
a
lot
of
these
benefits,
not
not
necessarily
with
any
code
change
to
your
application
and
in
many
cases,
not
any
code
change
to
your
manifest
to
your
spec
files.
Either
it's
a
pretty
sweet
deal,
there's
a
little
bit
of
magic.
Sprinkles
that
go
in
there.
A
We're
gonna
try
to
illuminate
some
of
those
point--is
surface
meshes,
don't
get
you
all
the
way
either
part
of
what
I
was
going
to
say
is
that
of
some
of
the
visibility
and
new
telemetry
that
you'll
gain
out
of
a
service
mesh,
at
least
as
they
are
today.
There's
a
fair
bit
of
that.
That
is
black
box
2d,
your
application,
that's
running
inside
your
container,
the
one
notable
exception
there
is
the
facilitation
of
distributed
tracing,
that
you'll,
find
in
most
service
rushes
and
then
that's
sort
of
full-blown
APM
well,
not
full-blown.
A
That's
quite
a
lot
of
visibility
and
certainly
falls
into
the
class
of
classes.
Classify
quarry
classification
of
application
performance
management,
APM,
okay,
I
mentioned
before
that
we
talked
about
client
libraries,
client
libraries
are
really
more
infrastructure.
Centric
concerns
the
the
timeouts,
the
retries
that
went
to
circuit
break
the
the
other
concerns
that
get
embedded
into
your
application
and
they
become
bothersome
because
you've
got
a
version.
Those
and
versioning
those
means
doing.
A
A
A
That's
not
I
mean
certainly
you
know,
others
are
attracted
for
different
reasons,
some
of
them
being
these
fine-grained
traffic
control
layer.
Seven
in
steering
some
blue
green
blue
green
deploys
canary
deploys
doing
things
in
a
declarative
way.
Controlling
the
way
your
traffic
is
flowing
in
a
declarative
way,
maybe
opening
up
the
packet
and
and
looking
to
see
if
you
know
if
Bob
is
signed
in
and
or
if
he's
of
a
belongs
to
a
certain
account
that
is
over
their
limit
or
needs
they're
of
a
certain
account.
A
A
The
resiliency
here
is
pretty
interesting,
certainly
an
attractive
component,
and
it's
not
just
about
providing
resiliency
by
doing
circuit
breakers
and
these
health
checks
and
rate-limiting
and
things.
It's
also
about
maybe
instigating
a
bit
of
trouble
and
maybe
creating
a
bit
of
chaos
and
seeing
what
happens
if
you
consider
that
these
service
meshes
are
powerful
by
way
of
their
their
network
capabilities,
they
they're
able
to
induce
latency
drop
a
few
packets
shut,
shut
things
down,
see
what
happens
so
it's
a
great
can
be
a
great
facilitator
of
chaos.
A
There's
some
security
things
that
I
didn't
I
come
skipping
over
and
not
maybe
I'll
mention
it
briefly.
I'd
said
that
the
third
pillar
today
is
probably
security,
and
that
is
you'll,
hear
about
mutual
TLS
and
peer-to-peer
authentication
and
encryption
between
your
micro
services
so
no
longer
necessarily
having
a
soft
gooey
Center
inside
of
your
cluster
and
a
hardened
outside,
but
rather
hardened
through
and
through
once
that's
once,
you
begin
to
just
take
that
for
granted
and
that's
how
your
infrastructure
runs.
Imagine
you'll
run
it
maybe
a
little
bit
differently.
A
A
A
Actually
you
know
hey,
you
know
Lee,
it's
not
necessarily
the
security
that
control
the
the
observability
and
other
things
yet
to
come.
It's
actually
the
notion
that
now
you
what
you're
telling
is
like
enabling
you're
diffusing
responsibility,
you're,
giving
a
new
tool
set
and
a
new
level
of
control
over
these
concerns
and
empowering
dev
the
devs
and
the
ops
to
iterate
a
bit
independently
to
move
a
bit
more
quickly.
A
If
you
were
listening
to
any
of
the
keynotes
I
think
the
notion
of
speed
was
probably
the
underbelly
too
much
of
the
context
of
why
people
do
why.
You
know
why
we're
doing
containers
where
I
do
cloud,
why
we
do
cloud
native
things?
Why
we're
why
people
deliver
SAS?
Not
you
know
much
more
so
than
they
do
shrink,
wrap
things
anymore.
It's
for
speed
and
some
point.
Bang
is
to
the
extent
that
these
teams
have
a
new
tool
that
they
can
move
faster.
A
Let
me
demonstrate
this
by
maybe
asking
this
question
so
so
again,
I
think
we're
on
like
a
fourth
or
fifth
question.
This
way,
so
I'm
going
to
expect
them
back
later
in
your
environments,
for
something,
like
rate
limiting
an
API
rate
limiting
and
an
HTTP
endpoint
that
you
have
do
if
you've
got
if
you're,
whether
you've
just
got
Devon
just
got
ops
or
or
or
what
have
you
whose
responsibility
is
it
to,
and
you
know,
define
the
rate
limit
and
enforce
the
rate
limit
in
your
environment.
A
Ops
very
good,
oops
Dave,
who
knows
and
honestly,
and
that's
actually
that
that's
I'm
sure
that
that's
an
answer.
I've
spoken
to
lots
and
lots
of
folks
about
this
particular
topic
and
and
the
answers
are
every
which
way
and
its
environment
dependent
and
that's
and
in
my
belief,
is
in
part
because
there
isn't
necessarily
standardized
tooling
or
there
hasn't
been
until
service
measures
have
come
along.
A
Declaratively
provide
control
over
this
you
know
source
or
version
controlled
declaration
of
how
it
is
that
you
want
these
things
to
run
how
it
is
that
you
want
to
limit
your
your
api
is
in
the
rates
by
which
they
respond
so
an
important
concept.
This
is
one
of
those
slides
where
I
just
like
to
take
a
moment
and
study
the
blueprint
here.
You
guys:
okay,
good,
all
right,
I'm,
gonna
somewhere
in
here,
I'm
gonna
make
a
statement,
and
it
looks
like
it's
at
the
bottom
of
the
screen.
A
Surface
meshes
you
hear
about
two
different
planes
and
if
you
know,
if
you're,
if
you've
been
in
networking
or
study,
that
these
are
probably
familiar
to
you
as
a
matter
of
fact,
if
you've
been
using
container
orchestrators
a
control
plane
and
maybe
a
data
plane
that
you've
heard
of-
but
you
certainly
heard
of
a
control
plane,
these
things
kind
of
make
some
intuitive
sense.
I
think
the
data
plane
here
is:
where
is
where
the
surface
mesh
handles
all
the
traffic
itself?
A
A
You
will
also
see
a
control
plane
inside
of
service
meshes,
and
this
is
where
the
operator,
or
maybe
the
developer,
comes
to
define
policy
comes
to
configure
your
your
how
it
is
you'd
like
for
at
operate,
some
of
called
service
meshes
actually
in
general
configuration
management
for
service
proxies,
which
that's
that's,
accurate,
there's
more
there's
more
than
that.
It's
also
again.
If
your
heritage
is
network
engineering
or
not,
you
may
be
familiar
with
a
management
plane
as
well.
I'm
gonna
give
an
example
of
a
magic
plane
here
today.
A
A
If
we
take
so
one
of
the
surface
meshes
that
you
might
have
heard
about
is
Sto
most
of
the
surface
meshes
have
a
sample
app
that
comes
with
them
to
help
you
learn
the
mesh
and
demonstrate
their
capabilities
in
a
SEOs
case,
this
one's
called
book
info,
which
is
not
to
be
confused
with
book
catalog
from
link
Rd.
But
this
is
how
traffic
so
in
this
sample
app
to
familiarize
with
it
very
quickly.
It
is
boy
I'm
having
all
the
fun
up
here.
Okay,
hey
we're
gonna
have
some
fun
man.
It
is
this
particular
app.
A
Where
is,
does
its
job?
Well,
it
demonstrates
the
power
of
a
surface
mesh
by
saying
here's,
four
services
they're
all
written
in
four
different
languages,
whereas
you'd
normally
have
potentially
four
different
client-side
libraries
you
can
take
those
the
surface
mesh
will
dissolve.
Those
concerns
provide
you
with
a
lot
of
control.
Your
traffic
flows
like
this.
This
is
you've
sort
of
taken
in
context
of
a
kubernetes
environment.
So
you've
got
four
services
they're
running
it's
just
a
simple
book
catalog.
If
you
deploy
it
on
the
mesh.
A
This
might
be
what
it
looks
like
you
know:
there's
a
few
different
deployment
models
for
how
you
do.
You
know,
deploy
service
specialist.
This
one
has
certainly
gained
in
popularity
and
that
is
more
or
less
by
side,
carring,
service,
proxy
and
again
in
Innes
Tio's
case
the
default
kind
of
out
of
the
default
batteries
included
or
a
service
proxy
called
envoy.
A
So
let's
look
at
East,
EOS,
Market,
Market
texture
in
specific
here's,
stos
control
plane,
the
blue
dashed
constructs.
These
two
gateways
are
are
well
I,
think
I
think
many
might
actually
put
the
the
ingress
gateway
in
a
solid
line,
sort
of
say:
hey!
That's
that's
probably
required.
That's,
probably
a
bit
more
accurate.
Let's
not
focus
on
that,
though.
Let's
go
to
the
control
plane
and
look
at
the
notion
that
the
control
plane
components
are
again.
A
This
is
presented
inside
of
a
kubernetes
context
that
they're
these
control
plane,
deponent
components
are
deployed
inside
of
a
namespace
there's
a
few
of
them
that
have
different
responsibilities
and,
let's
not
there,
there's
other
talks
that
go
through
all
those.
This
is
again
kind
of
the
sort
of
generic
model
of
how
it
is
that
traffic
would
flow
through
how
it
is
that
telemetry
would
be
gathered
and
stored.
How
it
is
that
policy
might
be
checked
on
and
enforced
people
might
you
know,
requests
might
be
rejected.
A
Link
or
D
some
similar
some
components
that
perform
some
similar
functions.
Linker
D
is
the
that
set
of
maintainer.
Z--
has
been
at
things
at
this
service
special
stuff
for
a
while
and
and
moves
quickly
and
and
so
that
control
plane,
as
it's
described,
there
might
be
missing
one
one,
newer
component
and
so,
but
is
by
and
large,
accurate,
so
you're
seeing
a
lot
of
similarities.
You'll,
you
know,
like
I,
said:
you'll
find
some
some
differences
as
well.
Okay,
there's
a
lot
of
ways
to
deploy
a
service
mesh.
A
You
guys
have
been
listening
to
me
talk
for
quite
some
time.
Thank
you.
We're
not
going
to
go
through
those.
Rather,
what
I
would
say
is
there's
a
a
yet
to
be
stale
free,
short
book
on
the
subject.
That
I
would
recommend
that
you
read
it's
not
that
long.
It
does
go
through
a
number
of
different
deployment
models,
which
I
think
are
both
help.
You
understand
why
things
have
arrived
at.
A
Have
this
sidecar
model
of
service
master
deployments,
but
also
will
help
maybe
energize
you
or
encourage
you
that
doesn't
have
to
be
an
all-or-nothing
thing
that
you
can
start
piece.
Mail
start
start
moving.
If
you
were
watching
I
think
it
was
the
day
two
keynotes,
the
the
announcement
of
sto
ingress
and
one
of
his
Gio's
control
playing
components,
pilot
being
incorporated
into
docker
enterprise.
A
Well,
that
was
that
was
clearly
not
all
the
components
that
I
just
showed
and
so
so
they're,
clearly
I'm,
starting
it
small
iteratively
doing
things
piece
mail,
it's
the
right
start
to
me
so
I
was
here
last
year,
did
a
workshop
on
using
sto
and
then
I
went
around
and
gave
the
workshop
quite
a
few
times.
I
pretty
consistently
heard
two
questions
I'm
in
giving
that
workshop.
A
They
both
very
naturally
started
out
with
this.
This
service
mesh
thing
is
fantastic
like
this
is.
This
is
awesome,
that's
kind
of
how
the
other
question
started
was
like
yeah,
yes,
I
know,
and
then
they
said,
but
you
talked
about
a
few
different
ones
so,
and
so
we
had.
What
do
you
recommend
that
I
start
with
which
which
one?
What's
the
so
wink,
was
which
one
which
one's
the
one
and
then
so
I
said
I?
A
Think
the
microphone
went
out
there
side?
Well,
you
have
to
catch
me
after
not
all
right,
so
I
did
give
it
answer.
Moreover,
I
felt
like
the
answer
needed,
backed
up
a
bit
I.
Think
I
felt
like
people
needed
a
playground
to
go
in
and
try
these
surface
meshes
out
relatively
quickly.
The
second
question
that
they
asked
and
it
was
it
really
kind
of
true
of
I.
Think
any
any
engineer
in
the
room.
They'd
say:
well,
that's
fantastic,
but
wait
a
second!
This
doesn't
come
for
free.
A
A
How
much
what's
the
return
on
investment
here,
and
so,
unlike
the
days
of
the
container
Orchestrator
where
when
people
were
trying
to
figure
out
which
one
to
go
and
deploy
and
and
what
the
differences
were
in
those
environments,
people
would
measure
measure
characterize
them
in
different
ways.
One
of
those
ways
was
on
scale
and
sort
of
resiliency
high
availability
that
was
measured
most
prominently
by
a
container
orchestrators
scheduler
how
how
quickly
it
could
schedule
containers
across
how
many
nodes
it.
A
A
They
can
put
it
on
the
mesh
test,
their
the
performance
there
again,
and
so
because
naming
open
source
projects
is
hard.
We
arrived
here,
yes,
also
because
there's
so
many
corny
things
you
can
say
with
em
with
mesh,
and
so
this
is
a
very
simple
project:
who's,
the
here's.
What
it
looks
like
most
commonly.
We
expect
that
people
will
download
the
tool
onto
their
local
docker
environment,
in
my
case,
docker,
desktop
and
load
up.
A
A
Let's
see
if
we
can
give
a
demo,
and
so
the
tool
is
intended
to
ultimately
there's
a
number
of
people
working
on
this.
Ultimately,
the
tool
is
intended
to
help
provide.
Do
a
public
service
around
helping
understand
the
different
characteristics
of
service
meshes
and
not
necessarily.
Certainly
there
will
be
some
comparison
within
they're
really
doing
an
apples
to
apples,
comparisons
pretty
pretty
rough,
but
but
you
can
get
kind
of
close
and,
but
maybe
most
importantly
here
is
for
people
to
understand
for
the
given
mesh
that
they
are
deploying
what
what
are
they?
A
What
are
they
giving
up
in
terms
of
overhead,
and
so
let's
see
if
we
can
give
a
demo
and
then
show
some
results,
we've
got
it.
There's
a
couple
of
well
a
couple.
A
few
different
university
students
working
on
the
project,
I
was
going
to
say
a
couple.
Phds
and
they've
only
been
able
to
give
it.
So
much
time,
but
so,
but
we
do
have
some
results
and
we'll
share
some
of
those
results
today.
A
So
the
tool
itself,
you
can
be
found
at
that
same
site,
layer,
five,
dot,
io
/
measure
e
in
order
to
install
the
tool.
These
instructions
are
on
the
site,
but
it's
just
you
go
out
and
download
it's
massery
CTL,
once
you've
installed
that
you
can
do
a
mesh
restart
in
my
case,
I'd
already
downloaded
and
started
measuring,
so
we're
just
going
to
do
a
mystery
update.
A
A
When
you
go
to
the
tool
you
may
need
to
configure,
configure
your
environment
tell
to
point
the
tool
at
your
kubernetes
system.
In
my
case,
I'm
connected
over
VPN
back
to
home
office
I'm,
going
to
upload
my
local
kubernetes
config,
submit
that
it
looks
like
it's
interpreting
it
very
good.
I'm
gonna
go
and
point
the
tool
mystery
at
the
two
adapters
we've
got
deployed,
so
our
SEO
adapter
or
linker
D
adapter.
A
A
Let's
leave
something
for
you
to
go.
Try
on
your
own,
but
I'll.
Tell
you
why?
Okay!
So
hopefully,
we've
got
our
environment
configured.
Hopefully,
we've
got
connectivity.
You
can
use
the
tool
to
do
something
like
install
the
latest
version
of
Sto,
so
the
tool
is
off
running.
Maybe
to
help
with
some
of
this.
This
by
the
way,
is
a
very
simple
environment.
It's
just
a
single
node,
ubuntu
cluster
right,
it's
a
VM,
so
we
just
told
it
to
install
ISTE.
A
Oh
looks
like
it's
often
doing
that
we
can
tell
it
to
go
ahead
and
install
the
sample
application.
The
one
that
we
were
looking
at
before
book
info
we've
been
there's
a
vendor
in
the
space.
Some
of
you
may
know,
Aspen
mesh,
it's
been
also
started.
An
open-source
project
called
sto
vet,
anybody
familiar
with
docker,
docker
bench
or
cube
bench,
some
tools
that
defines
some
best
practices
and
let
you
run
and
we'll
run
against
your
your
containerized
environment
and
tell
you
mostly,
if
you're
doing
things
wrong
by
way
of
security.
A
Well,
if
you're
familiar
with
it,
sto
vet
is
fairly
similar.
It's
a
tool
that
you
can
run
that
will
it
will
execute
a
number
of
vetters.
These
vetters
are
just
best
practices
for
how
you've
got
your
in
this
case
sto,
environment
configured,
and
so,
let's
see
if
we
can
run
it
here.
So
it's
running
we're
seeing
we're
getting
back
some
messages
which
is
good
and
so
yeah.
Some
of
these
messages
are
the
sto
that
just
ran.
It's
telling
me
how
many
many
pods
I've
got
that
are
not
in
the
mesh
it'll.
A
Also
a
bit
more
interestingly,
tell
you
when
you've
got
something
wrong
and
give
you
a
little
bit
of
info
about.
Maybe
what
you
need
to
do
to
to
correct
it?
So
it's
good.
Let's
go
ahead
and
do,
and
so
that's
great
you
got
a
playground.
You
can
work
with
it.
You
know
an
interface
with
there,
the
mesh
you
can
send
it.
Some
yamo
update
its
config
there's.
You
know
I'll
leave
other
things
to
the
imagination.
You
can
run
some
performance
tests.
I
had
said
that
maybe
we
would
take
a
look
at
the
that
sample
app.
A
Point
measure
e
to
it
I
will
have
to
save
this
result.
This
will
be
a
good
one.
There
are
that
kind
of
saying,
they're
sort
of,
but
there's
a
list
of
service
Besh's,
some
of
which
are
supported
today
we
can
go
out
and
tell
it
to
tell
mr.
e
this
tool
running
on
my
macbook
to
generate
something
load
in
this
case
HTTP
load
over
to
this
endpoint
book
info.
Maybe
you
know
in
this
case
for
30
seconds,
because
I
can
only
think
of
one
really
good
joke
in
30
seconds.
While
we
wait.
A
And
so
right
now,
what
it's
doing
is
generating
load
based
on
the
parameters
that
I
gave
it
in
this
case,
really
just
using
a
single
thread.
So
it
concurrence.
You
know
a
single
concurrency
generation
of
HTTP
traffic
over
the
send
point:
do
it
for
30
seconds:
do
it
at
a
query
rate
of
once
per
second
and
and
so
it
pulls
back
results
and
it's
using
if
you're
familiar
with
Ford
I/o,
it's
using
for
IO
as
a
load
generator
inside
the
tool
using
chart.js
to
display
things
back.
A
It's
going
to
show
you
a
histogram
of
where
most
of
your
most
of
the
the
latency
of
the
responses
back
this
tool
is
going
to
show
you
latency
of
your
requests
and
throughput
of
your
requests
and
help
you
test
that
I
think
I
know
the
answer
to
this
question,
but
who
is
here?
Who
is
that
container
world
and
saw
me
do
for
the
first
time
ever
a
side-by-side
performance
test
and
so
they're?
Okay,
one?
What
yes
one
individual
I'd
knew
it!
A
Well
guess
what
you're
lucky
this
is
the
you
know
what
I'm
actually
not
going
to
do
it
again.
I
was
gonna,
say
this
is
the
second
time
ever
that
I
would
run
it,
but
let's
pull
that
one
up,
because
I've
demoed
enough
live
things
on
stage
the
tool
itself
will
one
of
the
nice
things,
and
so
there's
our
result.
That's
great.
A
It
will
persist
your
results,
so
you
can
come
back
later,
so
not
dissimilar
from
an
internet
I
mean
in
some
respects,
from
an
Internet
bandwidth,
speed
test
that
you
might
run
at
home
to
figure
out
if
you're
getting
gypped
by
your
service
provider.
What
the
tool
intends
to
do
is
collect
some
of
these
performance
tests
anonymously
and
again
do
a
kind
of
a
public
service
back
to
share
what
the
average
latency
is
for
different
service
specialist
deployed
you
know
around
the
globe
or
for
whoever
is
deploying
them
container
world
was
in
Santa
Clara.
A
Three
weeks
ago,
April
18th,
we
ran
what
a
test
it
was.
The
test
was
linker
D
sto,
both
running
book
info,
this
sample
app
and
also
the
sample
app
not
running
on
any
mesh
at
all,
just
running
on
a
kubernetes
by
itself
and
the
line
breakage
here
is
unfortunate.
Let
me
switch
the
line.
Breakage,
so
that
we
can
I,
guess
there's,
maybe
a
couple
of
things
to
shows
that
you
know
you
can
select
a
couple
of
results
and
compare
them
in
the
same
graph.
So
this
is
kind
of
nice.
A
A
We
did
again,
we
did
a
test
with.
Oh
man.
Is
it
breaking
across
the
same
okay,
alright,
so
the
test
was
the
test.
I
think
I
ran
it
at
a
concurrency
of
1
1
thread
for
30
seconds
for
one
query
per
second,
which
is
actually
what
I
just
did
just
now
and
in
that
particular
environment.
Again,
there's
lots
and
lots
of
variables
within
here,
but
of
the
two
things
that
this
tool
is
measuring.
A
Right
now
is
throughput
in
latency
and
really
you're,
saying
just
a
nominal
difference
between
these
two
meshes,
both
performing
rather
the
same
under
these
conditions.
There's
a
sort
of
fat
asterisk
behind
this,
because
performance
testing
is
just
a
bunch
of
variables.
It's
just
a
bunch
of
it
depends
on
what
you're
testing
when
and
what
nodes
it's
running
and
all
these
things.
This
tool
is
intended
to
facilitate
that.
A
But
but
we
I
said,
we
also
ran
a
test
that
was
of
book
info
at
the
time
that
was
not
on
the
mesh
and
while
it's
unfortunate
that
they're
not
side
by
side,
so
you
can't
see
it.
In
fact,
what
was
rather
surprising-
and
even
at
the
time
I
think
to
me,
but
not
to
our-
not
that
too
many
here
was
that
the
slower
responses
were
those
from
book
info
that
was
not
on
the
mesh.
A
The
slower
responses
were
coming
from
book
info
that
was
deployed
on
kubernetes
by
itself
onto
its
own,
not
on
not
on
the
mesh.
The
response
is
coming
back
from
the
mesh
where
you
were
getting
security,
visibility
and
control.
We're
in
fact
pasture
there's
a
probably
a
couple
of
different
reasons
for
this.
A
One
being
that,
right
now,
within
your
Ted,
your
vanilla
deployment
of
kubernetes
you'll
find
that
IP
tables
and
netfilter
as
a
kernel
capability
are
being
used
and
if
you've
heard
talks
about
EBP,
F
or
IP
vs
other
Linux
kernel
capabilities
you'll
have
understood
that
not
all
Linux
kernel
capabilities
are
made.
The
same
point
is
somewhat
surprising,
but
actually,
in
this
case
being
on,
the
mesh
was
faster.
A
We're
gonna
do
more
tests,
some
of
some
of
the
tests
have
come
back,
and
these
are
fresh
as
of
this
morning
very
seriously.
These
all
of
these
slides
are
these.
These
last
ones
are
fresh
has
as
of
this
morning
and
so
just
even
trying
to
grok
them
and
internalize
them
myself,
as
we
got
these
back
from
UT
Austin
from
the
excellent
students
that
are
that
are
working
there.
Was
this
notion
of
this
test
being
done
on
an
eight-core
system,
a
vm.
A
You
go
into
a
system,
a
single
node
deployment
had
it
has
eight
cores,
and,
and
so
the
insights
that
were
being
gleaned
here
was
just
to
take
and
and
again
there's
a
lot
of
kind
of
configuration
of
the
mat
you
can.
You
can
configure
meshes
in
different
ways
and,
and
we
were
using
just
HTTP
HTTP
bin
in
these
tests,
which
is
hitting
a
very
simple
service
and
having
it
respond
back.
What
we're
seeing
here
is
that
between
this
particular
configuration
of
this
do
and
and
linker
D,
the
differences
seem
to
be.
A
You
know,
marking
a
marginal
and
not
nominal,
but
the
takeaway
that
wasn't
so
much.
We
were
trying
to
test
what
we're
trying
to
test
is:
what's
the
relative
slow
down
when
I
just
ran
that
test
a
minute
ago,
I
did
it
at
a
current
see.
A
concurrency
of
one
so
saw
is
the
basically
single
threaded
load
generation
and,
for
you
know,
I'm
not
going
to
educate
folks
with
something
that
you
probably
don't
know,
but
if
you're
running
more
threads,
then
you
have
cores
those
cores
need
to
time
slice
between
those
threads.
A
A
Switching
in
this
case,
and
and
this
was
in
that
this
is
measured
in
times
so
the
cost
of
context,
switching
or
a
hundred
threads
at
the
QPS
that
we
were
giving
it
at
the
you
know
with
all
of
the
data
isn't
shown
here,
but
are
all
the
computing
environment
configuration
but
is
pretty
high?
You
know
about
nine
times
as
high
as
it
is.
If
you
were
just
running,
if,
if
your
service
was
just
receiving,
your
service
is
sitting
there
running
on
a
VM
or
a
host,
it
has
a
certain
number
of
cores.
A
If
it's
getting
more
connections
more,
then
it
has
cores
to
draw
on
there's
the
context.
Switching
that
happens
and
so
point
of
interest,
something
that
may
be
serviced
meshes.
Could
they
so
they
clearly
have
insight
into
they
clear
to
get
affected
by?
Maybe
they
could
do
something
about
it
so
turns
out.
We
didn't
have
a
showdown,
but
we
had
a
slowdown.
A
Highlights
the
the
under
a
different
configuration
for
is:
do
this
sto
one
configuration
is
it's
kind
of
the
default
profile
for
Sto,
it's
the
one
that
has
distributed
tracing
enabled
by
default.
It
has
the
sample
rate
of
that
tracing
set
to
a
hundred
percent,
and
that
is
I.
Think
true,
as
of
one
dot.
A
One
dot
three
but
may
have
changed
here
recently,
just
having
understood
that
there
is
cost
to
generating
spans,
generating
trace,
IDs
I'm
you're,
passing
along
the
spans
and
collecting
that
and
and
so
there's
a
cost
to
to
telemetry
and
of
the
telemetry-
that's
arguably
the
most
expensive,
at
least
between
metrics,
logs
and
traces.
In
this
case
this
is
probably
the
traces
and
so
to
get
that
white
box
visibility.
The
distributed
tracing
view,
which
is
which
is
fantastic,
yeah,
there's
there's
some
cost
to
it.
A
To
the
tip,
so
the
question
was
hey
to
clarify
of
the
threads
that
we're
talking
about.
Here.
Are
these
threads
the
number
of
threads
that
are
available
to
the
data
plant,
the
the
service
proxy,
the
service
mesh,
that's
receiving
traffic
and
processing
that
traffic,
or
are
these
threads
that
are
being
given
to
the
load
generator
that
I
was
just
running
and
in
its
to
the
load
generator
that
I
was
just
running,
and
so
so
in
this
case,
like
8,
8,
threads
spun
up
on
the
load
generator
and
then
in
that
particular
environment.
A
Nope
sorry,
the
the
mesh
had
8
cores
and
the
load
the
load
generator.
We
started
with
8
threads,
like
a
1
to
1,
to
kind
of
baseline,
okay,
well,
hey
with
no
time
slicing,
with
no
context.
Switching
for
that
CPU
sort
of
you.
What's
the
conceptual
optimizing,
your
maximal
output,
and
so
then,
from
there
we
said.
Well,
let's
double
that,
let's
double
that,
and
then
we
decided
that
that
it
was
taking
too
long
so
we're
running
it
for
5
minutes
apiece.
We
skipped
208,
so
so
understanding
that
I've
been
speaking
at
you
for
some
time.
A
There
are
other
things
I
think
to
talk
about
here.
There
is
probably
good
to
mix
it
up
with
with
some
others
and
spike
is
already
starting.
Thank
you.
Thank
you
for
clarifying
spike
that
helpful.
This
is
a
diagram
of
just
in
this
case
of
telemetry
processing.
So
I
said,
looks
like
there's
some
expense
and
some
cost
to
gathering
that
telemetry
and
make
sense
like
this
is
very
insightful
information
in
stos
world.
A
It's
mixer
as
the
component
that
deals
with
this
and
mixer
has
this
adapter
model
where
you
may
be
using
either
open
source
or
some
vendors,
software
to
capture
metrics
or
capture
spans
and
and
look
at
spans,
and
so
different
vendors
and
different
projects
have
built
adapters
that
go
into
there.
In
my
mind,
this
is
a
bit
more
of
the
management
plane.
Okay,
what
we
were
alluding
to
before
sort
of
the
the
other
software
that
you
would
be
using
to
control
things
to
hopefully
explain
this
quickly
and
well,
the
other
another.
A
There's,
there's
lots
and
lots
and
lots
of
tests
that
we're
gonna
be
running
and
publishing
a
reports
on
this
one
again,
just
just
diagram
that
this
this
morning
the
test
was
to
say:
hey.
Is
there
a
difference
for
the
way
that
certain
these
service
messages
perform
by
going
out
and
pulling
down
a
10
megabyte,
binary
image
or
10
kilobyte
or
a
10
byte,
and
what
we
found
was
and
again
in
all
the
details
need
to
be
published
subsequently,
because
it's
like
well,
what
was
the
environment?
What
was
the
app?
What
was
the
the
environment?
A
A
The
same
was
really
seemed
to
be
true
for
the
10
kilobyte
byte
size,
and
then
the
third
test
that
we'd
run
was
for
a
10
bite
is
just
a
super
small
request
out
to
HDTV
bin,
and
since
these
are
just
an
hour
or
a
couple
hours
old,
my
guess
is:
if
you
figure
this
out
and
you've
got
a
different
perspective.
I
had
said
that
I
was
gonna,
try
to
have
tough
skin
on
Twitter,
so
you
know
so
do
your
worst.
A
My
perspective
is
that
of
these
super
small
requests
that
are
being
made
it
they
come
back
lickety-split,
so
I
hadn't
got
to
use
lickety-split
in
oil.
They
come
back
pretty
darn
fast
I'll
save
for
maybe
that
initial
setup,
where
what
you're
getting
here
is
encryption
both
from
these
two
deployments,
where
a
steal
and
linker
D
are
both
providing
the
mutual
TLS.
Okay,
maybe
the
set
up
of
that
takes
a
second
longer
than
you
know,
then
what
we're
looking
at
here
we're
looking
at
these
are
in
seconds.
A
One
of
the
things
that
it
is
attempting
to
do
is
provide
something
of
a
service
mesh
benchmark
specification
so
that
you
can
really
begin
to
I'll
export
your
test
results
and
share
those
around
in
a
consistent
way
so
that
they
could
your
test
results
could
be
comparable
to
others,
and
so
so
we're
inviting
the
different
service
projects
to
participate
there.
I
do
want
to
pause
and
expect
everyone
to
take
a
picture
of
this,
so
that
you
can
tweet
out
these
lovely
contributors
of
their
free
time
and.
A
So
yeah
I
occasionally
feel
like
the
odd
one
out
here.
I
am
so
pale,
it's
just
a,
but
with
that
enough
for
me,
do
go.
Read
a
service
matchbook
I
encourage
you
to
let's
maybe
just
take
a
five.
You
know
five
minute
recess
grab
some
drinks
use
the
restroom
come
back
with
your
questions,
we're
going
to
bring
up
five
panelists
that
represent
some
of
the
service
projects
that
we've
talked
about
and
some
that
you
maybe
haven't
seen
yet.
So,
let's
do
five
welcome
back.
A
We
will,
let's
get
going.
Let's
get
some
other
voices
up
here
on
stage
what
a
crew
we
have
today,
I'm
honored,
to
introduce
this,
the
panelists
that
we
have
here
there's
a
decent
representation
of
of
the
various
service
measures
that
are
out
there.
There
are
more
meshes
than
there
are
seats
up
here.
Hopefully
we
do
as
much
justice
to
the
surface
pressures
in
general
as
we
can,
if
I,
if
I
can,
if
I,
if
I
could
ask
our
esteemed
panelists
to
maybe
just
self
introduce-
and
you
know
spike-
maybe
if
you
would
start
sure.
D
G
A
Good
good
to
have
you
guys
today
the
we've
been
talking
a
lot,
but
we've
been
introducing
a
lot
of
you
to
service
meshes,
which
means,
as
your
interest
unfolds
you'll
go
about
adopting
a
surface
mesh,
hopefully-
and
that's
kind
of
the
theme
to
our
panel
today
too,
about
adoption-
and
maybe
that's
even
the
first
question-
and
maybe
a
bit
of
chaos
up
here
is-
is
good.
I'm,
gonna,
I'm
gonna
throw
this
one
right
in
the
middle,
but
in
your
mind
we
talked
about
some
of
the
value
that
a
service
mesh
provides.
A
F
Well,
yeah,
that's
William!
All
right
see:
I
chose
the
seat
because
I
figured
I
would
not
be
asked
the
first
question.
Additionally,
we
start
on
the
sides,
but
ok
I'll
go
for
it
yeah,
so
I
think
we
have
a
little
bit
of
a
unique
perspective
in
that
linker
dee
was
the
very
first
service
mesh
and
and
coined
the
term
back
before
the
term
existed,
so
we've
been
kind
of
been
able
to
view
the
many
stages
of
evolution
of
the
service
mesh,
ranging
back
from
you
know,
circa
2016,
where
you.
C
F
C
F
And
now
everyone
knows
that
they
need
a
service
mesh,
but
they
don't
necessarily
know
what
it
is
or
why
but
I
know
they
need
one
so
that
perspective
yeah,
I,
guess
the
reasons
why
people
have
adopted
it.
You
know
I,
think,
there's
a
couple
reasons
and
I
think
you
touched
on
most
of
them
in
in
your
intro
slides.
There
are
some
very
engineer
facing
reasons
right.
F
There's
there's
reasons
like
I
just
need,
you
know
telemetry
and
like
I,
just
don't
have
a
good
way
of
doing
it
or
you
know
I
need
a
way
of
you
know
putting
kind
of
these
security
policies
in
place.
There
are
engineering
challenges
that
it
solves,
but
I
think
fundamentally
the
thing
that
it
provides
and
the
thing
that
makes
it
have
such
a
huge
impact
on
organizations
that
adopt
it
is
is
the
decoupling
right.
It's
a
decoupling
between
the
platform
owner.
F
You
know
team
which
comes
in
various
forms
and
the
and
the
developers-
and
you
know
it's
nice-
that
the
developers
don't
have
to
write
their
own
retry
logic
and
by
the
way,
like
that's
really
hard
to
do
and
okay,
we
can
extract
that
all
and
they
should
be
focusing
on
a
business
logic.
That's
great,
but
it
allows
the
platform
team
then
to
have
ownership
over
these
over
these
kind
of
fundamentally
platform
concerns
around
security
and
reliability
that
otherwise
are
in
the
hands
of
the
developers
and
I.
F
C
Will
say,
I
think
you're
so
spot-on
right
this.
It
is
exactly
the
centralization
of
control
and
consistency
that
these
this
mesh
architecture
provides.
It
is
the
the
key
winning
thing,
but
we
do
see
that
most
of
the
reason
that
people
start
to
adopt
the
mesh
is
the
engineering
centric
reasons,
because
you
don't
start
to
realize
that
organizational
change
until
you
actually
start
the
adoption
process
Lisa.
As
far
as
I've
seen
right.
A
E
I'll
adjust
the
the
second
part
of
your
question
why
people
are
kind
of
hesitant
and
I
think.
Essentially
it's
introducing
another
another
level
of
complexity.
So
you
have
another
thing
running
in
your
data
plane.
The
the
problem
is:
never
the
control
plane,
it's
always
having
the
proxy,
and
what
does
that
mean
in
terms
of
latency?
What
does
that
mean
in
terms
of
stability?
How
do
I
monitor
another
component
that
I
didn't
write?
It
was
really
not
in
my
my
control
and
I
have
no
control
over
the
roadmap
of
that
specific
feature
or
that
specific
component.
E
The
second
part,
I,
think,
is,
as
your
platform
becomes
more
powerful
and
you
have
more
features
and
eesti.
Oh
definitely
has
more
features
compared
to
kubernetes.
You
start
seeing
a
lot
more
friction
with
the
way
you're
used
to
doing
things
outside
if
you're
doing
authentication
in
a
certain
way.
You
manage
your
certificates
in
a
certain
way.
You
have
a
way
to
do
routing
that
works
and
it
worked
outside
of
your
cluster
and
it
worked
inside
of
your
cluster
and
it
worked
everywhere
now.
E
F
A
counter
question,
a
reverse
ask
which
is:
is
any
of
our
so
I
agree
with
all
those
with
all
those.
All
those
reasons
are
any
of
them
specific
to
the
service
mesh,
as
opposed
to
general
reasons
to
adopting
any
new
piece
of
technology
I'll,
throw
that
right
in
the
middle
I'll,
throw
that
on
the
sides,
I
mean.
D
I
think
that
there
there's
a
there
is
you
know
that
this
kind
of
resistance
to
change
then,
and-
and
even
you
know
us
people
that
work
in
tech
and
think
that
we're
really
you
know,
innovators
and
and
embraces-
have
changed.
We
can
still
get
into
those
those
those
sort
of
ruts
but
service
meshes.
You
know
we
talked
about
these
organizational
changes
and
we
talked
about
how
this
is
now
a
platform
thing.
D
You
know
and
overhead
that
you
have
to
kind
of
understand
when
you're,
when
you're
biting
off
off
service
mesh
and
and
it's
the
kind
of
thing
that
pays
when
you
make
these
big
platform
investments,
that's
the
kind
of
thing
that
pays
dividends
across
a
large
group
of
services,
a
large
group
of
developers,
a
large
organization
when
you
have
small
nimble
teams,
you're,
not
paying
like
the
the
amount
of
value
that
you're
gonna
get
out
of,
deploying
something
like
a
service
mesh
may
not
may
not
be
the
same.
Yeah.
G
I
agree:
I
agree
with
all
of
you
guys,
I
got.
There
are
three
type
of
organizations
out
there
right
guys:
who've,
actually
containerized
their
services,
the
monoliths
into
big
containers,
guys
who
I've
actually
truly
done
micro
services,
architecture
right.
Oh
there's,
a
lot
of
guys
who
fit
in
the
first
one.
They
have
contained
rises
offices,
which
is
great,
which
is
because
now
it's
a
developer
agility
it
can.
G
They
can
deploy
faster
and
whatnot
right,
so
they've
crossed
that
impediment
right,
but
they
haven't
really
truly
gone
to
the
to
the
place
where
they
have
Microsoft
sized
all
services
right,
oh
so
this
mesh
is
good
for
the
second
case.
For
this
there
are
a
lot
of
micro
service
based
applications
running
in
there,
communicating
with
each
other,
and
you
want
something
like
service
mission.
We
all
know
what
capabilities
and
benefit
it
gives
us
right.
G
G
So
when
you
have
that
kind
of
scenario
of
the
source
mesh
hold
good
for
you
right,
there's
there's
again
a
thin
line
around
with
the
service
message,
just
true
for
east-west,
or
is
it
good
for
not
south,
also
where
the
ingress
gave
me
is
coming
into
picture?
But
those
are
the
kind
of
things
which
people
look
at
right,
that
you
know
what
my
traffic
is
mostly
not
south.
G
H
C
G
And
that
was
the
point.
The
point
I
was
trying
to
make
was
the
way
you
need
to
deal
with
not
saw
traffic,
as
of
today
is
a
little
different
than
the
way
you
deal
with
east-west
traffic
right
and
in
terms
of
just
the
scale
and
security
requirements
that
you
have
for
not
sauce
right
and
even
the
performance
requirement
that
you
have
not
south.
It's
a
little
different
like
like
TCP
or
TLS.
For
that
matter.
Right
and
those
kind
of
stuff
right
is
very
not
sought,
relate
or
DDoS
in.
D
G
A
Is
they
just
been
here
longer,
so
I've
had
longer
to
digest
them.
I
understand
that
they're
somewhat
different,
some
some
of
them
have
more
constructs.
Some
of
them
have
less.
Some
of
them
are
easier
to
deploy.
Some
of
them
are
more
difficult
to
deploy,
some
require
more
maintenance,
other
you
know,
and
I
would
postulate
that
that's
there
are
some
similarities
to
be
drawn
to
some
of
the
offerings
that
we
have
today
some
of
the
projects
that
are
available
today.
A
So
in
context
of
that,
my
question
is:
do
you
can
you
know,
do
you
consider
or
what?
What
sort
of
key
indicators
do
you
consider
or
points
of
inflection
or
key
indicators
as
to
that's
when
you
know,
or
here's
when
you're
really
going
to
benefit
or
that?
That's
when
you
know
you
should
you
should
do
this?
Maybe
it's
hey
things
are
too
complex,
and
so
you
won't
get
the
return
on
investment
or
hey.
You've
got
too
much
of
your
traffic
elsewhere
or
you
know.
Whatever
those
things
are
you.
F
Know
I
like
the
framing
in
terms
of
ROI,
because
it
makes
clear
that
there
is
both
a
there's,
a
return,
but
there's
also
an
investment
and
whenever
you're
making
an
ROI
decision,
you
have
to
look
at
at
both
of
those,
and
you
know,
I
I
think
the
the
return.
Certainly
the
experience
that
we
had
with
with
linger
D.
So
I
mentioned
that
linker
D
has
been
around
for
a
couple
years.
F
We
have
gone
through
a
very
substantial
transformation
from
one
dot
X
branch
to
the
2x
branch
in
part,
on
a
lot
of
based
on
a
lot
of
lessons
learned
during
one
dot
X,
which
was
very
widely
adopted
and
continues
to
power
massive
portions
of
the
internet
today.
But
you
know
the
value.
What
we
learned
with
one
dot
X
is
that
the
value
props
were
there
right.
People
were
getting
value
out
of
the
security
and
observability
and
and
reliability,
but
the
cost
that
they
were
paying
to
get
there
was
was
high.
F
So
you
get
the
value
propositions
right,
you
get
the
the
R,
but
the
AI
is
significantly
lower,
and
so,
when
I,
you
know
to
pick
on
sto
a
bit
when
I
hear
people
mention.
You
know
the
complexity
of
the
service
message.
Service
mission
is
complex
in
my
mind.
I'm
always
asking.
Are
you
talking
about
the
service
measure?
Are
you
talking
about
sto,
because
those
are
two
very,
very
different
things
and
I?
F
Think
sto
is
particularly
complex
and
I
think
it
does
a
and
you
know
maybe
you'll
flame
you
on
Twitter
I,
think
it
does
a
huge
disservice
to
users
by
its
complexity,
and
it's
not
complexity.
Yet
like
install
time
or
like
oh
I,
got
a
you
know
whatever:
it
is
a
long
term,
complexity
and
I
think
that's
a
real
problem
and
I,
don't
think
that's
endemic
to
this
service
message
itself.
I
think
a
lot
of
that
is
a
function
of
this.
F
Do
an
issue
is
what
is
in
people's
heads
and
therefore
you're
kind
of
ascribing
these
qualities
to
the
service
mission
as
a
whole
and
I
understand
why
that
happened
right.
We
did
the
same
thing
with
linker
d1
right.
We
we
went
through
that
journey
as
engineers
and
we
were
like
we
got
all
these
features.
F
We're
gonna
add
all
these
things
I'm
like,
let's
to
have
it
do
this
and
this
and
this
and
like
why
not
like
more
features
it
better
and
no
one
was
kind
of
having
any
real
empathy
towards
the
end
user
and
it
it's
a
long
time
to
learn
that
lesson,
and
so
that
has
all
been
kind
of
worked
back
into
into
two
decks,
but
ultimately
I.
Think
for
me
the
you
know.
Just
to
summarize
my
answer
to
your
question:
it
is
the
the
level
of
in
the
the
the
return.
F
C
I
I
think
William
is
spot-on
and
basically
everything
that
he
said
he
owes
what
happens
when
you
go
spend.
You
know
a
bunch
of
engineering
effort
for
a
year
year
and
a
half
and
and
don't
really
interact
very
closely
with
users.
Is
you
have
a
lot
of
really
cool
features?
They
can
do
a
lot
of
powerful
things.
C
It's
a
it's
a
Swiss
Army
knife
with
a
lot
of
feature
things
in
it
and
it's
really
really
easy
to
cut
yourself
all
over
trying
to
handle
it
right,
and
some
of
it
I
would
argue,
is
inherent
to
the
problems
that
are
being
solved
and
a
lot
of
it
is
incidental
complexity,
introduced
by
SEO
the
system
itself.
I
Williams
point
that
inherent
complexity
in
the
in
the
mesh
I.
F
So
I
appreciate
that
I
think
you
know
just
to
kind
of
pile
on
more
like.
Why
do
you
think-
and
you
can
crow
me
on
this
I
think
SEO
is
a
bad
project
and
it's
bad,
because
it
does
a
disservice
to
it
to
to
its
end
users,
and
it's
not
bad,
because
Zack
is
a
bad
engineer.
I
think
Zack
is
probably
a
better
engineer
than
I
will
ever
be
able
to
become,
but
I
think
there's
a
fundamental
disconnect
between
what
the
human
being
who
has
to
operate
this
thing
over
the
next.
F
You
know
the
core,
the
core
of
you
know
the
next
couple
years:
who's
building
their
career.
On
top
of
this
thing
whose
job
is
on
the
line
because
they
have
to
make
the
service
mesh
work,
I
think
there's
a
fundamental
disconnect
there,
and
if
that
loop
is
not
cutting,
we
can.
We
can
think
about.
Why
there's
a
disconnect,
you
know,
there's
like
I,
think
part
of
it
is
like
it.
It's
a
consequence
of
like
massive
amounts
of
marketing.
F
Like
it
just
kind
of
puts,
a
damper
puts
a
wet
blanket
on
any
kind
of
realistic
conversation
you
can
have
and
then
there's
parallels
to
OpenStack
and
we
can
get
it
all
that
stuff,
but
I
think
if
you
cannot
have
that
fundamental
loop
between
the
human
being
who
has
to
operate
this
thing
and
the
project
then,
like
you,
you're
doing
a
disservice
to
your
users
and
it's
not
the
right
thing
to
do.
Sorry.
G
Right,
both
of
them
are
right
right.
You
know
when
we
talk
a
doctor
customers
and
we
asked
them-
hey
guys,
you
using
kubernetes
your
Microsoft
this
but
based
architecture.
So
now
you
want
to
service
mesh
right,
yeah,
we're
trying
it,
but
damn
it's
complex
and
and
and
he's
right
most
of
times
we're
talking
with
you
right,
because
that's
what
they
they
end
up,
trying
that's
that's
most
popular
one
right
way
so
far,
right
and
say
it's
complex
and
we
didn't
sign
up
for
this.
G
G
C
r,
DS
right
and
all
that
stuff
right,
you're,
so
right,
I'm,
sorry,
just
matter
right,
there's
so
many
CR
DS
I
need
to
worry
about
now.
So
it's
both
both
of
your
spot-on
and
that's
that's
I!
Guess
all
of
us
need
to
really
think
about
how
to
make
the
whole
thing
simple
right.
So
this
mesh
is
there
to
solve
the
challenges
that
we
have
been
talking
about
right
and
it
does
it
wonderfully
it's
just
that
it
has
to
do
it
very
simply.
That's
all
it
is.
E
That
said,
I
think
it's
it's
very
important
that
if
don't
wait
for
an
inflection
point,
if
you
want
the
features
of
the
service
mesh
tri-service
mesh,
now,
don't
there's
no
reason
to
wait
until
you
have
an
X
number
of
services,
a
certain
size
of
deployment.
It's
only
going
to
get
worse,
so
you
want
to
start
as
small
as
possible,
which
is
probably
as
early
as
possible
and
and
grow
with
it.
So
so
choose
your
your
project,
evaluate
the
options
and
figure
out
what
works
for
you
and
then
go
with
it.
Yeah.
F
H
A
D
D
D
You
know
I
definitely
agree
with
with
William
about
thinking
about
ROI
and
and
what
are
the
returns?
What
are
the
investment
I'm
gonna
take
a
slightly
orthogonal
way
to
talk
about
it,
so
not
not
disagreeing
with
William,
but
but
another
way
to
think
about.
This
is
kind
of
what
are
you?
What
are
you
trying
to
solve
as
as
an
organization?
What
what
are?
What
are
the
problems
that
are
that
are
that
you're
dealing
with
and
what
are
the
urgency
of
the
different
problems?
D
So
so
you
can
be
reactionary
or
or
depending
on
on
what
kind
of
business
you're
in
and
what
sort
of
what
sort
of
mandate
your
group
has,
like,
maybe
you're
the
platform
team
and
your
job
is
not
to
be
reactionary.
Your
job
is
to
be
skating
where
the
puck
is,
if
you're
in,
if
that's
your
team,
if
that's
what
you
are
doing,
then,
then
by
all
means
right
get
on
this
like
this
is
this
is
a
thing.
That's
that's
rapidly.
Dropping
the
the
I
in
in
service
messages
is
rapidly
dropping.
C
The
vast
majority
people
that
have
successfully
been
able
to
adopt
a
mesh
had
one
thing
that
hurt
in
they
in
the
mesh
addressed
that
thing
that
hurt
and
they
used
it
to
solve
that
one
thing
and
then
later
they
expanded
that
to
solve
more
problems
because
they
had
the
infrastructure
in
place
because
they
had
the
understanding
in
place.
They
had
made
the
investment,
and
now
they
could
start
to
realize
returns
in
other
areas
that
they
didn't
intend
originally
right,
but
it.
But
you
have
to
be
a
use
case
focused.
C
A
Very
good
I
love
these
kinds
of
panels,
because
I
have
to
ask
two
questions
and
we
get
35
minutes
out
of
very
good
and
I
suspect
to
each
of
you
about
in
your
tongues.
At
that.
Let
me
because
again
because
it's
about
adopting
the
Meade
attempt,
this
question
to
put
things,
may
be
you're
slightly
more
concretely
and
choose
one
all
choose
aim
a
metric,
and
this
is
in
part
because
I've
heard
this
I
heard
my
teams
say
this
to
me
as
well
and
so
I'll
take
it
to
the
to
the
extreme
and.
C
H
C
Probably
honestly,
probably
not,
if
you
have
one
it's
not
that
hard
to
go.
For
example,
add
the
instrumentation
that
you
need
to
go
pull
in
a
library
that
appropriately
addresses
the
pain
that
you
have
there
downsides
to
those
approaches
as
well
right
there,
library
upgrade
problems
are
hard,
although
all
these
things,
those
are
greatly
mitigated
by
having
one.
G
Depends
on
the
use
cases
right,
even
if
there
are
minimal
number
of
services,
I
would
still
say.
No.
If
there
are
let's
say
even
ten
services,
I
might
still
say
no
depending
on
what
you
want,
and
what
do
you
use
cases
right,
so
it's
completely
dependent
on
what
your
need
is.
What
your
pain
points
are
right:
I've
customers
who
are
using
service
mesh
just
for
observability.
They
don't
really
care
about
any
other
features
of
service
mesh
I
have
customers
are
using
service
mesh
just
for
security,
that's
because
their
sake,
Ops
is
kind
of
behind
them.
G
They
want
it
to
be
multi-tenant.
They
want
policies
to
be
enforced,
the
way
they
should
be
enforced
across
ten,
and
so
our
namespaces
right
they're
using
it
for
just
that,
and
nothing
else
right.
So
it's
completely
dependent
on
your
your
use
case.
I
have
customers
who
keep
coming
come
to
me
say
your
tents
are
surrounding.
Should
we
do
service
mesh
I?
Well,
what
are
your
pinpoints
with
running
these
ten
solstice?
G
E
C
So
just
one
word
one
final
piece
here:
to
go
back
to
exactly
what
William
said
and
and
to
echo
what
you
said,
which
is
exactly
correct.
Look
at
the
calculation
right,
even
if
you
only
have
one
service
how
much
time
and
effort
are
you
going
to
invest
in
instrumentation
in
login?
Whatever
the
pain
point
is,
it
needs
to
be
use
case
driven.
So
how
much
are
you
gonna,
invest
in
so
like
number
of
services
is
an
irrelevant
metric
for
measured
option.
The
relevant
metric
is
what
is
the
thing
that
hurts?
C
What
is
the
investment
to
fix
the
thing
that
hurts
and
is
that
less
than
the
investment
in
fixing
it
now
with
a
different
tool,
and
does
that
pay?
Does
that
tool
make
sense
moving
forward
right?
That's
the
calculus
that
you
really
need
to
do.
Number
of
services
is
irrelevant.
It's
it's
about
developer
effort
and
energy
is.
A
While
we
toss
another
one
into
the
hopper,
please
do
I
know
that
many
of
you
have
got
questions.
If
you
do,
please
walk
up
and
we're
gonna
I
will
hand
walk
up
and
I
will
hand
you
the
mic,
and
so
don't
all
get
up
at
once.
Please
just
a
couple:
you
sit
back
down,
but
if
you
would,
but
you
know,
politely
and
calmly,
walk
this
way.
A
A
F
F
On
top
of
these
components,
and
those
are
at
least
from
the
linker
D
perspective,
it
is
those
people
who
are
often
not
writing
the
code,
although
in
small
companies
you
know
everyone
kind
of
shares,
a
lot
of
responsibilities,
but
in
larger
companies
are
not
writing
the
business
logic
directly,
but
they
are
building
the
platform
that'll
the
developers
to
do
that
in
a
way
that
you
know
doesn't
even
where
they
don't
have
to
worry
about
kind
of
the
the
executional.
You
know
complexities,
but
then
there
is
a
second.
F
There
is
a
second
audience
which
is
kind
of
indirect,
which
is
the
developers
and
themselves
and
because
they
are
ultimately
the
customers
of
this
platform.
So
to
the
extent
that
you
can
provide
features
that
make
the
lives
of
developers
easier
or
you
know,
then
that's
that's
beneficial
for
everyone.
F
It's
beneficial
for
the
platform
owners
who
are
gonna,
be
on
the
hook
for
providing
a
platform
that
the
developers
are
enjoying
right
if
they
they
build
this
thing
and
and
everyone's
bitching
about
it,
the
entire
time
and
well,
you
know
you
did
a
bad
job,
so
you
want
to
build
something.
That's
really
reliable
and
that's
you
know,
solves
people's
problems
and
that
that
has
things
and
that
make
the
lives
of
developers
easy
as
well.
So
in
my
mind,
that's
kind
of
the
secondary
audience
there
and
then
the
third
audience
is
I.
D
Or
you
agree
with
William
that,
like
you
know
the
people
that
we
at
tiger
and
normally
interface
with
as
our
our
direct
customers,
you
know
our
platform
teams,
security
teams.
Those
are
the
people
that
that
usually
have
the
the
very
direct
goals
that
service
meshes
are
going
to
going
to
help
them
achieve,
and
then
you
get
that
sort
of
benefit
out
to
the
developers,
and
you
know,
hopefully
this
the
like
the
who
benefits
should
should
extend
out
to
to
the
stakeholders
or
customers
of
your
organization.
D
Right,
like
you,
don't
want
to
just
sort
of
end
with
happy
developers
right
you
want.
You
want
to.
You,
know
delight
your
customers
or
or
or
do
some
good
for
for
society
or
you
know.
Whatever
is
your
organization's?
Bigger
goals?
Are
you
know?
Service
mesh
like
everything
should
should
be
supporting
that,
but
but
the
the
sort
of
place
that
we
interface
I
think
mostly
is,
is
yet
platform
sec.
C
Yeah,
it's
predominantly
either
like
a
central
traffic
or
platform
team
that
drives
it
and
then
what
you'll
see
over
time
is
security
gets
pulled
in
because
it's
now
we
have
this
thing
and
we
can
start
to
do
cool
security,
things
encryption
in
transit
policy,
it's
a
very
natural,
fit
right
and
then
typically
you'll
have
an
observability
team.
Either
essentials
or
building
team
either
start
to
be
established
or
existing
ones
come
out
of
the
woodwork.
A
H
All
of
your
clients
now
need
to
like
implement
like
exponential
back-off.
So
it
ends
up
being
something
the
ad
that
suddenly
makes
things
harder
for
the
client
and
was
just
trying
to
understand
what
certain
current
service
mesh
products
is
that
something
that,
like
them,
the
the
sidecar
proxy
would
kind
of
just
handle
on
the
client
side,
as
well
as
the
yeah.
C
That's
one
of
the
big
reasons
for
this
client-side
proxy
is
because
you
have
the
ability
to
do
things
like
some
of
these
resiliency
features
where
other
resiliency
features
that
you
enable
don't
interact
nicely
with
clients
right
so
I
Institute
default
deadlines
or
I
Institute.
You
know
whatever
it
is.
C
It's
not
actually
that
hard
to
break
clients
with
some
of
that
behavior
yeah
for
29s
is
a
great
way
to
do
it
right.
Resource
coated
limits
is
a
great
way
to
break
clients
being
able
to
also
put
in
place.
Things
like
automatic
retries
with
appropriate
back-off
is
a
powerful
way
to
deal
with
those
problems
and
mesh
because
of
the
architecture,
because
you
have
a
proxy
there.
That's
handling
the
requests
you
can
on
the
client
side
start
to
affect
those
changes
right
and
even
for
clients
that
are
outside
of
your
mess.
F
F
You
start
out
by
doing
retry
you're
like
oh,
my
web
browser
do,
you
know,
makes
three
calls
and
then
it
gives
up
and
I'm
gonna
do
the
same
thing
and,
like
turns
out,
that's
a
terrible
idea:
it's
in
a
in
a
big
distributed
system,
so
that
logic
is
hard
to
get
right.
It's
a
totally
independent
of
business.
F
It's
unrelated
to
business
logic,
right
business
logic
is
like
I'm,
a
foo
and
I
want
to
talk
to
bar
so
I
like
talk
right
and
it's
no
retries,
it's
not
in
there
and
it
works
best
when
it
is
done
platform
wide.
So
those
are
three
characteristics
of
a
feature
that
that
make
it
seem
like
it
should
be
part
of
the
platform
part
of
the
part
of
the
application,
and
so
that's
a
really
good
demonstration,
I.
F
Think
of
the
sorts
of
things
that
the
service
message
is
directly
valuable
for,
and
you
know,
there's
interesting
questions
there
when
you're
talking
about
things
like
retry
policy,
okay,
well,
who
owns
and
I,
think
Li
kind
of
touched
on
this
early
on
who
owns
that
policy
right?
Is
that
the
ops
team?
Is
it
the
service
owner
team?
Is
there
a
service
owner
team?
Is
it
developers
as
it
exits,
and
why,
like
someone
has
to
someone,
has
to
say
okay,
this
is
how
you
communicate
with
the
service
right.
F
That
ownership
has
to
be
clear
and
another
kind
of
I
think
ancillary
benefit
of
the
service
meshes.
It
gives
you
the
opportunity
to
make
that
ownership
clear,
because
unless
it's
codified
somewhere
right,
it's
just
like
it's
in
some
developers,
code
somewhere
and
then
you
know
they
left,
and
you
know
now
they
work
at
a
different
company
and
then
three
people
have
you
know,
come
and
maintain
this
thing
like
it's.
F
You
know
this,
this
critical
logic
which
is
like
what
is
going
to
determine
what
happens
to
this
service
when
load
gets
high,
is
like
not
written
down
anywhere.
It's
like
this
implicit
part
of
the
system,
and
that
is
a
recipe
for
a
bad
time,
so
the
service
mesh
gives
you
value
simply
by
giving
you
a
place
where
you
can
express
this
thing
and
say:
okay
here
it
is
and
here's
someone
someone
has
to
own
this
and
you
can
pick
who
it
is
right,
but
you
have
to
write
it
down.
It
has
to
be
there.
I
F
I
G
Yeah,
that's
that's
a
very
valid
question.
I
guess
we
all!
We
all
do
agree
to
the
fact.
There
is
a
lot
of
fragmentation
happening
in
that
space.
You
gotta
sto
as
a
control,
plane
your
leg
guardian
and
you
got
big
clouds
having
your
own
control
place
now
right.
The
good
thing,
though,
is
they're.
All
most
of
them
are
using
some
kind
of
the
same
data
plane
right
in
some
sense
right
and
the
same
protocol,
not.
F
G
G
But
yeah
there
is
something
people
are
thinking
about
it,
so
there
is
a
seed
that
has
been
sown
right.
People
are
think
about
it.
People
are
worried
about
it
and
and
you're
right
and
if
that
doesn't
happen,
I'm
gonna
get
logged
in
I
can
get
logged
into
Lincoln.
Ii
I
don't
want
to
get
along
anything
dirty
right.
So
that
has
to
happen
and
suspected.
You.
A
D
D
You
know,
Manish
just
just
talked
about
like
well,
there's
fragmentation
and
actually
I,
wouldn't
quite
use
that
that
word,
because
it
was,
it
wasn't
a
thing
that
was
like
one
thing
and
then
like
broke
into
pieces
right,
like
we've
got
these
different
projects
that
are
they're
all
growing
up
and
we're
all
making
different
choices
about
features
and
and
stuff
like
that,
and
and
so
eventually,
as
as
an
as
a
sort
of
industry
as
a
kind
of
product
segment
or
whatever
you
can
start
to
figure
out.
What
are
what
are
the
common
commonalities?
D
C
That
API
would
be
awful
because
we
don't
have
enough
experience
in
what,
like
services,
all
very
young,
a
very
nebulous
thing,
right,
I
would
one
thing
I
will
say
is
I.
Would
caution
against
lowest
comp,
nominator
api's
right?
Those
are
almost
universally
awful
for
users,
and
so
a
rush
to
standardize
too
early
is
likely
to
introduce
that
right.
C
The
primitives
that
system
exposes
are
probably
the
most
important
part
of
the
system.
Right
is
it's
it's
how
you
interact
with
it.
Those
are
hard
to
get
right.
We
have
conceptual
differences
between
the
things
that
a
mesh
exposes
between
different
meshes,
we're
still
trying
as
an
industry,
to
figure
out.
How
does
this
stuff
fit
together
right
and
it's
not
until
we
go
through
that
exercise.
This
is
exactly
what
spike
was
getting
at.
It
takes
time
right.
Standardization
takes
time,
we
have
to
have
mini
implementations.
First,
we
had
to
figure
out
what
works.
C
A
That
was
a
fantastic
question
and
I'm,
but
a
where
we
are
at
our
time
be
there's
a
cliffhanger
to
be
left
here.
There
are
efforts
in
the
works
to
that
very
question
by
more
than
one
set
of
folks
so
TBD.
How
do
you
go?
How
do
you
like
that?
We'll
see
we'll
see
you
back
at
docker
con?
That's
what
I
do
want
to
very
much.
Thank
our
panelists
today,
very
appreciative
of
the
answers
and
the
sharing
that
you've
given
of
your
time
and
and
of
your
sarcasm.