►
From YouTube: Istio, Envoy, Linkerd - Service Mesh Landscape: Interview with Idit Levine, CEO of Solo.io
Description
Idit Levine, CEO of Solo.io shares her perspective on the Service Mesh landscape, use cases, open source foundations, and other topics in this interview with Kit Merker.
00:00 Welcome Idit Levine
00:22 What is Solo.io and how does it relate to Istio?
01:59 Explain the use cases of service mesh
06:04 Landscape of service mesh projects and tradeoffs
09:40 Will there be one service mesh? Or are we looking at multi-mesh world?
12:43 Envoy-based solution is preferable
14:36 Easy vs. Industrial Grade? Example of progress?
18:50 Thoughts on Google Open Usage Commons?
22:25 What about the conferences and marketing?
25:13 Future of reliability impact from service mesh
26:40 Thank you and goodbye!
A
B
I
mean
particularly
we'll
be
focusing
on
two
areas:
three
pillars:
the
first
one
is
the
api
gateway
and
we
have
a
api
gateway
built
on
top
of
envoy
called
glue
who's
running
in
the
biggest
organization
that
exists
in
the
market
today.
The
other
thing
that
we're
doing
we
have
a
product
called
service
mesh
hub,
where
it's
basically
an
abstraction
layer
to
all
the
service
mesh.
So
it's
defining
the
api,
all
the
service
mesh
and
you
also
call
at
the
concept
of
virtual
mesh.
So
you
can
actually
do
it.
B
Two
meshes
group
them
together
and
we're
doing
all
the
work
behind
the
scene,
so
you
can
do
it
with.
You
know
two
instances
of
stl,
for
instance,
so
you
can
do
it
with
an
instance
of
sdo
and
app
mesh.
For
instance,
it's
basically
act
like
one
big
mesh
and
the
last
one
that
we're
doing
is
basically
around
webassembly.
So,
as
we
know
in
the
market,
everybody
they're
running
get
a
glue
or
any
type
of
service
mesh.
It's
never
a
perfect
fit
to
any
infrastructure.
B
What
you
need
is
usually
do
some
customization
around
it,
and
there
is
two
way
to
do
this.
One
of
them
is,
do
it
to
the
control
plan,
and
for
that
you
probably
will
write
operators.
So
we
have
a
a
kind
of
like
an
open
source
project
called
autopilot
that
helping
you
to
build
an
operator
for
service
mesh,
and
the
other
thing
is
the
data
plan
itself
for
envoy.
A
So
maybe
for
people
who
are
less
familiar
with
service
mesh,
not
you
could
explain,
you
know
the
use
cases.
You
know
I've
heard
that
it
helps
with
kind
of
web
and
api
and
transactional
workloads.
I've
heard
that
adding
service
match
to
kubernetes
can
kind
of
just
make
it
run
better
and
give
you
better
service.
Metrics.
I've
heard
that
you
can
use
the
metrics
from
service
match
to
get
service
level.
A
B
Yeah,
I
think
that
when
you
look
at
service
machine
generally,
you
need
to
understand
you
need
to
separate
the
implementation
data
from
the
actual
use
case,
and
I
think
that's
what's
special
about,
like
I'm,
specifically
passionate
actually
about
the
implementation
details,
because
I
believe
that
the
way
service
mesh
is
actually
abstract
and
the
problem
that
it's
trying
to
solve
can
be
leveraged
for
a
lot
more
different
problems,
and
we
just
carefully
basically
just
started
right.
There
is
way
more.
We
can
do
so
in
the
nutshells.
B
The
way
I
think
about
it
is
that
we
obstructed
it
right.
I
mean
we're
basically
putting
this
sidecar
piece,
which
is
a
proxy,
usually
and
but
sometimes
something
else
next
to
each
of
an
a
basically
a
micro
services
right
or
inside
a
port,
basically
next
to
your
application
and
then
you're
doing
it
to
a
lot
of
them
right
and
that's
basically,
what
obstructing
the
network
and
you're
treating
tricking
that
the
ip
table
that
every
traffic
in
and
out
we
have
to
go
through
this
proxy.
It's
an
inversion.
B
You
have
this
proxy
and
proxy
proxy
can
do
a
lot
of
stuff,
but
it's
not
extremely
smart.
You
need
to
tell
them
what
to
do
when
the
request
is
coming
so
basically
by
you
putting
that
next
to
each
application
right
and
basically
defining
it
as
the
gate
to
the
application.
So
the
microservice
cannot
talk
to
anybody
without
going
through
this
and
cannot
basically-
and
nothing
can
talk
to
him
without
going
through
this
thing.
B
Now
we
have
this
ability
to
configure
configure
the
things
and
because
we
basically
can
watch
everything
that
coming
in
and
out
we
can
make
a
decision,
for
instance,
is
that,
okay,
that
this
micro
service
will
talk
to
each
other?
Is
that
you
know?
Maybe
you
want
to
do
a
retry.
Maybe
you
want
to
do
to
grab
some
logs
right
and
anything,
basically
that
we
want
and
the
beautiful
of
it.
Imagine
that
it's
basically
like
a
x-ray.
You
can
see
everything.
That's
happening
right.
B
You
can
see,
you
know
when
you
have
bugs
before
it
could
be
inside
the
microservices.
It
could
be
on
the
latency,
but
you
can't
know,
and
what
service
mesh
is
giving
is
the
ability
to
basically
put
the
cycle
next
to
it
and
then
have
control
to
see
everything
that
going
in
the
microservices
and
on
the
transaction
right
on
the
pipe.
I
think
this
is
very,
very
powerful,
and
now,
if
we
basically
obstruct
the
network,
there's
way
way
more,
we
can
do
right.
I
mean
we
can
leverage
it
for
security.
Right
kenny
cannot
talk
to
people.
B
You
can
leverage
that
for
observability
right,
you
can
say.
Oh
now,
I
can
actually
see
what
happens,
so
we
can
be
smart
about.
What's
going
on
or
debug
it
simpler,
you
can
do
stuff,
like
you
know,
cited
breaking.
So
maybe
something
like
chaos.
Engineering
would
be
very
interesting
because
now,
instead
of
embedded
library
inside
your
code,
you
can
basically
just
come
on
top
of
it
and
it
injects
basically
like
folding
jacks
information.
You
can
do
stuff
that
related
to
just
special
writing
routing.
B
I
have
two
micro
services
right
and
I
want
them
to
talk
to
each
other.
So
all
of
this,
I
think,
becoming
very,
very
useful,
specifically
when
you're
talking
multi-cluster,
that's
even
more
complicated
to
the
fact
that
you
actually
have
right
now,
two
instances
of
mentions,
and
how
do
you
manage
that?
I
think
that's
the
big
problem
that
people
are
trying
to
do
right
now,
so.
A
When
your
company's
looking
across
service
meshes
in
multiple
types,
there's
multiple
flavors
and
projects
and
solutions
out
there
for
service
mesh-
and
maybe
you
have
a
unique
perspective
here
on
the
off
since
you're
working
with
so
many
of
them,
I
haven't
been
able
to
get
kind
of
a
clear
picture
of
the
landscape.
Maybe
you
can
help
me
understand,
you
know
the
landscape
of
service
mesh
and
how
the
maybe
the
different
trade-offs
are,
or
the
differences
between
the
projects.
B
Yeah
now
that's
funny
actually,
actually
so
when
we
started
working
with
service
mesh,
it
was
over
almost
two
years
ago,
and
what
was
clear
to
me
is
that
that
would
be
big.
But
it
also
was
clear
to
me
that
first
of
all,
it
would
take
a
while
and
bills
will
get
there
so
like
two
years,
and
this
is
why
we
started
with
api.
B
But
so
when
we
looked
at
this,
I
basically
said
to
myself:
okay,
we've
been
there
before
we
saw
it
going
with.
You
know,
with
the
orchestration
ecosystem.
Right,
kubernetes
vs
mesos
all
of
this
and
try
to
figure
out
what
I
can
do
that
is
not
building
mesh,
because
I
knew
that
it
would
be
harder.
That
would
be
helpful
and
then
the
ashikob
guys,
who
we
know
very
well.
We
have
the
same
founder
and
I
know
our
mom
mitchell
very
well
basically
reached
out
to
us
and
said
here's.
B
B
So
we
start
with
that,
and
then
it's
kind
of
like
it
means
that
that
instead
of
trying
to
build
the
service
mesh,
I
don't
want
to
put.
I
don't
want
to
try
to
build
another
service
mesh
to
complete.
What
I
wanted
to
do
is
to
try
to
figure
out
what
would
be
the
next
problem
that
people
would
try
to
solve
when
servicemen
would
be
everywhere,
and
what
I
realized
is
that
the
first
problem
that
people
wanted
to
solve
is
the
fact
that
there
is
more
than
one
and
more
than
one
instance.
First
so
like.
B
If
you
have
two
clusters,
you
will
have
two
instances
of
service
mesh.
You
have
two
instances
of
service
mesh,
it's
already
an
orchestration
problem.
How
do
you
manage
it?
Are
you
making
that
they,
they,
you
know,
upgrade
you
know,
version
control
and
so
on.
So
that's
the
first
thing,
but
after
working
with
ashley,
I
realized
that
the
problem
will
be
even
bigger,
because
if
someone
will
run
ashikop
in
on-prem
and
again
this
vision
of
two
years
ago
right
when
they
will
go
and
want
to
use
google
cloud
they
most
likely.
B
We
want
to
use
the
native
solution
there,
which
is
st.
So
how
is
that
going
to
work?
And
that's
basically,
where
we
come
with
the
fact
that
not
only
potentially
will
have
more
than
one
instance
it
could
be,
but
potentially
to
be
a
different
one:
okay,
so
the
mess
that
there
is
right
now
in
the
ecosystem,
just
to
be
fair.
I
I
predicted
long
time
ago
so
now
after
we
announced
this
aws
reach
out
and
aws
announced
up
me
right.
B
So
if
you
look
right
now
in
the
ecosystem-
and
you
kind
of
look
at
this
three
of
the
biggest
cloud
going
to
have
a
different
measure,
besides
that
you
have
cronk
with
kuma
right,
you
have
console
connect,
you
have
linker
d
and
you
have
sd
and
that's
for
now,
because
I
know
that
there
is
another
one
coming
up
so
now.
The
question
is:
how
is
that
you
know?
Who
is
the
winner?
B
Why
should
you
choose
one
by
the
other
and,
to
be
honest,
it's
a
little
bit
frustrating
that
this
is
the
ecosystem,
and
this
is
the
market
because
to
be
fair,
this
is
a
really
it's
like
amazing
piece
of
software
like
the
ideal
service
mesh,
and
it's
a
shame
that,
because
of
the
mess
people
scared
to
kind
of
like
adopt,
and
that's
exactly
what
I
tried
to
prevent
in
service.
So.
A
There
being
a
single
winner
that
the
the
long
term
kind
of
steady
state
of
service
mesh
will
be,
you
know,
multiple
players
playing
side
by
side,
but
you've
also
kind
of
pointed
out
that
they
have
a
similar
api.
They
actually
can
be
orchestrated
and
work
together
across
different
instances.
So
isn't
it
kind
of
a?
I
don't
want
to
say
commodity,
but
isn't
it
kind
of
a
you
know,
a
technology
that
you
know
it's
kind
of
all
doing
the
same
thing
or
is
there
really
a
difference
in
terms
of
each.
B
B
B
So
it
was
a
good
building
block
to
work
together
and
basically
get
to
where
it
is
today
when
sto
in
the
beginning,
they
make
some
architecture
decisions
that
make
other
people
wanted
to
compete
because
they
didn't
feel
it's
good
enough
right.
So
now
it's
just
in
the
matter
of
time.
Right
I
mean
you
know,
people
started
competing.
They
have
already
decided
that
that
they're
going
to
create
their
own
and
not
to
kind
of
like
go
and
consider
it
and
one
of
them.
B
B
Not
technically
totally
totally
so
now,
let's
talk
about
the
the
market,
the
first
two
one
that
was,
if
you're
looking
at
the
one
that,
to
my
opinion,
is
the
more
advanced
is
seo
and
linkedin
linkedin
is
not
based
on
envoy
and
that's
a
big
big
minus
to
them.
I
think
the
reason
not
because
the
technology
is
the
minus-
I
mean
I
think,
they're
they're.
You
know
that
they're,
actually,
a
rust
proxy
is
really
good.
It's
really
good.
B
What
are
you
curious
about
the
use
cases?
What
actually
is
the
feature
that
you're
getting,
and
I
think
you
will
get
more
with
an
envoy
based
a
service
mesh
than
something
like
linkedin,
so
it's
not
the
best.
It's
not
about
the
best
technology
just
about
the
market.
Already,
as
you
said,
for
solar
rate,
it
can
go
faster.
A
B
The
fact
that
android
is
part
of
the
solution
and
nvidia
has
this
ability
to
be
extended
via
a
you
know,
add
feature
with
something
called
a
filter
that
and
I'm
reading
there
and
other
people
writing
filter.
Now
there
is
an
ecosystem
and
I
can
leverage
each
other
so
in
the
nutshells,
if
you're
buying
for
me
a
proxy
right
or
glue
right,
api
gateway
or
seo.
What
you
will
get
is
more
feature
and
will
be
able
to
give
you
more
things.
B
I
can
give
you
a
secret
breaking
that,
maybe
you
will
not
be
able
to
get
with
a
good
day
right
now,
and
you
know
now:
google
did
an
amazing
work
by
actually
bringing
it
was
web
assembly
to
android.
So
again,
now
people
can
write
their
own
filter
very
easily.
You
know
with
that's
the
work
that
we
did
with
webassembly
hub.
B
That's
a
huge
benefit
to
a
customer
right,
it's
really
it's
getting
independence
which
they
cannot
do
right
now
with
linkedin,
and
I
don't
think
they
work
with
anytime
soon.
So,
basically,
if
you
think
about
it,
you
just
didn't
what
you're
getting
in
turn.
Eventually
is
a
lot
of
power
as
a
customer
that
can
use
a
lot
of
good
features
that
you
need.
So
that's
why
I
think
that
every
base
is
the
direction
to
go.
So
that's
number
one.
So
that's
kind
of
like
putting
link
your
day.
B
A
When
you
think
about
the
trade-off
between
ease
of
use
and
industrial
grade,
we'll
say
right,
there's
there's
on
the
one
side
and
this
isn't
unique
to
service
mesh,
it's
kind
of
when
you
look
at
technology
or
products,
you
kind
of
have
to
think.
Okay,
what's
going
to
be
easy
to
get
started
versus,
what's
going
to
give
you
an
industrial
grade
product
and
when
you're
thinking
about
the
spectrum,
you
know.
A
Where
istio
is
on
that
spectrum,
and
and
where
will
it
be
in
the
future?
First
of
all,
and
second
part
of
that
I
want
to
know
you
mentioned
that
that
there
are
things
in
the
direction
that
you're
excited
about,
that
it's
easier
to
use
or
simpler
than
it
used
to
be.
Can
you
give
me
some
specific
examples?
Can
you
tell
me
two,
or
you
know
one
or
two
things
that
really
get
you
excited
about
the
future.
B
Yeah,
so
I
mean
we'll
start
with
the
second
one,
maybe
because
I
remember
it
and
then
we'll
go
to
the
first
one,
so
the
first,
the
second
one.
I
think
it's
what
I'm
really
excited
about.
They
doing
so
it's
very
simple.
I
mean
I'll
try
to
explain
that
in
the
most,
not
technical
way
that
I
can,
but
I
mean
in
the
nutshells
android
envoy-
can
be
extended
and
you're
extending
by
writing
a
c
plus
class
asking
filter,
that's
a
very
hard
thing,
and
then
you
need
to
rebuild
and
work.
B
That's
something
that
we're
doing
very
well,
but
to
be
honest,
most
of
the
people
not
so
we
had.
You
know
we
needed
to
figure
out
how
to
attach
it,
because
we
we
knew,
we
knew
as
google
knew
and
everybody
that
we're
using
envoy
knows
that
not
everybody
can
write
an
you
know
an
android
filter,
and
but
there
is
a
need
in
the
customer.
So
basically
the
way
we
did
it.
We
basically
said
we
will
write
it
right.
We're
writing
those
twitter,
they're
very
complex,
we're
giving
you
what
we
need
we're
giving
a
destroyer
envoy.
B
Oh
god,
google
tried
to
figure
to
go
to
another
direction,
which
is
basically
using
something
called
mixer.
So,
basically,
every
time
that
the
request
is
coming
to
envoy,
it's
basically
doing
a
geo
proceed
to
are
to
a
go
server
and
you
can
put
some
code
right,
basically
adaptive
there.
The
problem
with
that
was
that
the
the
performance
right
this
is
on
the
request
path.
It's
very
sensitive
in
terms
of
you
know
doing
the
round
trips.
Don't
suddenly
with
all
this
data.
B
Sent
and
every
time
that
you
heard
the
best
thing
about
scalability
and
seo,
that
was
the
problem.
The
problem
was
the
wrong
trip
every
time
that
you
want
to
change
a
simple
thing
in
data:
you
need
to
send
us
all
the
body
and
everything
to
the
mix.
It
just
become
very,
very
problematic,
so
one
of
the
things
that
they
decided
to
do
right
now
and
again.
I
think
this
is
great.
B
B
So
all
of
this
means
that
now
you
as
a
customer
who
won't
do
whatever
pending
editor,
let's
say
or
whatever
create
your
own
filter-
can
do
it
in
any
language.
You
want
and
very
easily
be
up
and
running,
and
I
think
this
is
this
would
be
great
because
that
will
solve
the
biggest
problem
that
sto
has
in
performance.
So
I
think,
by
day
doing
this
that
you
know
that
will
go
a
long
way,
so
I
think
that
it's
becoming
way
way
way
better,
because
it's
solving
the
main
major
problem.
B
B
But
by
doing
this
they
chose
an
api
that
is
a
little
bit
implementation
details
in
the
point
of
like
you
can
see,
for
instance,
sidecar
object
in
the
api
of
of
sto,
but
sidecar
is
implementation,
detail.
Theoretically,
it's
not
a
picture
right,
so
in
the
nutshells.
I
think
that
it
would
be
welcome
to
have
some
obstruction
that
define
what
actually
you're
trying
to
do
and
what
you're
actually
trying
to
do.
You
try
to
group
a
source
group,
a
destination
and
put
the
policy
on
the
pipe.
B
A
Yeah
yeah,
of
course,
I
I
want
to
ask
you
just
shifting
gears
here
a
little
bit
and
I've
been
kind
of
exploring
this
topic
with
several
people.
So
I
appreciate
getting
your
your
take
on
it
as
well.
So
last
week
google
announced
that
istio,
along
with
two
other
projects,
would
be
joining
the
newly
found
open
usage
comments
and
not
the
cncf,
as
some
people
had
anticipated
and
open
usage
comments
would
be
the
neutral
home
for
the
trademarks.
A
B
So,
let's
understand
because
I
think
it's
important
it's
educational,
to
understand
what
does
happen
when
you're
giving
a
project
to
a
cnc.
So
what
do
you
give
so
so?
Usually
those
open
source
projects
are
already
apache
apache,
which
means
that
the
ip
is
not
relevant
here.
So
there's
two
things
that
is
really
relevant.
The
first
one
is
the
trademark
right
who
owned
the
trademark
and
the
second
one
is
the
gun.
Right
I
mean
you
know:
how
does
this
project
work?
Who
is
defining?
What
is
the
direction
of
this
and
usually
in
cncf
they're?
B
B
They
have
a
very
good
one.
Now
there
is
basically
two
committees
there.
One
of
them
is
defining
the
direction,
the
technical
direction
and
to
be
fair
and
and
one
of
them
is
motherboard,
and
I
can
tell
you
that
in
both
of
them
google,
one
of
the
google
is
not
the
majority
already
which
mean
that
you
know
by
the
way
gover.
B
You
know,
I
will
argue
that
ibm
is
part
of
it
and
the
other
one
who
can
change
it
and
change
the
governments
the
way
they
want,
because
they
actually
have
a
lot
of
power
now.
So
that's
number
one
and
number
two
and
the
other
one.
They
were
the
majority
and
they
just
basically
suggested
to
stop
that,
and
basically
they
came
with
a
new
rule
to
first
of
all,
extend
it
to
13
people
and,
second
of
all,
make
sure
that
none
company
can
be
a
majority.
B
So
what
you
can
say
forget
about
that
forget
about
the
politics
me
as
a
user
want
to
use
it.
Am
I
in
dangerous
by
going
with
google,
with
the
sdo
right
now,
I
will
update
that
now,
because
the
trademark
is
not
google
anymore
right.
They
gave
it
to
this
thing.
So
that's
done
right.
So
that's
equivalent
that
giving
you
to
their
sins,
yeah,
exactly
same
thing,
someone
else
owning
the
trademark
and
overall
government
exactly
like
it
will
be
if
they
will
give
it
to
the
cncf.
B
Google
will
not
be
in
the
majority
and
guess
what
there
will
not
be
a
majority
here
as
well,
and
I
can
tell
you
as
someone
who's
not
like
they're
working
a
lot
with
their
store
community.
I
don't
feel
that
there
is
any
problem
with
the
government.
I
don't
feel
that
I'm
not
being
heard.
I
don't
feel
that
I'm
you
know
so
in
the
natural.
It's
the
same
thing
so
now.
B
B
A
Also,
the
marketing
and
conferences
and
and
kind
of
the
community,
if
you
will,
which
is
not
you
know,
quote
unquote
owned
by
any
organization
or
any
any
group,
and
the
affiliation
is
probably
a
bit
looser
for
people
that
they
feel
like
they're.
Part
of
you
know
the
cncf
community
or
the
kubecon
community,
because
they
go
to
those
events
and
they
they're
part
of
the
the
sigs
and
there's
there's
a
certain.
I
don't
want
to
say
culture,
but
there's
a
certain.
A
You
know
a
group
of
people
who
are,
and
it's
a
worldwide
group
of
people
who
are
sort
of
all
working
in
these
areas,
regardless
of
whether
that
affects
the
the
actual.
You
know
kind
of
mechanics.
If
you
will
of
the
future
the
project
there's
a
there's,
a
feeling,
there's
a
sense
of
being
a
part
of
it
and
being
in
something
new.
What
do
you
say
to
those
people
who
are?
You
know
going
to
be
a
kubecon
and
are
and
they
care
about
istio,
and
they
want
to
be
a
part
of
both.
A
B
See
it
I'm
sad
that
this
is
going
that
way,
but
I
will
argue
that,
as
you
can
say,
I
mean
the
the
thing.
As
you
said,
and
I
should
have
probably
mentioned
it-
that
the
cncf
is
doing
is
basically
giving
a
lot
of
marketing
right
and
that's
very,
very
helpful.
It
is
helpful,
but
then
again
look
to
me
personally,
and
this
is
very
personal.
I
don't
think
that
the
project
has
to
be.
You
know
I
want
to
make
sure
that
I
will
be
able
to
use
it.
B
I
want
to
make
sure
that
I
will
be
able
but
you're,
looking
at
very
successful
projects
like
something
like
ashi.
She
has
tons
of
very
successful
projects
that
was
using
in
a
lot
of
communities
and
they
are
still
not
in
a
community,
and
this
is
fine.
It
doesn't
mean
that
this
project
is
not
useful
project
like
vault
of
most
of
the
us
is
using.
So
I
don't.
A
Shift
shift
back
just
for
a
moment
as
we're
kind
of
wrapping
up
here.
What
what
do
you
see?
You
know
you've
talked
a
little
bit
about
the
future
of
of
this
technology
and
the
the
different
landscape.
But
when
you
look
at
some
of
the
challenges
that
we're
facing
in
the
world
right
now
around,
you
know
digital
reliability.
A
You
know
everybody
is
pretty
much
not
traveling,
and
so
many
things
have
moved
online,
so
much
of
business
and
life
and
everything
is
now
kind
of
relying
on
the
internet
and
relying
on
services
in
the
internet.
As
you
kind
of
you
know,
look
forward
a
couple,
you
know
years.
Maybe
how
does
service
mesh
fit
into
that
future
of
kind
of
the
reliability
and
and
consistency
of
services?
Where
do
you
see
this
kind
of
going
over
the
next?
You
know
as
you're
just
kind
of
looking
ahead
so.
B
If
you're
looking
at
the
service
mentions,
I
said
to
you
one
of
the
biggest
use
cases
that
customers
talking
about
is
security
right,
mtls
and
you
know
zero
trust,
networking
and
everything
that
is
doing
as
well
as
a
help
to
debug
problem.
Now
now
everything
is
on
the
internet
and
a
lot
of
more
people
using
it.
I
think
that
it's
critical,
that
you
will
be
able
to
detect
real
quick
problem
and
solve
them
and
make
sure
that
it's
extremely
secure.
So
I
think
that
there
is
a
big
big
big.