►
From YouTube: Panel Discussion: Ask Us Anything: Microservices and Service Mesh – Moderated by Jason McGee
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Panel Discussion: Ask Us Anything: Microservices and Service Mesh – Moderated by Jason McGee, IBM
Have you heard the buzz around microservices and containers lately? With containers becoming the new standard to building microservice based applications for production, users are leveraging the service mesh to solve common issues with routing, re-routing for graceful degradation as services fail, secure inter-service communication and rate limiting between services. Join us for a live interactive session where our panel of experts from IBM, Google, Lyft, VMware, Linkerd, and RedHat will address your most challenging inquiries around microservice and service mesh!
To learn more: https://sched.co/Graa
A
All
right
guys
we're
gonna
get
started
here,
it's
a
big
room
so
and
it's
a
panel
like
meaning
it's
QA
and
you
guys
asking
questions
so
I
might
encourage
you
if
you're
in
the
way
back
to
just
try
to
fill
in
towards
the
front,
it'll,
be
easier
to
hear
you
or
get
to
you
with
a
microphone
so
I'm
Jason,
McGee
I'm,
run
Cobb
platform
for
IBM
cloud.
This
session
is
a
panel
discussion
around
surface
mesh
and
micro
services
and
the
projects
associated
with
it.
A
C
D
E
A
So
let
me
just
pull
the
audience
how
many
of
you
are
kind
of
novices
to
the
concept
of
service
mesh
awesome
everybody,
so
maybe
we'll
start
somewhere
really
simple
and
what
I'll
do
is
I'll
just
try
to
get
us
started
and
then
be
thinking
of
questions
because
we'll
be
out
in
five
minutes.
So
why
don't
we
start
with
what
problem
is
service
mess
trying
to
solve?
You
know
what
is
the
core
use
case
behind
service
mesh?
Anyone.
D
Open-Source
project
or
your
money
back
right,
no
so
I
would
say
a
service
mesh
is
a
layer
of
infrastructure.
That's
designed
to
give
you
kind
of
a
global
layer
of
visibility,
reliability
and
security
across
your
entire
application,
or
across
your
entire
cluster,
without
involving
a
whole
and
ideally
without
involving
any
changes
to
the
application.
All
right,
yeah.
B
So
I
think
that
that's
something
that
we
would
all
generally
echo
all
right.
We
it's
a
networking
of
abstraction,
a
higher-level
networking
layer
that
works
with.
You
know
your
orchestration
systems,
you
know
it's,
you
can
observe
services
there.
Endpoints
can
help
operators
control
the
flow
of
traffic.
Kpis
microservices
calls
between
those
services
and
it
operates
at
that
layer
and
provides
abstractions
to
do
things
around
telemetry
security
policy
management,
etc.
So,.
A
C
Sponsored
users
that
were
working
with
so
one
place
that
they
want
to
start
is
the
visibility
because
they
actually
have
no
idea,
what's
the
latency
between
their
micro
services
and
who
communicates
with
who
so
visibility.
In
order
to
gain
some
insight
about.
What's
going
on
and
do
some
troubleshooting
is
one
place
where
we
see
that
people
want
to
start
agreed.
E
Yeah
I
mean
we
see
we
see
kind
of
which
vertical
you
pick
the
lines
fairly
well
with
kind
of
what
your
company
prioritizes
always
so
you
go
talk
to
financial
people
and
typically
they're
gonna
pick
security.
First
right,
you
go
talk
to
most
of
the
world,
trying
to
do
micro
services
and
it's
buzzer
buildi,
because
nobody
knows
what
the
heck
is
going
on
in
the
cluster
and
traffic
management
tends
to
be
a
kids
to
follow
a
little
bit
in
in
our
experience
right.
E
A
So
on
the
panel
we
have
kind
of
two
major
surface
master
projects
represented.
Maybe
we
could
just
take
a
minute
and
and
maybe
you
could
start
William
and
just
give
a
quick
kind
of
state
of
link
or
D,
and
we
can
do
the
same
thing
with
this.
Do
it
just
give
people
a
sense
for
where
those
projects
are
at
I'm.
D
Outnumbered
you
are
it's
true,
so
state
of
link
or
D,
let's
see
so
it
it's.
It's
been
around
for
a
couple
years.
Actually
I
think
we
were
the
fifth
or
yeah
the
5th
C
NT
f
project
accepted
to
the
CNC
F
right
now,
there's
kind
of
two
versions
that
which
are
quite
different
that
are
both
kind
of
currently
in
in
production.
D
At
various
points,
there's
a
one
dot,
X
stack,
which
is
built
primarily
on
on
the
Twitter
stack,
so
things
like
finagle
and
Nettie
and
Scala,
and
the
JVM
very
widely
deployed,
often
in
kind
of
the
enterprise
world,
who's
very
familiar
with
the
JVM.
And
then
we
have
the
2x
versions,
which
have
been
mostly
what
we've
been
demoing
and
showing
off
at
at
coop
con,
which
is
a
rewrite.
You
know
with
a
custom
proxy
written
in
rust,
which
is
very
fast
and
very
small
in
a
control
plane,
that's
written
in
go
and
it's
a
you
know.
D
D
A
A
B
B
The
next
release
that's
coming
up
in
1.1,
which
hopefully
will
be
in
January
time
frame
slightly
later
than
we
hoped.
But
you
know
this
is
software.
It
happens.
You
know
we're
doing
some
architectural
things
to
make
it
easier
to
scale
up.
This
do
to
make
it
easier
to
use
in
multi
cluster
environments
to
make
it
easier
to
configure
and
in
particular
to
make
it
applicable
in
environments
or
easier
to
use
in
environments
other
than
kubernetes.
B
A
Alright,
one
more
for
me,
that's
your
turn,
so
both
projects
that
we
just
talked
about
while
service
mesh
is
new
and
obviously
for
you
and
the
audience.
Many
people
are
just
learning
about
service
mesh.
The
projects
themselves
are
actually
multiple
years
of
work
already.
Are
there
inhibitors
that
we
think
exists
that
you
know
are
preventing
people
from
getting
started
with
service
mesh?
Or
is
it
just?
You
know
new
concept,
maturity,
learning,
curve
problem.
A
D
So
I
think
I
have
some
some
of
the
hindsight
having
been
you
know
in
the
in
the
surface
mesh
world
for
a
couple
years
early
on.
It
was
very
much
a
here's,
this
new
thing
and
here's
what
it
does
and
here's
what
I
need
to
care
about
it
and
no
one
really
wanted
to
have
you
know.
No
one
wants
to
have
that
conversation.
You
already
got
50
things
that
you're
thinking.
F
D
You
don't
want
to
have
to
learn
about
a
new
thing
over
the
past
few
years.
I
think
that's
completely
shifted,
and
now
everyone
at
least,
is
aware
that
the
service
mesh
is
a
thing
now.
You
might
not
know
what
it
does,
but
you
know
that
it
exists
and
it's
like
a
you
know,
an
object
in
the
universe
that
you
can
start
thinking
about.
That's
been
a
huge
change,
so
I
think
now
it's
less
about
less
about
like
am
I
aware
of
it
and
more
about
okay?
D
E
In
kind
of
a
more
SEO
specific
case,
I
think
maybe
one
of
the
biggest
blunders
that
we
made
with
the
project
starting
out
is
releasing
it
as
this
big
monolithic
thing,
and
that
has
certainly
been
a
barrier
to
adoption
for
SEO,
specifically
and
to
Louise
point
right
in
1.1
and
then
moving
forward.
We're
making
large
efforts
to
to
try
and
address
that
and
make
a
consumable
piecemeal,
yeah.
C
D
Learned
a
lot
about
that
with
linker
d1
that
X,
which
was
very
much
you,
know
very
widely
deployed,
but
there's
a
lot
of
friction
to
adopting
it,
because
it
was
this
big,
complicated
piece
of
machinery
that
you
had
to
wrap
your
head
around
and
had
this
right
configuration
language
that
you
had
to
learn,
and
you
know
it
was
very
much
presented
as
like.
Hey
you
just
learned
kubernetes,
which
has
a
million
API,
is
now
here's
like
another
thing.
D
That's
super
hard
to
understand
to
layer
on
top,
and
so
people
who
adopted
it,
you
know
they
they
got
to
the
value
prop,
but
it
was
kind
of
at
a
at
a
cost
and
so
with
the
2x
rewrite.
We've
been
taking
kind
of
a
very
sharp
knife
onto
onto
that
and
trying
to
make
it
as
easy
as
possible
to
install
and
to
make
it
feel
not
like
it's
this.
D
You
know
giant
thing:
that's
going
to
require
six
architects
in
a
five-year
plan,
but
instead,
like
it
can
be
a
tactical
decision
like
let's
just
install
it
in
a
single
namespace.
Let's,
just
you
know,
mesh
one
service,
you
know,
let's
just
get
comfortable
with
this
thing
and
make
it
a
tactical
decision,
not
a
huge
strategic
decision,
there's
a
bunch
of
other
like
cool
engineering,
stuff
we've
done
that
I'm
not
talking
about
at
all.
D
B
G
B
That's
not
an
overnight
conversation
right
now
that,
but
that's
a
very,
very
long
conversation.
You
know
internal
that
organizations,
you
know
what
does
this
mean,
for
you
know
my
operations
right
that,
but
that
does
not
change
overnight
so
that
that's
another
thing,
that's
going
to
kind
of
over
time
is
people
understand
the
benefits
of
those
things,
and
hopefully
they
provide
real
benefits
to
them
right.
You
have
to
prove
value,
probe,
I,
know
I.
G
A
A
E
Yeah
so
yeah,
so
how
do
I?
How
do
I
configure
the
Envoy
with
the
new
features
as
it's
being
shipped
in
history?
Oh
lags
behind
that
about
summarizes
yeah,
so
fortunately
there
so
you're
right,
like
we
try
to
kind
of
abstract
the
OnPoint
model
away
a
little
bit,
but
there's
a
great
class
there.
So
there's
there's
it's
called
the
Envoy
filter
CRD.
E
B
So
I
think
you
know
the
general
goal
is
to
more
or
less
keep
pace
with
envoy
right.
You
know
we
haven't
quite
been
able
to
do
that,
because
we've
been
doing
some
major
architectural
things
and
some
structural
things
in
the
API,
because
what
iste
ió
really
does
is
it
takes
a
bunch
of
different
things
right
and
it
assembles
them
into
configs
for
each
individual
envoy
right
and
each
of
those
resources
that
were
assembling
from
has
different
ownership
right,
whether
it's
by
namespace
is
controlled
by
an
admin
right.
B
So
this
what
the
job
of
pilot
is
to
assemble
those
things.
You
know
when
that
piece
becomes
more
stable
and
more
baked
in
and
more
just
more
user
friendly.
Then
it's
much
easier
to
keep
pace
with
the
kind
of
just
raw
envoy
features
right,
because
there
isn't
on
a
feature
by
feature
basis,
as
long
as
the
right
abstraction
or
the.
H
B
A
F
So
you
know
to
your
earlier
point
about
initially
how
we
look
at
service
mesh.
What
is
the
definition
service
mode?
One
of
the
things
is
when
we
we
hear
about
service
mesh
in
context
of
kubernetes
container
management,
micro
services,
but
you
know
those
micro
services.
Applications
need
to
talk
to.
You
know
some
legacy.
Application
legacy
database
sources,
so
we
then
starting
about
API
gateway.
So
how
do
you
guys
see?
You
know
where
the
service
mesh?
B
E
B
You
know
the
probably
the
first
thing
I'd
say
is:
service
mesh
is
not
just
for
micro
services.
Service
meshes
not
just
for
kubernetes
right
we're
actually
working
quite
hard
to
make
sure
that
service
mesh
works
for
VMs
yep
service
veche
works
for
giant
mainframes
I.
Guess
you
guys
make
some
of
those
sure
we
make.
A
B
And
really,
that's
you
know:
I
love!
All
these
service
mesh
products
that
you
see
today
use
proxies
of
some
kind
write.
An
API
gateway
is
a
proxy
right.
So
you
will
see
those
types
of
capabilities
you
know
arrive
in
those
proxies
all
right.
Most
of
what
most
API
gateways
do
today
is
routing
and
envoy
is
a
very,
very
capable
router
right.
So
what
we
do
could
be
concerned.
You
know
pretty
much
equivalent
to
that
right.
The
thing
that
you
see
in
API
gateway
products
that
we
don't
do
a
lot
of
today
is
Content
transformation.
B
But
if
you
went
to
Envoy
Kahn
this
week,
you
would
have
seen
them
talking
about
some
content
transformation
like
features
right
and
you
know
getting
those
things
into
the
data
plane.
So
I
think
it's
a
blurry
distinction,
it's
one
that
we
mostly
don't
care
about,
and
what
we
care
about
is
just
making
sure
that
we
can
put
that
functionality
into
the
places
on
the
workloads
that
need
to
be
talked
to
or
talked
from,
like
whether
it's
VM
mainframe
pod
container
function
right.
It
doesn't
really
matter.
C
So
I
think
we
need
to
draw
the
distinction
between
where
the
code
runs,
which
is
what
you're,
explaining
about
kubernetes
containers,
v
or
whatnot,
and
also
having
the
co-teacher
on
your
application.
Calling
external
services,
which
is
a
use
case,
that
we're
seeing,
of
course,
very
often
and
the
advantage
is
working
of
working
with
a
service
match,
is
that
all
of
the
cost
can
go
out
through
an
egress
gateway
and
that
egress
gateway
can
be
a
central
point
that
you're
using
in
order
to
manage
policies,
access
control,
compliance
security
and
so
on.
A
Other
thing,
I
would
add,
is
I.
Think
service
measures
represent
a
change
in
architecture.
Right
I
mean
API.
Management
traditionally
has
been
an
edge
architecture
where
you
do
all
that
management
on
an
API
gateway
on
the
entry
into
some
environment
and
well,
you
know
what
we're
finding,
of
course
is
that
the
same
kinds
of
things
you
want
to
do
on
the
edge
you
want
to
do
between
applications
and
between
services
and
between
teams,
and
so
you
want
that
same
capability
pushed
into
a
mesh
architecture,
not
an
edge
architecture
and
there's
some
interesting
integrations
happening
I.
E
I
You
talked
a
little
bit
about
the
maturity
of
link
or
D
and
ISTE
o,
or
it
stands
right
now,
but
I'm
curious
I
mean
you're
solving
kind
of
the
same
subset
of
problems.
Broadly
speaking,
is
there
a
philosophical
difference
in
which
each
project
is
headed
or
the
your
approach
to
how
you're
handling
this
the
service
mesh
yeah.
D
I'll
I'll
speak
to
the
linker
D
flaw.
You
know
someone
else
can
speak
to
the
sto
philosophy,
because
I
I
think
you're
right
in
that
the
kind
of
the
goals
or
the
the
value
props
are
the
same.
For
you
know
these
projects,
as
well
as
fifty
other
service
mesh
projects
that
are
out
there,
but
the
implementations
are
very
different.
I
think
that
yeah
yeah
it's
due
to
a
very
different
kind
of
design
philosophies
so
for
linker
D.
You
know
this
kind
of
relates
to
what's
happened
to
us.
D
You
know
in
this
transformation
from
one
dot
X
to
2
dot.
X
we
care
very
much
about
the
operational
surface
area
of
linker
D
like
we
are
asking
you
to
install
this
thing
on
your
cluster
and
you're.
Gonna
have
to
wake
up
for
it
and
you're
gonna
have
to
you
know
debug
it
at
3:00
a.m.
when
things
go
wrong.
Although
things
never
go
wrong,
and
so
that
kind
of
gates,
the
night
gates
that
that
shapes,
the
the
sorts
of
features
and
the
way
that
we
introduce
features
to
linker,
D
and
I.
D
Think
for
us,
like
the
the
goal,
is
kind
of
two
audiences,
the
the
the
first
audience
is
well
who's,
actually
adopting
linker
D.
Well,
it's
kind
of
this
platform
owner
audience
of
you
know
the
people
who
are
the
same
folks,
who
are
adopting
the
kubernetes,
adopting
kubernetes
and
adopting
docker,
and
sometimes
that's
easy
and
sometimes
that's
difficult,
but
then
there's
this
other
audience
of
people
who
they
are
serving,
which
are
the
developers
or
the
service
owners
within
their
organization,
and
we
believe
strongly
at
least
for
link
to
D.
D
We
believe
strongly
that
we
have
to
serve
both
audiences
and
you
kind
of
have
that
you
gotta
satisfy
the
first
folks
because
they're
who
are
actually
going
to
implement
the
service
mesh,
but
then
you
also
have
to
satisfy
who
you
know
we're
not
just
doing
this
infrastructure
in
a
vacuum.
Alright,
we're
not
doing
infrastructure
for
infrastructures,
sake,
I,
hope
we're
doing
it
in
order
to
make
the
lives
of
developers
easier.
D
You
know
who
are
deploying
stuff,
you
know
with
the
service
mesh
actually
understand,
what's
happening
in
their
lives,
also,
there's
a
selfish
interests
there,
which
is
that
whenever
you
install
a
service
mesh
for
the
next
six
months
or
12
months
or
18
months,
the
thing
that
always
gets
blamed
whenever
anything
goes
wrong
as
a
service
mesh.
So
we
are
very
incentivized
to
have
lots
of
Diagnostics
in
there
so
that
we
can
defend
ourselves
because
otherwise
we
end
up
in
these
very
irritating
conversations,
and
it
turns
out
that
it's
DNS
the
whole
day.
It's
always
DNS.
B
So
that
was
you
know,
you're
gonna
walk
before
you
can
run.
You
know
what
now
having
done
a
bunch
of
that
you
know
our
primary
focus
is
on
quality
scale
and
integration
right
and
because
of
the
customers
that
I
talk
to
and
I
think
you
know
IBM
and
other
companies
that
we
partner
with
in
this
space.
You
know
it's
a
lot
about
environmental
integration.
B
It's
a
lot
about
reach
because
ok
I
want
to
do
mesh,
but
I've
only
adopted
kubernetes
for
15%
of
my
workload
right
so
that
I,
you
know
the
security
team
is
bought
into
the
notions,
but
it's
not
useful
to
me
unless
I
can
roll
it
out
everywhere.
All
right,
so
you
know
coverage
is
a
big
deal.
We
get
a
lot
of
asks
a
lot
of
pressure
around
that,
so
that's
been
a
strong
focus
for
us
and
that
has
also
driven
some
architectural
changes
in
the
product
around
componentization
to
make
that
environmental
coverage
easier.
B
So
that
is
the
focus
you
know
probably
has
been
the
tactical
focus
since
100
shipped,
and
we
care
about
the
things
that
William
described
for
sure.
We
work
quite
hard
on
those
things,
but
in
terms
of
kind
of
the
architectural
direction
and
what
we've
been
trying
to
achieve.
You
know
it's
it's
about.
You
know
extending
the
reach
of
the
platform
right
service
mesh,
not
just
for
kubernetes,
ok,.
G
G
Talking
about
low
latency
calls
like
two
milliseconds
or
like
even
low.
Where
is
it
going
to
effect
such
calls
or
are?
Have
we
seen?
That's
one
question.
I
have
another
question:
I
want
to
talk
about
connection
polling
right
now
we
have.
We
have
util
classes,
which
has
this
list
of
connection
polls
between
and,
and
so
it
becomes
faster,
like
the
like.
The
load
is
faster.
How
is
that
handled
in
the
service
fish
architecture
in
general?
So
those.
D
Yeah
I
can
speak
a
little
bit
to
that.
So
first,
you
know
the
way
that
you
know
like
louie
mentioned
the
way
that
the
service
pretty
much
every
service
mesh
works
is
by
inserting
these
proxies
and
there
is
a
cost
to
doing
that
right
in
in
the
in
the
olden
days.
We'd
have
these
fat,
client,
libraries
and
there'd
be
no
cost
to
well
much
smaller
cost,
I
guess
to
calling
them
and
but
the
reason
we've
done.
D
So
there's
always
a
trade-off.
If
you
have
these
incredibly
low
latency
requirements,
then
you
may
not
have
a
service
mesh.
That
is
satisfactory
simply
because
of
that.
On
the
other
hand,
some
of
the
kind
of
fancier
things
that
the
service
mesh
can
provide
may
be
able
to
speed
things
up
and
though,
in
the
long
run,
so
by
having
intelligence
in
the
way
that
the
requests
are
load
balanced
across
things.
D
By
being
intelligent
about
connection
pooling,
and
things
like
that,
sometimes
you
can
actually
speed
things
up,
even
though
you're
adding
more
proxies
and
I
think
we
had
a
blog
post
about
about.
You
know
the
benefits
of
moving
away
from
round-robin
request
balancing,
but
once
you
get
down
I
guess
my
sense
is
once
you
get
down
to
kind
of
the
single-digit
millisecond
stuff,
then
it
gets
a
little
dicey.
Of
course,
link
or
DS
proxies
are
incredibly
fast
and
we
have
a
p99
of
less
than
one
millisecond.
B
Yeah
I
mean
I,
think
it
so
TECA
William
said
you
know:
we've
run
into
situations,
particularly
one
of
the
advantages
service
meshes.
Is
you
get
a
kind
of
more
uniform
network
behavior,
regardless
of
you
know
what
the
application
was
built
with
when
it
was
built,
and
you
know
it
might
have
been
built
seven
years
ago.
You
know:
we've
certainly
seen
cases
in
production
where
people
have
things
go
quite
a
bit
faster
because
they
were
using,
let's
say
HCP
100
without
connection
keepalive
right,
and
that
is
just
really
bad
from
a
network
performance
standpoint.
B
Of
that's
not
even
that
old
right,
you
actually
tend
to
go
faster
ya
know.
We
always
have
a
lot
of
experience
with
this
at
Google,
because
we
actually
use
like
our
proxies
in
the
data
plane
at
scale
in
Google.
We
don't
use
envoy,
but
we
use
something
very
much
like
it,
and
you
know,
we've
talked
before
a
bit
about
the
performance
of
what
we
could
think
we
can
achieve
with
envoy,
which
would
match
what
we've
done
internally
at
Google
and
now
you're
talking
in
the
low
hundreds
of
microseconds
of
overhead
per
hop
right.
B
As
long
as
you
use
the
proxy.
The
right
way
talk
to
it
the
right
way.
That's
eventually
what
we
should
all
roughly
be
striving
for.
That's
not
to
say
that
it's
not
a
hop.
It's
still
a
hop
I
knew
there
are
interesting
efforts
going
on
in
the
ecosystem
around
squeezing
those
hops
down.
You
go
talk
to
the
cilium
guys
and
the
work
that
they've
done
in
the
Linux
kernel
to
kind
of
just
make
local
host
IP
super
super
fast
right,
even
faster
than
UNIX
domain,
socket
right.
B
E
Other
two,
a
little
bit
more
future-looking,
one
of
the
things
that
I
think
that
we'll
see
as
the
server
semester,
control,
plane
matures
and
we
kind
of
standardize
on
api's
for
configuring
data
plane
is
that
you'll
see
heterogeneous
data.
Planes
speak
for
different
use
cases,
because
a
lot
of
minded
business,
Java
apps,
have
SL
O's.
You
know
of
a
second
or
more
and
a
couple
milliseconds
here
and
there
in
the
proxy
is
really
aren't
important,
and
so
maybe
I
want
a
more
feature.
E
Full
proxy,
like
like
liquidity
or
like
envoy,
maybe
I'm
doing
something
really
high
performance,
but
I
still
need
some
of
the
I
still
want
the
load
balancing
architecture
without
extra
hops
through
the
network
that
a
middle
proxy
gives
me
or
I
want
some
limited
amount
of
visibility,
and
so
you
reach
for
some
simpler
implementation.
You
could
imagine
in
the
future
or
something
like
you
know,
some
p4
implementation
that
gives
you
low
level
fast
things
for
those
specific
use
cases
where
you
we're
really
really
matters
now.
E
B
You'll
see
things
like
on
Moya's
user
space,
IP
style
yep.
You
know
at
Google
we're
doing
work
to
make
those
api's
that
the
control
playing
API
is
work
with
G
RPC
directly
right
without
requiring
a
proxy
right
for
a
limited
subset
of
the
features.
So,
if
you're
really
performance
sensitive,
you
can
kind
of
mix
and
match
between
those
two
things.
So
you're
just
gonna
see
a
lot
of
kind
of
innovation
in
that
space.
I
think
and
there's
lots
of
companies
downstairs
talking
about
it.
Go
talk
to
the
FDA.
Oh
guys
like
this.
B
H
Thank
you
today
in
my
company
we
are
handling
this
security,
observability
and
control
with
with
libraries,
and
it's
easy
to
explain
the
advantage
of
going
to
a
standard
service
mesh.
But
these
guys
they
are
now
looking
at
more
doing
more
a
synchronous
communication
with
akka
framework
using
using
Kafka.
H
So
the
question
is
what
what
is
the
position
of
service
machine
in
data
here
and
and
kind
of
sub
question?
Is
that
I
I
would
like
not
to
see
back
a
central
Kefka
broker,
or
something
like
that?
So
are
you
really
thinking
about
taking
a
synchronous
communication,
keeping
the
mesh
structure
of
a
service
mesh
I.
C
Think
this
is
a
really
interesting
question
and
I
think
it's
an
area
that
we're
working
on,
which
is
how
to
extend
the
stl
to
support
multiple
different
protocols,
and
what
does
it
mean
when
you
have
asynchronous
communication
where
you're
gonna
get
the
value
from
Sto?
And
you
know
there
are
several
areas:
visibility
is
one
of
them.
Policy
is
another
one.
So
I
think
this
is
an
active
area
of
research
for
the
future.
B
No,
no
so
this
is
this
is
a
pretty
early
space
right
I
mean
we're,
we're
still
trying
to
get
people
happy
with
HC
P
and
G
RPC
in
the
synchronous
protocols
like
akka,
like
I,
know
the
akka
stuff
pretty
well,
it's
it's!
It's
pretty
impressive
engineering.
I
think
when
you
talk
about
a
synchrony.
One
of
the
more
interesting
things
to
discuss
is
what
what
effect
does
that
have
on
the
security
model
right,
we're
job
a
emits
message
in
to
broker,
and
then
it
spits
back
out
somewhere
jobs
see
how
does
job.
B
So
one
of
the
things
you
want
to
be
really
want
to
be
thinking
about
when
you
talk
about
asynchronous
is
talking
about
message,
provenance
and
the
PKI
infrastructure
that
you
know
we
use
what
spiffy
should
allow
you
to
have
a
strong
provenance
for
messages
as
they
transit
through
brokers
right,
even
though
it's
not
point-to-point
between
two
different
trust,
domains
and
I.
Think
that's
that's
probably
the
thing
we
should
think
about
the
most
right
and
then
routing
and
how
fast
we
get
that
message
there
or
almost
like
that's
technology.
We
can
make
that
go
right.
B
G
A
B
E
B
So
in
in
the
1.1
release,
we've
actually
or
we're
on
the
middle
of
making
things
have
a
much
stronger,
namespace
boundary
in
terms
of
administrative
control.
So
you'll
you'll
see
some
changes
in
the
api's
that
align
better
with
the
kind
of
namespace
as
omit
as
administrative
boundary,
which
is
an
important
feature
for
many.
Many
people.