►
From YouTube: The State of Service Mesh
Description
Service mesh has arguably been the hottest topic in the open source and cloud native communities over the past two years. KubeCon Europe 2019 continues the enthusiasm with close to 20 sessions and talks about service mesh this week. At this breakfast our panel of experts will discuss the latest service mesh technology developments, lessons learned and best practices for adopting service mesh, challenges and opportunities that lie ahead for Istio and Envoy open source projects, and what’s next for service mesh in the coming year.
A
A
A
A
One
of
the
things
that
we
like
to
do
with
these
pancake
breakfasts
is
make
them
a
real
question-and-answer
opportunity
for
you
to
ask
questions
to
make
it
interactive
and
create
some
dialogue
here.
To
do
that,
you
each
have
your
tickets.
Did
everyone
get
a
raffle
ticket?
If
you
didn't
raise
your
hand?
Okay,
we
have.
We
have
one
raffle
ticket
over
here.
It's
needed!
Oh,
you
got
it.
Oh
you
got
it.
Okay,
as
everyone
is
everywhere,
everyone
has
a
raffle
ticket,
excellent.
A
So
here's
the
deal.
If
you
ask
a
question,
you
get
five
extra
raffle
tickets
and
the
prize
is
an
Arduino
and
that's
just
how
it
goes
and
so
feel
free
to
ask
your
questions
and
we'll
give
you
those
extra
tickets
and
you'll
get
a
chance
to
win
in
the
drawing
surface.
Brush
is
a
topic
that
consistently
draws
interest
on
the
new
stack.
A
We
see
the
topic
being
discussed
over
and
over
and
over
again
in
the
stories
that
we
write
in
the
podcast
that
we
published
and
I'm
curious
about
it,
because
it's
quite
an
abstraction
and
it
leads
to
a
lot
of
questions
you
know
about
how
we
think
about
our
infrastructure
overall.
So
that's
really
going
to
be
the
focus
I.
Think
of
our
discussion
today
and
so
I
just
want
to
introduce
our
speakers.
A
We
have
cliff
cliff
grosser,
Edie,
Levine,
paramount
clue
and
pop
in
thorium,
and
let
me
just
get
that
right
again,
fluorine,
so
it'll
come
up.
I
just
said
there
we
are
make
sure
I,
pronounce
your
name
by
Floria
deed
way,
then
Swisscom
and
he
and
Edie
Levine
we're
all
here.
So
thank
you
very
much
for
joining
us
on
this
panel
discussion.
A
I
want
to
just
get
started
to
ask
you
all
a
question
about
what
is
networking
anyway,
these
days,
it's
it's
with
service
mesh
technologies,
we're
starting
to
ask
these
questions
and
I
know
that
you're,
probably
thinking
about
these
questions
quite
a
bit
yourself,
so
maybe
cliff
you
could
get
get
started
with
that,
because
you're
the
one
actually
who
suggested
that
and
so
I'd
love
to
get
your
thoughts.
Okay,.
B
Sure,
well,
I,
I
think
the
way
I
look
at
it
is
having
been
in
networking
for
many
many
years.
His
service
mesh
is
a
chance
for
us
to
rethink
how
we
should
be
doing
networking
and
I
don't
want
to
imply
that
we
didn't
do
it
right
the
first
time,
but
we
did
it
right.
We
did
it
that
way
because
of
a
particular
time
in
the
world
where
applications
were
monolithic,
we
were
very
device
centric
and
it
served
us
well.
B
A
C
I
think,
like
everything
that
happening
in
this
system,
starting
with
beginning
with
the
hardware,
that's
where
we
were
until
now,
but
but
every
what
we
trying
to
do
right
now
is
talk
about
application
in
the
end
of
the
day.
That's
what
we
care
and
I
think
that
several
smash
is
exactly
doing
this
instead
of
folk
talking
about
hardware,
she
was
talking
about
layers.
What
we're
talking
about
is
services
right
of
the
application.
C
D
F
Maybe
the
thing
that
has
happened-
the
last
few
years
is
that
recently
networking
was
an
infrastructure
layer
that
you
would
create
ahead
of
time.
So
you
would
think
in
terms
of
compute.
So
that's
not
working
regardless
of
what
type
of
applications
you
would
create
on
top
and
suddenly
we
went
to
the
opposite
thing,
which
is
networking
is
just
a
service
to
assess
the
application
to
provide
secure
connectivity.
So
the
biggest
change
is
not
necessarily
that
went
from
hardware
to
software
or
from
infrastructure
to
application.
F
But
is
this
notion
that
never
became
something
that
you
have
to
create
on
demand
in
a
way
that
you
fulfilled?
And
it's
from
the
application
point
of
view?
And-
and
this
is
the
aspect
that
now
you
start
thinking-
how
do
I
serve
better?
The
application
and
I
see
what
the
stack
as
you
get
into
micro
services,
API
gateways
and
so
on.
Now
the
meaning
of
networking
starts
to
change
because,
instead
of
identity
being
an
IP
address,
now,
identity
may
be
something
a
little
bit
more
abstract
like
a
certificate
or
stronger
identity
connectivity.
G
So
what
with
all
the
kubernetes
clusters
but
we've
deployed,
either
internally
or
for
external
customers,
something
which
comes
to
mind
when
they
think
about
service,
meshes
programmability
and
also
avoiding
the
need
to
know
what
is
the
network.
So
we
don't
have
to
know
about
Reuters,
which
is
anything
we
just
think
about
services
and
linking
things
together
and
applying
policies
and
that's
a
big
change
from
previous
networking.
But
you
really
have
to
know
all
the
internal
details
and
how
it
works
and
about
something.
That's
really
really
an
evolution
from
before.
So.
A
How
solely
for
you,
your
thoughts
on
networking
I
mean
you've
been
in
the
networking
space
for
a
long
time
and
you've
seen
this
transformation.
You
you've
been
you,
you
are
soccer,
captain
still
aren't
you
and
so
you've
seen
the
container
ecosystem
really
grow
out,
and
what
is
what
has
happened
to
the
concept
of
networking
in
the
process?
For
you,
yeah.
H
Glad
that
you
brought
up
containers
because
I
think
that
that's
an
interesting
reflection
and
makes
it
maybe
easier
to
understand,
what's
happening
with
the
proliferation
of
services.
If
we
step
back
one
step
back
before
containers
and
we
were
dealing
with
VMs
and
VM
sprawl,
you
think
about
actually,
if
you
step
back
even
further
to
physical
machines,
they
might
have
had
for
maybe
eight
physical
NICs,
you
could
assign
you
know
virtual
IP
addresses
to
those.
H
So
maybe
maybe
twenty,
if
you
were
maxing
out
sort
of
IP,
addresses
endpoints
on
the
network
that
maybe
maybe
that
many
services
that
you
would
be
hosting
off
of
a
physical
node.
You
move
over
to
VM,
you
might
take
that
times.
Four,
you
got
a
rush
of.
You
know
up
to
fifteen,
to
twenty
VMs,
a
bunch
of
different
virtual
interfaces.
Their
containers
then
100
something
containers
per
server
potentially
right
times
that
mean
so
it
just
gets
more.
Then
you
bring
in
services
and
you've
got
some
of
the
same
concerns.
H
You've
got
services
for
all
as
you
get
into
micro
services.
You
end
up
if
you're
doing
something
very
meaningful,
you
end
up
moving
pretty
quickly
bringing
forward
quite
a
few
more
services
and
so
you'd
need
with
each
of
those
layers.
New
tooling
has
been
brought
forth
to
manage
a
lot
of
the
same.
The
same
concerns
so
the
service
mesh.
It's
nuanced,
but
reincarnates
a
lot
of
concepts
that
we've
known
kind
of
all
along
it's
just
a
different
different
type
of
tooling.
H
B
I
actually
just
wanted
to
add
one
more
thing:
there's
also
pitfalls
that
we
need
to
watch
out,
for
sometimes
we
can
use
a
word
like
a
service
and
think
that
we
changed
the
world.
Well,
in
fact,
TCP
is
a
service
and
it's
embedded
in
the
OS
and
all
programs
since
the
beginning.
Well,
for
many
many
years
you
see
CP
as
a
service
to
do
network
connectivity.
The
real
difference
from
my
perspective
is
the
level
of
abstraction
that
the
service
provides
hiding
the
complexity
of
the
underlying
implementation
and
also
allowing
program
abilities.
C
So
I
think
that,
like
everything
we're
doing
in
this
ecosystem,
we
starting
solving
problem
like,
for
instance,
moving
from
analytic
to
micro
services,
and
then
we
open,
you
know
a
lot
of
more
problem
to
the
user.
So
I
think
that's
exactly
what
happened
in
this
evolution.
Everybody
got
very
excited
about
micro
services.
I
wanted
to
move,
but
now
they
need
to
solve
problem
like
how
do
you
communicate
between
those
micro
services?
How
do
you
make
sure
that
it's
securely
okay
and
the
last
one
is?
C
How
do
you
make
sure
that
you
actually
can
see
what's
going
on
in
your
cluster
and
that's
basically
the
main
problem
that
service
mesh
is
trying
to
solve
right
now?
So
what
I'm
more
passion
about
is
the
way
it's
solving
it
and
they
opportunity
that
we
are
getting
from
it
so,
basically
by
abstracting
and
taking
the
operation
code
from
actually
the
application
itself
before
you
needed
to
import
a
library,
and
now
it's
all
configurable
on
the
sidecar
I
think
now
we
basically
abstract
the
network
and
we
really
abstract
an
echo
from
the
business
code.
C
A
F
Maybe
what
we
see
is
that
a
lot
of
people
don't
necessarily
start
thinking
that
service
maze
is
networking,
I
mean
a
lot
of
people,
start
thinking.
Well,
I'm
a
developer
I
can
put
east
UN
envoy
I
can
instrument.
My
application
I
can
understand.
What's
going
on,
latencies
I
can
predict
that
this
specific
pot
has
a
problem.
So
what
we
saw
is
a
lot
of
people
started
by
observability
and
understanding.
What's
going
on
once
you
start
by
the
observability,
then
immediately
start
thinking
can
I
do
something
more
interesting.
F
What
I
do
like
progressive
rollouts
upgrades,
blue,
green
testing
and
so
on?
So
what
we
saw
is
that
it's
much
more
like
close
to
a
DevOps
tool,
like
the
understanding
of
how
do
I
tie
my
processes
in
terms
of
application
deployment.
Upgrades
constant
monitoring
of
SLA
is
a
loss
with
service
measure.
I
would
not
say
that
the
first
thing
that
comes
to
everybody
in
mine
is-
or
this
is
a
networking
tool,
it's
much
more.
It's
like
a
development
operations
tool
that
allows
you
to
maintain
your
applications
and
then
immediately.
F
You
start
going
to
the
point
of
saying.
Well,
if
I
can
understand
what
application
is
doing
with
what
data
or
what
else
indicated
user
is
coming
to
this
and
I
can
track
the
token
and
can
have
a
tracing
and
when
then,
you
start
thinking
in
terms
of
advanced
users
of
security,
so
I
think
sometimes
we
oversimplify,
because
the
fact
that,
of
course,
you
provides
connectivity
with
MPLS
and
this
route
about
balancing
and
all
these
things.
F
But
the
reason
why
it's
powerful
is
not
just
because
it
provides
connectivity
and
load
balancing
and
so
on
is
we
could
help
you
to
tie
processes
in
terms
of
operations
and
security
that
are
much
more
advanced,
that
what
could
be
done
in
different
layers-
and
this
is
what
we
see
is
not
necessarily
oh.
This
is
a
networking
technology,
it's
much
more
than
that,
it's
much
more
as.
G
I'm,
it's
tough
to
go
after
payday
because
it
says
everything
what
you
need
to
say
about
service
meshes
I
mean
everything
is
a
little
bit
the
thing,
but
with
this
I
seen
service
messages,
but
everyone
sees
about
policy
management
and
every
talk
I've
been
to
about
service
messages.
People
have
asked
what
about
the
scalability
of
wisping.
So
of
course
it's
the
easy
question,
but
by
the
community
today
it's
much
more
and
as
it
says,
we
have
to
remember
remember
it's
still
a
networking
tool.
G
So
all
these
things
are
full
of
proxies
and
everything
you
have
to
to
take
care.
But
you
are
not
putting
your
application
like
at
a
huge
risk
with
River
service
match.
It's
not
so
simple
as
just
putting
pinning
it
down
and
putting
some
policies
and
off
you
go,
and
production
and
I
think
the
moving
from
nice,
pure
sis
to
the
production
is
something
but
lot
of
people
in
this
room
are
probably
struggling.
A
And
that
leads
to
the
time
for
questions,
and
here
we
have
the
Arduino
and
so
Libby
Clark
has
has
the
mic.
My
question:
first
of
all,
everyone
is
who's
actually
using
service
mesh
in
production.
Right
now
you
raise
your
hand,
ok,
keep
your
hands
raised,
please
who's
testing
it
and
everyone
else
is
kicking
the
tires.
So
if
you
raise
your
hand
you're
using
it
in
production,
you
raise
your
hand
you're
using
it
in
production.
Did
you
tell
us
some
of
the
things
that
you're
finding
we
have
a
Libby
Clark?
I
Yes,
so
our
primary
concern
was
mutual
encryption
between
services
to
ensure
your
address,
basically
within
our
clusters
as
well
as
telemetry.
So
we
have
a
lot
of.
We
are
building
platforms
for
developers
and
product
teams
and
we
cannot
always-
or
we
can't
assume
that
they
have
instrumented
their
applications
in
such
a
way
that
we
know
what's
actually
going
on
and
if
the
cluster
is
working.
So
that
was
our
primary
concerns.
I
A
J
Yeah
we
use
is
TN
production
and
our
main
concern
is
like
stability
of
the
project
itself.
It's
quite
new
and
sometimes
we
see
it's
difficult
to
find
problems
in
the
logs
of
application
and
sometimes
when
things
fail
within
each
tier
itself,
it's
a
big
concern
because
it's
the
main
networking
solution
for
the
whole
application.
So
if
that
fails,
then
everything
fails.
So
it
feels
like
one
sort
of
choke
point
for
for
the
whole,
so.
J
Think
the
main
thing
for
me
was
the
telemetry
like
with
a
lot
of
services.
It's
really
nice
that
you
can
sort
of
get
a
nice
overview
of
everything
and
how
networking
works
on
the
whole
system,
like
with
a
lot
of
teams
working
on
a
lot
of
services.
You
don't
necessarily
know
about
the
whole
application,
and
you
had
a
lot
of
nice.
Visual
solutions.
I'll
show
you
the
whole
network
and
a
lot
more
people
to
get
more
insight
about.
How
does
their
application
work
within
the
system.
H
It's
if
you're
listening
closely,
if
you
can
indeed
may
have
kind
of,
kicked
off
part.
This
is
thread
this.
That
you're
hearing
is.
Is
there
some
softer
things
that
are
enabled
through
service
mesh?
There
is
some
empowerment,
at
least
of
the
two
respondents
here,
I'm
guessing
they're,
probably
more
on
the
platform
team,
a
bit
more
in
operations,
you're
probably
enabled
and
feel
a
sigh
of
relief
when
you
windows,
like
the
blindfold,
comes
off
and
you
get
to
see
what's
happening
within
your
environment
when
you
don't
have
to
rely
on
those
pesky
developers
to
actually
in.
H
I
think
that's
actually
key
and
I'm
written
about
that
in
a
recent
book
that
I
published
it
talks
about
well.
Actually,
if
you
would
ask
this
question,
I
think
speaking
of
being
interactive,
if
we
were
to
say
within
your
environment,
if
you
were
to
think
about
it,
who
is
it
that's
responsible
for
rate
limiting,
you
know,
service
requests
calls
to
your
application
or
who
is
responsible
for
exposing
that
telemetry
who's.
H
A
F
I
mean
one:
one
aspect
is
what
leads
describing,
which
is
the
strength
and
the
weakness
right.
The
fact
that
you
have
this
new
layer
that
now
is
the
bridge
between
the
developers
and
the
platform
teams.
It
is
very
powerful,
but
at
the
same
time,
in
the
absence
of
being
very
well
understood,
then
you
have
the
infrastructure
team,
the
platform
team
and
the
developer
that
they
all
understand
that
Suresh
mesh
has
something
for
them
and
now
who's
going
to
take
the
lead
so
a
lot
of
times.
What
we
see
is.
F
If
you
talk
to
a
team
and
Enterprise
that
they
understand
the
technology,
they
know
what
it
does.
Then
it's
a
very
easy
discussion,
but
when
it's
in
the
early
stages,
the
question
is
who's
going
to
lead
this
discussion,
who's
going
to
own
that
layer,
who's
going
to
operate
the
layer
who
has
expertise
to
understand
a
little
bit
of
what
the
application
developers
are
doing
and
how
the
infrastructure
works,
and
this
is
kind
of
this
platform
teams
I
mean
Floreal-
is
one
example
that
it's
it's
a
scarce
resource.
F
It's
not
that
everybody,
every
single
company
have
those
skills
to
kind
of
cross
layers,
and
if
you
are
stuck
between
a
development
team,
an
infrastructure
team,
then
it
may
be
no-man's
land
and
what
we
thing
is
that,
as
the
level
of
awareness
of
what
the
platform
means,
especially
when
we
get
into
kubernetes
and
cloud
native
increases,
it
becomes
easier.
But
right
now
the
fact
that
this
layer,
as
they
were
saying,
is
kind
of
the
cornerstone
of
talking
to
everybody.
It's
a
problem
by
itself.
F
G
As
a
service
provider,
you
you
often
told
by
the
customer,
we
want
to
service
mesh
and
then
they
want
us
to
operate
the
service
mesh
and
then
they
want
to
have
full
admin
powers
to
do
whatever
we
want
with
it.
So
that's
kind
of
a
conflict
inherent
to
this
and
with
dichotomy
where,
basically,
they
have
full
control,
but
they
still
want
you
to
manage
the
thing.
G
And
typically
have
some
governance
that
they
want
to
put
for
every
project
and
we
give
them
admin
and
they
have
to
do
when
they
are
back
model
and
they
don't
know
how
to
to
accompany
their
own
customers.
Because,
usually
we
speak
to
IT
teams.
We
went
delegate
to
different
two
different
end-users
and
these
people
are
not
necessarily
able
to
understand
or
I,
don't
have
know
how,
after
a
saying
to
properly
separate
and
have
some
common
framework
for
all
the
namespaces
or
what
they
have
so.
A
C
That
the
problem
that
I
see
right
now
is
mainly
the
maturity
of
the
tools,
so
I
mean
there's
a
lot
of
servicemen
out
there.
I
think.
The
reason
there
is
a
lot
of
time
is
that
there's
no
clear
winner,
yet
we
don't
know,
is
the
one
that's
doing
the
best.
What
I'm
very
excited
about
is
is
where
it's
going
to
so
I,
don't
know
if
you
heard
about
what
SEO
is
doing
in
order
to
make
webassembly
working
with
us
do
think
that
will
make
performance
huge
advantage
that
will
make
us
use
it
better.
C
C
Was
announced
by
Microsoft
and
Ashley
and
buoyant
and
us
yesterday
that
was
exactly
the
problem
that
we
try
to
solve
this,
which
API
using
the
difference
between
the
implementation
and
a
lot
of
the
problem
and
like
the
way
to
debug.
It
will
be
a
huge
problem.
I
agree
with
all
those
abstraction
layer,
so
there
is
a
lot
when
we
need
more
to
do,
but
I'm
excited
I
may
be
specifically
with
the
provider.
I
think
that
Ashley
cop
is
doing
a
huge
investment
and
they're
very
well.
I
should
steal
a
table.
Yes,
so.
K
Good
morning
related
to
the
first
question
you
posed
to
the
panel,
so
I
was
talking
yesterday
to
to
somebody
about
how
service
mass,
at
least
partially
came
from
limitation
of
the
classical
tcp/ip
stack
and
what
specifically
layer
one
two
to
four
and
I
was
thinking.
How
would
service
mesh
look
like
if,
for
example,
ipv6
was
ubiquitous,
it
was
a
hundred
percent
adopted
and
we
had
things
like
basically
unlimited
access.
We
had
a
flat
network
for
containers
and
nodes.
We
can
use
their
discovery
protocols,
maybe
multicast
and
other
things
that
ipv6
would
provide.
K
F
Maybe
that's
two
aspects
to
the
question
right.
One
is
if
we
had
ipv6
universe
where
everybody
talks
to
everybody
in
a
flood
wall,
definitely
lots
of
things
could
be
simplified
right
and
you
have
initiatives
like
beyond
Corp
and
things
like
that.
What
we
could
change
the
paradigm.
The
problem
is
always
not.
That
would
be
nice
to
have
something
like
that.
Is
that
today's
enterprises,
they
don't
open
all
the
IP,
addresses
to
the
Internet.
F
They
have
private
IP
address
space,
they
have
firewalls,
they
have
policies,
they
have
perimeters
and
now
the
thing
is
when
we
start
injecting
a
new
technology
like
coordinators
and
putting
it
in
an
enterprise
environment.
You
go
to
a
financial
institution,
and
you
tell
them
yeah.
Don't
worry,
you're
going
to
have
a
coherent
environment
on
Prem.
What
all
your
parts
that
get
dynamically
created
are
going
to
openly
talk
to
services
that
you
have
in
Google
or
Amazon,
or
to
cellphones
connecting
from
any
part
of
the
world
right
and
99.999999%
of
the
enterprise
will
say
our
units.
F
So
what
happens
is
that
we
can
design
and
think
in
terms
of
what
type
of
technologies
could
simplified
infrastructure.
But
the
truth
is
that
we
are
going
to
live
in
a
brownfield
wall
and
we
will
have
to
find
a
way
in
how
to
bring
service
mesh
and
how
to
bring
kubernetes
into
the
existing
enterprise
environments.
And
that's
why,
like
there's
a
lot
of
complexity,
to
connect
an
oracle
database
on
the
heart
of
an
organization
to
a
micro
services
in
a
public
cloud
environment
and
we'll
have
to
continue
to
use
new
tools
and
old
tools.
F
H
You
know,
like
I,
said,
there's
a
very
long
tail
of
IT.
It's
a
lot
of
psychological
barriers
to
overcome
as
well
outside
of
grokking
technology,
and
you
know
bringing
forth
new
technology
and
adopting
that
there's,
there's
some
identities
and
the
roles
and
responsibilities
it
shift
it
around
people
get
concerned,
but
to
the
question
that
might
win
an
Arduino
which
you
don't
have
a
question
later.
H
Example,
running
around
would
be
great,
I
think
that
my
direct
answer
if
the
world
was
ipv6,
that
you'd
probably
find
that
a
service
matched
is
critically
needed,
that
you
did,
you
really
need
fine-grained
traffic
control,
the
the
endpoint
itself,
all
the
way
to
the
to
that
service
itself,
security,
identity,
the
rotation
of
certificates,
that
visibility
becomes
even
even
more
of
a
need.
I
think
that
you'd
find
service
measures
would
be
very
prominently
needed
in
that
case,
and.
D
F
Work
in
security
in
my
purse
right,
so
you
have
things
like
Spector
and
Mel
down
and
attacks
that,
even
if
you
have
service
match,
they
will
not
be
contained.
So
that's
why,
when
you
think
in
terms
of
security,
even
if
on
any
realistic
way,
a
new
technology
could
address
all
the
connectivity
and
security
problems
you
may
have,
because
certain
vulnerable
components
of
your
infrastructure,
you
may
always
have
to
resort
to
multiple
layers
of
security,
even
if
they
are
inconvenient,
because
there's
a
trade-off
that
you
have
to
have.
E
Question
yeah
good
morning:
all
my
question
is
to
pair
man,
clothes
I,
see
when
we
bring
programming
abilities
to
the
network
layer
in
the
services.
Already
I
see
lot
of
complexities.
Example
in
SXT,
nsx
V.
So
for
the
new
people
it
adds
more
complex.
So
is
there
a
way
we
can
simplify
the
serviceability
in
the
networking
layer.
A
F
Yes,
so
an
NSX
is
an
SDN
layer,
a
network
virtualization
layer
that
offers
you
distributed
switching
distributed
routing,
but
balancing
firewalls
and
so
on.
When
you
go
with
the
servicemen's
level,
now
you
have
a
new
set
of
controls
and
what
we
are
doing
is
how
to
align
the
policy
from
one
layer
to
the
next,
in
a
way
that
imagine
that
you
have
micro
segmentation
policy
at
layer.
F
4
should
not
contradict
what
you
are
putting
at
the
layer
7
with
a
service
mesh,
and
then
you
have
things
like
ingress,
egress
invoice
that
they
may
have
to
be
tainted
by
the
micro
segmentation
groups
of
the
layer
4,
because
otherwise
you
may
have
conflicting
policies.
So
what
we
are
doing
is
align
the
different
layers
in
terms
of
groups
in
terms
of
identities
in
terms
of
policies,
in
a
way
that
the
operational
model
is
is
consistent
between
the
multiple
layoffs.
B
Yeah
and
what
I'd
like
to
add
to
that
is,
as
we
move
up
the
layers,
we
have
to
make
sure
that
one
layer
is
in
each
layer
is
independent,
so
we
can
change
at
say
a
layer,
6
or
a
layer
7
and
have
the
freedom
for
the
application
developer
to
set
the
policies
they
need
at
the
application
layer
and
have
that
filter
down,
and
each
layer
should
also
be
removable
and
changeable
as
needed,
so
that,
as
we
can
make
changes
at
one
layer,
what
are
impacting
all
layers.
So
we
don't
have
an
integrated
stack.
B
We
have
the
ability
to
manage
the
system
overall
and
at
different
levels,
so
the
IT
individual
for
the
shared
part
of
the
infrastructure,
because
you
will
have
to
have
shared
infrastructure
to
go
across
cloud
to
even
grow
between
developers.
You
can't
have
ones
you're
not
going
to
be
able
to
have
just
one
type
of
service
mesh
I
mean
all
those
flexibilities
to
make
it
work
are.
A
M
C
I
mean
it's
another
abstraction,
which
is
always
a
problem
right,
it's
another
abstraction.
Before
that
you
had
a
problem
of
how
do
you
debug?
You
know
when
you
have
a
boy
and
your
steel,
and
now
you
have
a
semi
as
well,
so
this
adapter
is
costing
you
I,
think
the
adventure
that
I
see
with
us
and
III
I
came
with
this
idea.
It's
because,
if
you
think
about
it
right
now
as
an
organization,
in
my
opinion,
you
will
need
to
run
more
than
one
mesh,
because
you
don't
know
right.
C
When
we
talk
to
our
customer,
they
were
you
know
they
were
debating
and
therefore
they
were
trying
with
a
lot
of
type
of
service
mesh.
They
needed
to
learn
a
new
API.
You
need
to
start
operating
with
that.
They
need
to
investigate
that.
That's
took
quite
a
lot
of
time
and,
second
of
all,
they
also
wasn't
clear
about
which
one
to
choose
and
what,
if
them
choose
linker
D,
but
then,
as
here
is
the
winner,
so
that's
it.
C
So
the
point
is
that
that
way,
you
can
actually
swap
the
implementation
behind
the
same,
but
didn't
change
the
layer.
On
top
of
it,
so
that
every
abstraction
layer
me
specifically
the
reason
I
was
very
engaged
with.
That
is
because,
as
I
said
in
organization,
you
will
have
more,
at
least
you
know,
maybe
the
same
type.
Maybe
you
will
use
a
steel.
You
will
use
more
than
one
instance
of
Sto
right
because
you
have
more
cluster.
This
is
where
we're
going
with
right.
C
We
don't
want
one
big
cluster
multi-tenant,
we
kind
of
like
one,
a
small
one
and
guess
what
each
of
them
will
need
an
service
match
that
you
will
need
to
manage
that
you
will
maybe
will
be
different
version.
Maybe
you
have
different
organization
in
your
inside
your
company
to
choose
different
service
match,
and
maybe
you
want
to
go
to
AWS,
and
you
know
what?
If
so,
you
need
to
use
up
mesh
because
it's
free
and
it's
integrated
with
everything
you
have
there
so
now.
The
question
is:
how
do
you
actually
manage
that?
C
And
this
is
an
orchestration
problem,
and
this
is
where
I
think
we're
going
with
a
semi.
So
we
have
a
product
super
glue
that
Asuma
is
basically
based
on
and
basically
what
it's
doing
is
exactly.
This
is
manage
its
discovering
every
service,
much
that
you
have
it's
installing
them
and
then
it's
basically
grouping
them.
I.
Have
this
service
mentioned
this
service
special,
want
to
group
them
and
use
the
same
primitives
the
same
as
certificate,
and
for
that
you
need
that
layer.
C
This
is
a
use
case
that
we
couldn't
do
before
right,
so
I
think
the
ability
to
do
that
kind
of
of
this
or
chaos
engineering
right.
This
is
another
thing
that
you
probably
make
more
sense
on
the
level
of
the
proxy
than
actually
embedded
it
in
your
code,
so
I
think
there's
so
much
stuff.
We
can
do
right
now,
as
a
community.
You
saw
yesterday
flogger
and
others
and
I
think
that's
where
it
would
be
very
interesting.
What
is
the
use
case
that
you,
as
a
company,
wanted
to
create
yeah.
H
There
really
is
so
much
more
than
kind
of
the
the
three
component.
Yeah
use
cases
that
are
prominently
talked
about
about
service
meshes,
ad-din
team
are
exploring
and
providing
for
some
of
those
there
are
even
more
I
would
expect
to
come
forth.
The
nice
thing
about
SMI
back
to
your
question
is
that
well,
it
facilitates
a
few
things.
Maybe
some
common
nomenclature
across
service
meshes
such
that
we
can
have
more
easier
conversations
without
a
bunch
of
caveats.
We're
not
confused
about
what
we
mean
when
we
say
a
certain
term,
that's
kind
of
nice.
H
It
also
helps
vendors
and
users.
Refine
the
core
use
cases
refine
the
specification
about
how
how
we
generally,
we
collectively
would
generally
like
to
interact
with
service
messages
and
speak
to
them
and
control
them.
So
calm,
spec,
really
when
you
think
about
a
common
spec,
a
common
API,
there's
very
close
sibling
examples
of
these.
H
So,
if
you're
familiar
with
container
with
CNI
container
net
networking
interface,
CRI
container,
runtime
interface,
CSI,
container
storage
interface,
unfortunately
it's
not
a
C,
but
it's
an
S
in
my
service
master
interface,
similar
in
is
to
Genesis
and
reasoning
and
what
it
hopes
to
bring
forth
right.
You.
L
E
H
A
D
F
Ambu
is
continuously
improving
in
terms
of
what
type
of
protocols
is
supporting,
so
you
have
from
HTTP
RPC
is,
but
the
notion
of
Kafka
and
understanding
other
protocols
is
continuously
increasing
and
now,
with
web
assembly,
you'll
be
able
to
even
define
more
capabilities.
On
top
of
that.
So
the
idea
is
that
it's
not
just
for
HTTP
or
G
RPC
is,
as
time
goes
and
as
webassembly
matures
a
set
of
new
plugins
are
going
to
emerge.
F
We
did
some
things
in
VMware
with
MySQL
and
some
of
the
data
elements
of
how
to
start
understanding
data
objects
in
order
to
apply
policy.
Kafka
topics
is
another
element
that
we
are
looking
in
terms
of
applying
policies.
So
all
the
stretch
protocols
I
see
that
is
just
a
matter
of
time-
that
the
mess
was
understanding
natively.
All
those
capabilities.
C
A
Have
a
question
about
security
and
I'd
like
to
ask
this:
you
know
what
we're
seeing
with
you
know
the
evolution
of
container
technologies,
really
this
ability
to
share
and
on
a
level
that
we
didn't
have
before
right.
There's
this
there's
this
portability,
that's
that
provide
that
is
provided
with
it
recently.
You
know
the
docker
hub
was
attacked
and
then
190,000
accounts
were
compromised
and
it's
raising
a
lot
of
questions
about.
You
know
the
security
and
the
whole
entire
software
supply
chain.
F
It's
not
service
massive
problem.
Only
I
mean
it's
the
notion
that
security
has
to
be
tight
through
all
the
stages
from
the
production
of
the
code
to
the
deployment
of
the
code
to
the
runtime
of
the
code,
and
now
a
lot
of
energy
is
going
to
the
notion
of
detecting
behaviors
in
the
runtime
environment,
but
correlating
it
to
change
management
or
correlating
it
to
new
artifacts,
and
if
you
detect
a
behavior
that
doesn't
match
what
you
had
in
in
the
production
of
the
code
or
in
the
deployment
and
stop
it
put
it
in
quarantine
whatever.
F
But
it's
this
notion
that
security
is
going
from
the
notion
of
saying:
oh,
a
firewall
will
stop
it
or
a
service
mesh
will
stop
it
or
whatever
it
is,
will
stop.
It
can
I
tracked
all
the
stages
of
the
lifecycle
of
an
application
and
make
sure
that
there's
no
compromise
in
any
of
the
stages
and
be
able
to
correlate
across
the
stages.
So
there's
a
lot
going
on
in
that
direction.
I.
A
Would
actually
wanted
to
ask
a
quick
question,
a
cliff
when,
when
you
were
talking
earlier,
you
know
before
the
before
the
panel
about
what
went
wrong.
You
know
not
necessary
what
went
wrong.
Is
you
know
back
in
the
game,
we
were
think
you
know
virtualization
and
kind
of
the
evolution
of
virtualization
and
what?
What
are
the?
What
are?
What
are
you
seeing
is
like
the
parallels
that
we
can
that
we
can
learn
from
today
as
we're
moving
forward
with
service
Matt
sure.
B
B
All
I
saw
was
a
performance
hit
and
that
that's
something
that
we
we
don't
want
to
repeat
going
forward,
and
one
of
the
ways
that
we
could
see
it
repeated
here
is
that
when
a
vendor
produces
piece
of
production
software,
what
we
see
bundled
in
is,
for
example,
what
if
someone
bundled
in
a
service
matched
with
their
code
shipped
it.
That
means
now,
all
of
a
sudden.
You
have
another
monolithic,
sighs,
oh,
that
you
have
to
deal
with.
We
haven't
we're
not
able
to
get
any
of
the
benefits.
B
What
we
look
for
when
we
have
applications
manages
hundreds
of
small
pieces
and
it
would
be
very
natural
for
people
who
haven't
changed
their
culture
change
their
thinking
to
do
that,
and
so
I
think
that's
a
danger
that
we
want
to
avoid.
That's
an
example
of
how
this
might
ease
some
something
we
don't
want
to
see
carried
over
easily
be
carried
over.
N
A
good
money
I
want
to
ask
about
the
service
mass
with
the
with
the
topic
of
the
inter
cloud.
One
because,
like
our
business,
is
running
24
hours
and
globally,
and
we
don't
want
to
depend
on
only
a
single
service
provider
or
cloud
provider.
How
service
mask
can
play
a
role
or
solve
the
problem
of
the
inter
cloud.
One
because
actually
at
the
moment,
is
the
pain
for
our
business.
In
order
to
to
have
it
so
working
seamlessly.
H
In
a
very
simple
way,
service
measures
can
facilitate
cross
cloud
overlays,
maybe
that's
the
most
concise
way
of
speaking
to
that
I.
Think
the
question
about
service
manager,
interface
and
kind
of
a
standard
interface
for
interacting
can
also
to
the
extent
that
those
cloud
service
providers
implement
that
or
are
friendly
to
that
specification.
That
can
also
help
facilitate.
D
F
F
Next,
what
having
a
mesh
that
federates
between
an
on-prem
environment
and
a
cloud
environment
providing
you
and
then
to
an
identity
view
of
the
problem
and
doing
service
analytics
and
traffic,
routing
and
everything,
and
to
end
so
I
think
this
is
the
area
that
it's
going
to
evolve
a
lot
I
mean,
if
you
think,
in
the
networking
layer
we
had
say
IP
connectivity,
but
then
we
have
to
introduce
not
and
firewalls
and
ipv6
and
ipv4,
and
so
on.
Right.
When
you
go
to
the
service
mesh
level.
F
Now
you
have
identity
providers
with
certificate
authorities
and
now
you're
going
to
have
multiple
kubernetes
environments
or
multiple
services
across
multiple
clouds.
So
the
question
is:
how
do
you
federated
entity?
How
do
you
have
a
set
of
policies
that,
if
you
have
services
in
a
public
cloud
and
services
in
on-prem,
you
may
not
want
to
accept
all
the
services
that
you
have
on
Prem
to
the
public
cloud,
because
you
don't
want
the
public
cloud
to
have
a
full
view
of
what
you
have
in
your
enterprise.
F
So
now
it
becomes
granular
control
of
servicemen's,
Federation,
understanding
what
identities
are
going
to
be
seen
and
what
identities
can
talk
to
the
other
side.
So
this
is
what
we
call
kind
of
global
namespaces
if
you
control
both
messes
or
Federation
of
service
messages,
if
you
don't
control
the
other
side,
but
that's
an
area
that
it's
evolving
quite
fast,
because
it's
a
valid
use
case
from
from
an
enterprise
point
of
view.
G
And
of
interest
as
well
I
mean
for
Federation
of
service.
Mesh
is,
if
you
have
an
intelligence
environment,
not
necessarily
only
kubernetes
clusters,
because
you
can
install
a
service
mission,
also
different
environment
service
work
for
Cloud
Foundry
or
going
on
other
sort
of
software.
So
many
enterprise
have
grown,
organic
I
mean
have
software
grown
organically
and
it
helps
bridge
and
put
some
common
policy
of
a
multiple
resources.
You
have.
Some
is
some
platform,
other
service
and
kubernetes
clusters,
and
also
big
something
which
can
really
help
yeah.
B
And
I
just
wanted
to
mention
that
maybe
some
people
in
the
room
aren't
sure
how
widespread
the
use
of
hybrid
or
multi
cloud
is
and
from
our
research
on
average
we're
already
getting
information
from
enterprises
that
they're
using
10
different
cloud
service
providers
for
infrastructure.
So
that's
it's
a
pretty
widespread
issue.
So
thank
you
for
raising
that
rain.