►
Description
Join Frederick Kautz and Ed Warnicke, maintainers of Network Service Mesh for an AMA!
Network Service Mesh is a community-driven CNCF Sandbox project that simplifies connectivity between workloads, independent of where they are running. It extends IP reachability domains to workloads running in multiple clusters, legacy environments, on-premises, or in a public cloud, communicating with the protocols they are currently using.
NSM does this at the granularity of individual workloads. Your workloads have connectivity to only the workloads they need, with just the service from the network they want – nothing more, nothing less. NSM brings the useful features of a Service Mesh from the lofty heights of HTTP down to IP itself. Applications and the Application Service Meshes, such as Istio, run on top, leaving the hybrid/multi-cloud IP connectivity to NSM.
A
A
Tell
us
a
little
bit
about
the
road
map
what's
going
on
in
that
community
and
then
we'll
have
time
at
the
end
for
q
a
so
as
we're
going
through
this.
It's
live
streamed
wherever
you
are,
facebook,
twitch
youtube
live
or
in
bluejeans
with
us
here
type
your
questions
into
the
chat
and
we
will
relay
them
to
the
our
guest
speakers
today
and
so
without
any
further
ado,
ed
and
fred.
B
Community
sure
so
I'm
my
name
is
ed
warnicky,
I'm
one
of
the
founding
committers
on
the
network
service,
mesh
project,
it's
a
cncf,
sandbox
project
and
just
sort
of
by
way
of
general
housekeeping-
and
I
say
this
all
the
time
and
frederick's
is
quite
used
to
it.
Please
feel
free
to
ask
questions
as
we
go,
because
if
there's
a
question
that
occurs
to
you,
while
we're
going
through
sort
of
the
brief
introductory
slides,
then
it'll
probably
occur
to
other
people,
and
since
this
this
is
an
ama.
B
C
So
from
a
housekeeping
perspective,
we
have
network
service
message
at
io
as
our
main
website.
We
will
post
the
the
link
to
these
slides
on
we'll
make
sure
that
that
they
get
posted
in
the
openshift
commons
place
and
where,
wherever
those
slides
tend
to
tend
to
be
stored.
So
people
can
gain
access
to
these
and
we
also
have
a
longer
form
of
these
slides
in
the
form
of
a
in
the
form
of
a
webinar.
C
So
in
terms
of
venous
nsm
vision
we're
going
to
we're
going
to
go
over
three
particular
areas,
so
one
of
them
are
some
of
the
problems
we're
trying
to
solve,
and
this
is
not
a
exhaustive
list
of
all
the
problems.
This
is
just
one
set
of
problems
that
we
think
will
be
useful
to
the
audience
that
is
here.
C
The
first
concept
is,
if
you
think,
of
kubernetes,
think
of
kubernetes
as
a
runtime
domain,
you
it's
your
it's
a
domain,
that
you
run
your
your
pods
in
your
your
computing
and
in
with
every
kubernetes
runtime
domain.
There
is
a
connectivity
domain
associated
to
it.
This
this
connectivity
domain
from
the
perspective
of
kubernetes
is
pure
layer.
Three,
you
will,
you
will
not
see
mac
addresses
in
any
of
the
kubernetes
tooling
or
any
any
of
the
northbound
apis
that
they
expose.
C
You
will
see
service
discovery
and
routing
which
is
typically
handled
through
dns,
and
you
will
see
isolation
through
the
form
of
kubernetes
network
policies,
you're
thinking
of
like
ingress
policies,
egress
policies,
you'll
see
services
and
where
they,
where
they
land,
you
optionally,
you'll,
often
see
a
layer,
7
service
mesh,
an
application
service
mesh
which
istio
linker
d
and
similar
are
great
examples
and
connectivity.
The
connectivity
of
domain
within
kubernetes,
even
though
there's
a
lot
of
flexibility
in
the
definition.
C
The
most
common
trend
that
you
see
is
intra
cluster,
in
other
words
pod
to
pod
app
to
app
or
you
can
have
something
that
handles
your
ingress
to
your
to
your
pod,
and
so
on.
That
doesn't
mean
that
doesn't
mean
that
there
is
no
external
connectivity,
but
for
the
purposes
of
the
connectivity
domain
itself
that
it
tends
to
focus
on
what's
within
the
cluster.
B
And
so
these
these
two
things
are
sort
of
important
to
think
about
as
we
move
forward
through
the
world.
So
one
of
the
hallmarks
of
cloud
native
is
that,
more
than
anything,
it's
a
rethinking
of
problems
as
we
progressively
virtualize
the
world.
One
of
the
things
that
we've
realized
is
that
we've
unnecessarily
brought
along
physical
constraints
that
were
true
about
the
physical
devices
servers
networks
that
we
all
started
with
in
the
late
90s,
and
that
often
these
end
up
being
simple
boat
anchors.
They
actually
don't
serve
us.
B
They
actually
hinder
our
ability
to
solve
our
problems,
and
so
the
history
of
cloud
native
is
the
history
of
stopping
to
rethink
these
things,
and
one
of
these
physical
artifacts
has
always
been
that
your
runtime
domain,
in
other
words,
where
your
workload
is
running,
is
connected
to
precisely
one
connectivity
domain.
Originally
back
in
the
90s.
It
was
your
physical
networking,
your
data
center,
and
that,
even
though
that
there
may
be
a
bunch
of
different
nerd
knobs
that
could
be
termed
it
was
precisely
one
connectivity
domain
that
had
precisely
one
set
of
things
on
offer.
C
So
when
we
start
to
think
about
these
particular
these
particular
domains,
and
so
when
we
start-
and
we
start
to
spin
up
multiple
clusters,
so
because
we
have
this
the
style
of
thinking
where
every
container
every
kubernetes
or
say
your
your
runtime
domain,
is
directly
attached
and
has
the
exact
same
shape
as
your
as
your
networking
domain
within
cluster.
When
we
spin
up
multiple
clusters,
we
get
something
that
looks
like
this
diagram
on
the
right
like
each.
C
C
And
so
what
ends
up
happening
is
when
we
start
to
connect
when
we
start
to
talk
about
connecting
the
workloads
and
do
other
workloads,
we
think
we
tend
to
think
of
it
as
as
a
community
about
connecting
the
networking
domain
with
each
other,
like
let's,
let's
see
we'll
start,
taking
a
look
at
inter-cluster
workload,
isolation!
So
we'll
have
these
four
clusters
and
how
do
we?
How
do
we
set
up
these
networks
so
that
they're
capable
of
communicating
each
other?
C
B
And
so
the
intra
cluster
thing
is
the
first
natural
thing
that
comes
to
mind
for
people
that
are
doing
clustered
cluster
networking,
because
that's
how
we
handle
the
physical
data
centers,
but
as
frederick
sort
of
played
it
out.
It
has
a
number
of
problems,
not
the
least
of
which
is
that
I'm
going
to
make
a
very
bold
statement.
Nobody
actually
wants
two
clusters
to
talk
to
each
other.
C
You
have
times
the
number
of
nodes
you
have
minus
one
then
divide
that
by
two
and
that's
the
total
number
of
links
that
you
potentially
can
have
between
these
between
these
type
of
systems,
and
so
so,
if
you're
only
setting
up
two
or
three
systems,
it's
not
a
big
deal.
If
you're
setting
up
30
of
these
things,
40
of
these
things
and
they
have
to
communicate
each
other
across
multiple
clouds,
multiple
regions,
then
it
becomes
a
huge
problem
and.
B
C
Absolutely
and
then,
and
then
you
also
have
to
work
about
how
do
you
actually
configure
these
things
like
who's,
going
to
set
up
the
the
links?
How
are
you
going
to?
How
are
you
going
to
organize
the
this
information?
There
still
has
to
be
rules
between
them
and
how
to
on
how
to
prevent
them
from
communicating
with
each
other
in
ways
you
don't
want
them
to
so
then,
the
the
firewall
rules
that
they
get
attached
to
that
can
become
incredibly
complex
and
people
are
bringing
in
things
like
layer.
C
Seven
service
meshes
to
try
to
deal
with
some
of
these
things,
but
you
still
end
up
with
a
problem
of
application
gateways
that
you
have
to
go
and
configure
each
each
one
and
set
them
up.
You
still
have
the
problem
of
having
to
synchronize
all
of
the
state
between
every
every
system.
That's
that's
there
and
you
still
have
the
problem
of
of
identity
between
them.
C
How
do
you,
how
do
you
work
out
the
identity
of
the
things
that
you're
that
you're
communicating
with
which
is
beyond
the
scope
of
where
we're
gonna
talk
in
this
scenario?
But
it's
it's
there's,
there's
a
lot
of
complexity
that
comes
in
that's
hidden
that
comes
beyond
just.
We
just
want
to
hook
these
things
up
when,
at
with,
with
the
with
a
networking
in
a
networking
layer.
C
And,
of
course,
service
discovery
and
and
routing
between
them
like
how
do
you,
how
do
you
even
set
up
the
the
discovery,
and
how
do
you
set
up
the?
How
do
you
route
between
pods
or
between
between
the
systems,
so
what
we,
what
we
effectively
are
getting
when
we
try
to
take
this
approach,
is
where
we're
seeing
basically,
the
the
the
network
domain
trying
to
be
spread
across
all
systems
in
in
an
equal
way,
and
so
this
is.
C
This
is
where,
when
you
start
talking
about
about
federated
multiple
clusters,
one
of
the
problems
that
you
have
with
this
you're
saying,
let's
bring
in
a
single
stn
and
we'll
have
it
on
everything.
That's
in
there
and
seo
will
deal
with
everything.
That's
that's
there,
but
you
still
have
you
you've
automated
some
of
the
combinatorics
work
that
goes
on,
but
you
still
have
an
explosion
in
state
and
eventually
that
sdn
is
eventually
going
to
hit
its
its
limits,
and
you
still
have
problems
with.
C
B
One
one
very
simple
way
to
see
where
the
federation
on
solution
will
start
to
break
down
is,
if
you
look
at
the
scaling
of
kubernetes
itself
right,
so
kubernetes
effectively
keeps
a
small
set
of
very
simple,
mostly
red,
seldom
written
two
objects
in
the
api
server
things
you're
like
your
crds,
your
pod,
specs,
your
surface,
specs,
etc,
but
even
there
kubernetes
technically,
I
think.
Last
time
I
checked
the
stated
limit
of
the
size
of
a
cluster
was
5
000
nodes
and
long
before
you
get
to
that
point.
B
Things
start
to
get
creaky
and
it's
primarily
because
of
the
scope
and
the
change
velocity
of
the
state
in
your
api
servers
and
that's
about
as
good
as
it's
ever
going
to
get
guys,
because
those
api
servers
tend
to
be
located
in
a
single
cluster
where
everything
is
at
low
latency
to
each
other.
When
you
start
playing
the
federation
game
effectively,
the
simple
way
to
think
about
it
is
you're,
taking
the
same
sort
of
game
that
you
played
in
a
single
cluster
of
basic
of
centralizing.
B
Some
state
and
you're
blowing
the
combinatronics
up
beyond
the
scale
at
which
your
cluster
is
normally
breaking
down
and
you're,
making
the
problem
worse
by
introducing
greater
latency,
greater
partition
potential
et
cetera,
because
you've
got
clusters
potentially
running
across
the
land
from
each
other.
And
so
it's
not
at
all
surprising
that
trying
to
federate
in
this
way
faces
very
significant
challenges.
B
And
it's
because
it's
taking
something
that
was
extraordinarily
well
designed
at
the
scale
of
that
cluster
scale
and
extraordinarily
well,
designed
for
an
environment
of
low
latency
within
within
a
single
cluster.
And
it's
trying
to
project
to
something
at
much
larger
scales
than
it
was
ever
designed
for
with
much
much
worse,
latency
impacts
than
it
was
ever
designed
for
and
and
so
effectively.
C
So
yeah
and
this
complexity
gets
even
worse,
like
once,
we
start
to
add
in
other
types
of
compute
domains,
such
as
virtual
machines,
which
run
on
systems
like
like
neutron,
or
we
bring
in
on-premise
servers
that
may
not
have
kubernetes
installed
on
them.
They
may
be
running
top
of
rack
switches
or
other
types
of
of
hardware
that
provides
networking
that
you,
you
may
need
to
to
integrate
with.
C
B
It's
very
much
a
semantics
problem.
It
turns
out.
Every
connectivity
domain
has
a
certain
semantics
to
it.
It's
how
it
thinks
about
how
workloads
communicate
with
each
other
and
the
way
that
kubernetes
thinks
about
workload.
Communication
with
you
know
basic
l3
communication
at
pure
l3,
with
network
policies
with
services
et
cetera.
B
That's
one
way
of
thinking
about
inter
cluster,
about
connectivity.
The
way
you
traditionally
would
think
about
things
in
terms
of
you
know
land.
You
know
in
terms
of
l2
subnets,
you
know,
and
that
sort
of
stuff
and
security
groups
and
everything
else
in
a
virtual
network
with
vms
is
a
different
way,
and
then
every
data
center
has
an
entirely
bespoke
set
of
semantics
about
the
various
nerd
knobs
and
how
it's
basically
built
out,
how
it
thinks
about
communication
between
workloads
and
these.
These
are
sets
of
semantics.
C
You
still
have
problems
with
the
full
mesh
combinators
like
what
are
you
going
to
expose?
How
are
you
going
to
manage
the
state?
How
are
you
going
to
push
them
push
them
around,
and
you
still
have
the
same
manual
cluster
that
and
link
setups
that
between
every
different
types
of
cloud
provider
that
that
exists
and
and
including
the
complex
firewall
rules
that
that
you
still
have
to
set
up
between
them
and
so
the
the
biggest
problem
as
well
that
this
that
this
makes
tying
it
to
the
l7
and
not
l3.
C
Is
that
it's
it's
making
the
assumption
that
every
single
one
of
these
systems
already
has
an
underlay
setup
and
what
we
mean
by
an
underlay
is
you
can
think
of
these
types
of
connections
as
being
an
overlay,
an
overlay
network?
It's
a
network
that
sits
on
top
of
another
network,
even
if
it's,
even
if
it's
a
type
of
system
that
is
they're,
doing
tls
connections
and
tunneling
through
that
you
can
still
see
that
as
an
overlay.
C
So
if
I
asked
you
to
hey
hook
up
azure
and
aws,
then
they're
not
immediately
going
to
be
able
to
start
talking
with
each
other
until
you've
done
some
initial
setup
work
in
order
to
get
them
to
start
to
communicate
with
each
other.
So
there's
you
still
have
that
underlying
l2
l3
problem,
even
when
you
bring
an
l7
mesh
on
top
of
it
same,
goes
with
on-prem.
C
You
end
up
having
to
set
up
your
your
vpns
or
your
or
your
peering,
with
with
aws,
google
and
azure,
or
you
hook
onto
google
and
and
so
on.
So
it's
the
same.
It's
the
same
problem
and
they
can
help
you
with
managing
some
of
the
discovery
issues
that
that
appear
at
the
top.
But
you
still
have
that
you
still
have
that
core
problem
that
sits
underneath.
C
So
what
do
we
mean
by
connectivity
and
domain
independence?
Is
that
we
is?
We
have
to
look
at?
What
is
it
that
we
really
care
about?
Do
we
really
care
that
the
kubernetes
networking
itself
is
capable
to
talk
to
a
to
the
other
to
the
other
networks,
or
do
we
care
about
the
capability
of
the
pod
to
communicate
with
another
pod
or
a
workload,
to
communicate
with
another
workload
like
whether
it
ends
whether
it
ends
up
how
this
gets
rendered,
what
it
could
be
through
kubernetes
networking
whether
it
gets
ran
through
something
else?
C
And
so
the
solution
that
we
were,
that
we're
aiming
for
and
that
we've
and
that
we've
developed
towards
this
is
to
leave
inter-clustered
networking
alone
integra
the
intracluster
intra-cluster
networking
alone.
Rather
so,
the
intracluster
networking
itself
is
fantastically
well
done
as
long
as
you
have
as
long
as
you're
staying
within
a
single
kubernetes
cluster.
It's
a
very
well
solved
problem,
so
we
don't
want
to
break
that,
but
at
the
same
time
we
want
to
be
able
to
enable
communication
between
clusters
and
while
at
the
same
time,
being
harmless
to
existing
kubernetes
networking.
B
C
So
the
next
step
after
that
is
that
we
want
to
then
create
a
a
connectivity
domain
that
is
not
welded
to
any
given
to
any
given
cluster,
but
instead
is
one
that
where
we
can
hook
up
specific
workloads
to
a
specific
connectivity
domain.
So
perhaps
we
have
a
database
replication.
Let's
say
that
you
have
like
usabit
test
as
an
example.
Maybe
you
have
a
test
on
each
of
these
pods
and
you
want
to
perform
some
form
of
replication
between
them.
C
C
It
all
allows
you
to
to
avoid
co-mingling
your
your
connectivity
domains
and
such
so
that,
like
your
replication
data
is
not
traversing
over
istio
or
vice
versa,
which
means
that
not
only
does
this
get
certain
security
properties
that
they
get
enabled,
but
also
you
could
give
it
a
different
performance
treatment.
You
can
give
it
different,
latency
or
throughput
requirements.
B
B
everybody
can
talk
to
everybody
over
ip
together
with
basic
admission
controls,
so
only
your
databases
that
should
be
replicating
are
allowed
to
connect
to
it,
and
you
can
make
that
that
scope
of
semantics
as
precisely
matching
needs
of
your
workloads
as
you
need,
and
the
scope
of
admission
as
narrow,
as
makes
sense
for
the
problem
you're
trying
to
solve
an
enormous
amount
of
the
complexity
that
we
produce
in
networks.
Around
security
has
to
do
with
the
fact
that
you've
got
many.
B
Many
many
many
many
many
things
with
disparate
needs,
disparate
security
characteristics,
etc,
participating
in
a
single
connectivity
domain.
And
then
you
have
to
bring
very
complicated
policies
to
manage
that.
If
you
could
instead
just
say,
look
the
only
things
here
are
stuff
doing.
Database
replication
and
the
only
things
that
we
have
to
provide
to
them
are
network
features
of
a
network
service
and
semantics
that
help
with
database
replication.
B
That
makes
the
world
enormously
simpler
to
work
with,
but
it
also
means
that
you
can
simply
say:
hey
we're
going
to
let
the
guys
who
are
managing
the
databases
twist.
What
very
small
number
of
nerd
knobs
there
are
for
the
database
replication
network
service
because
it's
their
workload
and
if
they
you
know
they
can
manage
that
themselves
and
if
they
do
something,
it's
not
going
to
score
for
everybody
else's
workloads.
You
can
give
them
administrative
independence.
C
So
and
then,
when
we
start
to
look
at
bringing
in
other
types
of
virtual
networking
domains
such
as
your
vms
or
your
on-premise
servers,
then
by
separating
separating
these
out,
it
also
reduces
the
chances
like
you,
don't
have
to
deconflict
the
entire
world
like
you're,
not
you're,
not
starting
with
with
global
state.
What
you're,
starting
with
is,
is
local
state
such
as
database
replication.
C
This
should
look
very
similar
to
the
to
the
first
non-solution
that
we
described
your
trusted
network
connected
to
another
trusted
net
trusted
network
in
the
scenario
you'll
be
kubernetes
with
pods
in
them
which
are
workloads,
and
then
you
hook
up
some
form
of
a
tunnel
or
vpn
between
them
and
the
way
you
defend
them.
Is
you
stick
firewall
rules
and
access
control
list
and
so
on
on
the
perimeter,
which
then
defines
how
they
can
communicate
with
each
other
and
kubernetes
takes
us
a
bit
further.
C
It
also
means
that
you
can
apply
your
policy
not
at
the
ip
level.
Instead
of
saying
you
know,
these
ips
are
allowed
to
talk
to
these
ips.
Instead,
you
can
say
these
workloads
with
these
cryptographic
identities
the
their
the
the
api
gateways
might
have
a
specific
identity
in
order
to
connect
to
a
backend
api
like
like
a
payment
gateway
or
so
on,
you
can
give
them.
C
You
can
give
them
identities
that
you
can
then
reason
about
so
when
you're
scaling
kubernetes
and
you
decide
to
scale
it
out
horizontally
or
you
or
you
reduce
the
size
of
your
scale.
Even
if
you
have
them
in
separate
clusters
and
they're
communicating
with
each
other,
you
can
still
establish
the
secure
connection.
C
But
it
severely
limits
the
type
of
thing
that
an
attacker
can
do
where
they
break
into
the
workload
and
they
decide.
Oh,
I'm
gonna
do
a
scan
for
open
databases,
it's
like
you
if
they
don't
have
a
policy
that
allows
those
databases
to
connect,
then
they're
not
gaining
they're,
not
gaining
access
to
that
database
because
they
won't
be
able
to
connect
to
that
database
and
so
and
in
short,
the
the
identity
part
looks
similar
to
this.
C
You
have
a
ca
at
the
top
that
attests
and
gives
identities
to
applications
to
your
to
your
workloads.
Let's
say
like
an
application
service
or
a
database
service,
and
then
you
can,
then
you
can
perform
that
policy
on
top
of
it
once
once
they
receive
these
these
identities
and
so
in
in
the
case
of
network
service
mesh.
C
When
we
start
talking
about
these
things
like
say
suppose
that
the
service
you
want
to
connect
to
similar
to
maybe
application
ones
connect
to
a
database,
you
have
you
have
an
app
that
wants
to
connect
to
a
secure
corporate
internet.
It
is
a
it
is
a
network
service,
and
so
when,
as
as
the
app
developer,
you
don't
want
to
you
don't
want
to
have
to
worry
about
what
segment
am
I
connected
to?
How
do
I
set
up
the
interface?
How
do
I
set
up
the
routes?
How
do
I
set
up?
C
C
The
operator,
however,
may
have
a
requirement
on
on
what
does
it
mean
to
connect
to,
in
this
case,
secure
corporate
internet,
so
the
the
operator
might
say
well
in
order
to
connect
to
this,
we
want
by
policy.
We
want
you
to
connect
to
a
firewall,
an
intrusion
detection
system,
a
certain
bpa
gateway
which
might
connect
to
a
certain
vpn
concentrator.
C
So
you
have
this
chain
that
gets
that
gets
created,
and
you
want
to
enforce
this
particular
this
particular
path,
and
so
the
first
thing
that
that
you
see
happen
in
these
type
of
scenarios
is
you
have
a?
Is
this?
You
separate
out
the
control
plane
from
the
data
plane,
and
this
is
a
very
common
theme
in
networks.
C
You
even
see
this
in
in
hardware
switches
like
the
control,
plane
and
data
plane
will
be
separated
from
each
other,
and
that
way
you
can
control
it
and
update
your
control
plane
and
give
an
easy
model
that
you
can
then
manipulate
your
your
data
plane.
So
we
follow
the
same
pattern
where
in
kubernetes
were
able
or
your
your
run,
your
connectivity
domain.
C
So
what
this
means
is
that
every
item,
every
major
item
in
your
workload,
gets
an
identity.
So
the
pod
gets
an
x59
certificate,
firewall
intrusion,
detection
and
vpn,
and
the
vpn
itself
gets
an
identity,
and
these
identities
are
managed
by
these
control.
Endpoints
they're.
They
they
don't
tend
to
be,
even
though
they
can
be
pushed
down.
They
don't
have
to
be
the
devices
underneath.
C
Don't
need
to
be
aware
of
the
identity
as
as
long
as
the
endpoint
itself
is
aware
of
that
identity,
and
so
this
means
that
when
the
pod
connect
is
total
connect
to
this
firewall.
In
order
to
continue
your
communication,
it
knows
exactly
who
it's
connecting
to.
That
is
connecting
to
the
right
one
that
provides
the
right
type
of
firewall
with
the
right
policies
that
are
in
line
with
policy
of
the
operator
that
that
allows
it
to
proceed
to
the
next
step,
which
is
the
intrusion,
detection
system
and
and
so
on.
C
And
so
in
essence,
we
want
something
that
looks
like
this.
The
app
goes
to
the
vpn
gateway
following
that
chain
that
we
showed
before
connects
to
the
internet
and
then
connects
to
the
vpn,
concentrator
and
api
and
this.
So
this
allows
us
to
build
out
that
trust,
because
we're
using
x519
certificates
at
this
area.
We
can
establish
trust
where,
even
if
you
have
two
organizations
that
are
communicating
with
each
other-
and
that
are
you
that
are
following
the
same
pattern
and
are
controlling
their
own
set
of
identities.
C
Am
I
receiving
a
connection
from
the
right,
vpn
gateway,
all
driven
through
that
top
level
x509
set
of
certificates
that
were
released
with
those
specific
identities
and
also
with
the
policy
usually
using
something
like
open
policy
agent,
although
you
can
use
others
as
well,
defining
what
type
of
of
communication
is
allowed
between
between
those
systems,
so
that
was
a
foray
into
zero
trust.
These
are
all
things
that
we've
implemented
within
nsm,
so
that
allows
you
to
provide
that
decouple.
B
Thank
you.
What
are
one
other
quick
thing
here
again
the
we
would
love
to
see
folks
turn
off
the
nsm
august
17th,
it's
a
virtual
event.
The
information
is
here
so
feel
free
to
please
go
register.
That's
literally
a
week
from
today,
we've
got
a
really
good
lineup
of
speakers.
Talking
about
all
kinds
of
network
service.
Mesh
related
topics
from
all
across
the
industry
so
should
be
a
really
good
time.
C
A
And
there's
a
lot
of
those
are
like
anthem
and
bell
and
others
are
big
open
shift
users
too.
So
it's
it's
interesting
one
of
the
questions
I
have
and
thank
you
for
the
introduction,
because
it
cleared
up
a
lot
of
things
for
me
in
terms
of
different
service
meshes
and
how
level
seven
and
level
three
all
worked
was
great.
A
B
So
part
of
it
really
is-
and
this
is
what
gets
to
be
super
interesting
when
you
sort
of
look
at
building
a
system
like
this
and
you're
talking
about
single
panes
of
glass,
the
question
always
is
single
panes
of
glass
across
which
domain
and
who
is
actually
the
administrator?
That's
looking
at
that
single
pane
of
glass
and
one
of
the
challenges
that
you
actually
run
into
when
you
start
actually
growing
up
is
that
you
discover
that
the
world
is
much
more
complicated
than
a
single
administrative
domain.
B
That
gets
some
divided,
and
this
is
something
my
my
I'm
a
chief
network
guy
right,
and
so
this
is
something
I'm
very
familiar
with,
because
the
internet
is
not
a
single
administrative
domain
that
you
subdivide.
The
internet
is
a
bunch
of
peers,
and
so
it's
a
different
set
of
problems,
and
so
the
real
question
is:
how
do
you
give
people
visibility
into
the
parts
they
should
have
visibility
into
and
in
network
service
mesh?
What
we
have
is
some
very,
very
simple,
straightforward,
grpc
apis
that
will
allow
you
to
monitor.
B
B
That's
that's
not
something
I
am
never
going
to
have
control
over,
but
I
have
enough
visibility
that
I
can
see.
Okay,
this
is
sort
of
like,
what's
going
on
within
my
domain
of
control,
my
workloads
that
are
attaching
to
it
have
these
kinds
of
metrics.
So
I
can
see
the
problems
related
to
my
workloads.
Participation
in
that
network
service,
even
though
it's
being
provided
by
someone
else,
and
so
that's
an
interesting
piece
to
get
right
around
the
visibility,
but
because
everybody
has
their
own
dashboards
that
they
want
to
use.
C
Yeah
and
to
add
to
that
as
well,
when
you
start
looking
at
how
do
you,
how
do
you
control
these
type
of
systems?
The
network
service
mesh
was
designed
specifically
to
allow
multiple
companies
to
or
multiple
organizations,
to
also
be
able
to
establish
these
type
of
changes.
So
one
example
I'll
use
a
medical
example,
since
I
do
stuff
with
within
the
healthcare
space
is
in
in
the
near
future.
We're
going
to
have
5g
systems
deployed
out
and
we're
going
to
have
these
edge
data
centers
that
exist.
C
C
You
have
the
connection
from
the
hospital
to
the
edge
data
center,
that
owned
by
a
different
organization,
the
actual
firewall
or
firewall
intrusion,
detection
system
and
similar
things
so
and
so.
You're
talking
about
easily
six
seven,
eight
different
identities
and
setups
that
have
to
be
integrated
together
and
when
you
start
to
look
at
these
type
of
integrations,
there's
no
way
you're
going
to
be
able
to
be
able
to
control
all
that
across
all
identities.
C
Maybe
maybe
you
want
to
use
wireguard
for
tunneling,
because
you're
going
over
an
insecure
network,
so
then,
like
let's
go
and
establish
the?
What
key
should
I
use?
What
how
do
I?
What
ips
should
I
select
in
order
to
establish
that
that
connectivity,
and
so
so
it
allows
us
to
establish
a
means
to
is
to
negotiate
those
those
connectivities
while
still
giving
each
and
each
individual
section
each
company
the
ability
to
control
its
own,
its
own
set
of
networks
and,
in
the
case
of
kubernetes,
for
the
reference
implementation
that
we
did?
C
These
actually
are
defined
through
primarily
through
custom
resources.
So
we
have
a
crd
that
describes
that
there's
a
that
there's
a
workload
that
exists
and
that
you
can
then
connect
to
so
these
are
defined
through
the
discovery
is
done
through
through
custom
resources,
which
you
can
install
using
an
oper
an
operator.
We
have
an
nsm
operator
in
the
works.
C
B
You
can
think
about
this.
You
remember
the
old
adage
when
we
started
moving
into
the
virtual
world
about
pets
and
cattle,
where
it
used
to
be
that
you'd
have
servers
that
were
kept
as
pets
and
you
had
systems
who
would
lovely
lovingly
pet
them
and
feed
them
every
day
and
they
were
all
just
a
little
bit
different
from
each
other.
There
was
a
lot
of
manual
work,
and
so,
if
you
needed
a
new
server
well,
you
know
you
started
a
couple
quarters
ahead.
B
Looking
for
financing
for
it
and
finding
the
rack
that
you
could
put
it
in,
and
people
would
plan
out
the
wiring
and
go
to
do.
We
have
enough
ips
on
the
subnet
and
you
know,
and
then
somebody
would
come
in
and
say
well
gee
what?
What?
What
just?
What
version
of
this
distribute
linux
distribution?
Are
we
installing
and
what
extra
packages
do
we
need
the
system
to
install
and
so
getting
a
simple
server?
B
B
Network
service
mesh
is
doing
a
very
analogous
thing
to
how
you
handle
connectivity
between
domains
right
because
traditionally,
if
I
had
two
domains
that
needed
to
talk,
I
would
go,
and
I
would
have
my
dmz
and
there
would
be
meetings
with
you
about
your
dmz
and
we
would
negotiate
links.
There
would
be
all
kinds
of
things
about
policy
and
then
anytime
anything
had
to
move.
B
You
had
two
or
three
more
quarters
of
tickets
and
company
meetings
and
conversations,
because
all
of
the
communication
were
pets
at
a
level
that
was
even
absurd
compared
to
what
the
servers
were
and
that's
the
piece
that
has
to
get
solved
if
we're
actually
going
to
be
able
to
move
because
you've
got
a
mismatch
between
the
velocity
of
systems.
We
can
now
move
really
fast
within
a
single
cluster
and
really
fast
at
the
level
of
workloads,
and
it's
brought
us
enormous
benefits.
B
A
Okay,
yeah,
so
we're
almost
to
the
end
of
the
hour,
but
so
I
wanted
to
sort
of
refocus
a
little
bit
too.
You
are
a
cncf
sandbox
project.
You
have
a
lot
of
big
name,
even
openshift
and
other
customers
using
using
nsm
in
different.
It
sounds
like
a
lot
of
telco
a
lot
of
edge
scenarios:
automotive,
medical.
What
is
the
path?
The
next
steps
for
your
project
in
terms
of
cncf?
Are
you
still
gathering
steam
to
get
incubated?
B
B
You
know
basically
there's
a
radical
simplification
going
on
in
order
to
improve
velocity
of
development
across
the
entire
ecosystem,
and
this
also
ends
up
as
it
turns
out
and
simpler
is
a
lovely
thing
because,
as
it's
gotten
simpler,
we've
also
discovered.
We
can
make
the
system
even
more
robust,
so
we
already
had
in
place
a
very
good
resiliency
strategy
around
auto
healing,
but
that
resiliency
strategy
is
becoming
even
more
robust
as
we
simplify
the
system
because
it
turns
out.
Complexity
has
massive
taxes
everywhere,.
C
Yeah
one
of
the
things
that
we've
done
as
well
and
this
this
slowed
us
down
a
little
bit
but
is
proving
to
increase
our
velocity
quite
substantially.
Now
is
we
we
went
back
and
we
had
a
monolith
version
of
network
service
mesh
and
we
stepped
back
and
said:
okay.
Well,
this
monolith
is
actually
starting
to
to
slow
us
down
it's
trying
to
every
time.
I
want
to
make
a
change.
C
It's
becoming
more
more
difficult
to
make
a
change
to
the
core,
and
so
what
we
did
was
we
we
created
an
sdk
and
then
what
we
did
was
we
is.
This
sdk
was
designed
for
people
to
write
their
network
services
in,
but
then
we
made
the
realization
that
network
service
mesh
itself
should
be
written
using
that
exact
same
sdk,
so
in
other
words,
we
should
go
through
the
same
pain.
C
We're
asking
other
people
to
go
through
in
terms
of
in
order
to
build
up
these
systems,
and
this
has
turned
out
to
be
immensely
helpful
because
it's
helped
enforce
the
modularity
of
the
the
system,
and
so
it
allows
us
like
all
the
stuff
we
mentioned
about.
Identity
is
within
a
specific
service.
You
can
rip
that
service
out
sticking
your
own
identity
solution
in
the
same
with
policy
we're
using
open
policy
agent
as
our
reference.
C
C
What
are
the
results
of
that,
and
so
we've
so
we're
we're
very
close
to
having
a
a
full
release
on
this
new
version
with
this
new
sdk,
and
once
we
get
that
out,
there
then
well
we're
we're
gonna
spend
time,
helping
helping
others
to
stand
up
their
initial
versions
of
nsm
in
their
labs
in
their
in
their
test
environments
and
so
on.
So
they
can
get
a
feel
of
what
it's
what
it's
like
and
then
we'll
see
where
it
goes
from
there
cool.
A
A
A
A
Lots
of
things
we
can
talk
about
too
and
I'd
love
to
do
this
and
have
a
demo
of
deploying
it
and
and
showing
that
you
know
the
visualization,
maybe
in
in
the
context
of
openshift
as
well
sometime
when
the
new
release
comes
out.
So
please
come
back
and
with
that
I'll,
let
you
guys
go
back
to
your
day
jobs
and
I
will
go
back
to
my
vacation
and
we
will
upload
this
along
with
the
slides,
hopefully
in
the
next
day
or
so
so.