►
From YouTube: Gloo Mesh Enterprise Webinar 12.10.2020
Description
Gloo Mesh is the service mesh management plane for single to multi-cluster and multi-platform configuration, global failover routing, and operations. As a Kubernetes-native control plane, Gloo Mesh streamlines administration and unifies management as service mesh environments scales across clusters, clouds, and regions.
The recently announced Gloo Mesh Enterprise adds security, management, and commercial support to the open source edition, including:
* Role Based API for delegated service mesh access and ownership to configure policies
* Production Istio Support including validated upstream software, maintenance, patches/hotfixes, and long-term support (LTS)
* Operational Observability with unified dashboard with status and health across service mesh clusters, services, and workloads
* Integrated WebAssembly modules and tooling to customize service mesh behavior
A
A
A
A
I
just
want
to
make
sure,
and
so
let's,
let's
get
started,
I
see
people
continuing
to
trickle
in
and
I
assume
that'll
that'll
that'll
happen
here.
Thank
you
for
joining.
I'm
pretty
excited
about
this
webinar,
pretty
excited
about
what
we're
doing
here
at
solo
and
how
we
fit
into
and
can
help
folks
in
the
service
mesh
space,
particularly
in
their
adoption
of
service
mesh,
and
we
know
there
are
challenges
around
doing
that,
but
we
know
that
there
is
a
lot
of
benefit
to
doing
that.
A
A
A
A
What
the
what
the
web
companies
have
done
and
bring
that
to
enterprise
and
allow
allow
them
to
achieve
some
of
the
same
business
benefits
from
adopting
these
types
of
technology,
and
that
that's
why
I
came
here
to
solo,
because
we're
focused
on
a
particular
area
application
networking
that
I've
been
very
interested
in
for
a
long
time
and
so
at
solo.
What
we're
doing
is
we're
helping
our
customers
build
these
large-scale
distributed
systems,
solving
problems
at
the
edge
of
their
environments.
A
A
A
So
but
today
we're
going
to
focus
on
the
glue
mesh
part
of
our
stack
and
the
glue
mesh
part
of
the
of
our
stock
is
focused
on
the
service
mesh
part,
and
so
you
may
have
heard
of
service
mesh.
So
it's
been
around.
The
concept
has
been
around
for
three
or
four
years
now
and
there
have
been
various
open
source
projects
that
have
sprung
up
around
trying
to
implement
this.
A
This
pattern,
this
capability
and
really
the
focus
of
the
service
mesh,
is
to
kind
of
offload
and
and
simplify
how
applications
connect
to
each
other,
specifically
in
the
world
of
security,
things
like
timeouts
and
retries
and
circuit
breaking
so
in
large
distributed
systems.
These
these
are
not
optional
capabilities.
A
You
need
to
implement
them
and
doing
that
in
each
individual
microservice
in
the
application
code,
for
that
particular
library
in
that
particular
framework
and
then
trying
to
support
multiple
languages
and
multiple
frameworks
across
a
you
know,
a
distributed
architecture
that
that
is
incredibly
hard
to
operate,
and
so,
with
the
service
mesh,
we're
we're
able
to
implement
this
in
a
very
cross-cutting
way
and
implement
it
consistently
for
each
of
these
applications.
So
just
like
containers
came
in
and
simplified
the
deployment
and
scale
and
management
of
a
of
an
application
workload.
A
An
instance
service
mesh
is
coming
in
and
transparently
and
cross-cuttingly
solving
some
of
these
networking
connectivity
challenges,
regardless
of
what
language
the
application's
written
in.
So
some
of
the
ones
you
see
here.
Sto,
open
service,
mesh
from
azure
console
and
app
mesh
wouldn't
be
a
open
source
one,
but
it's
it's
definitely
a
very
interesting
one.
As
a
cloud
provided
service
mesh
service,
mesh
technologies
provide
these
features,
you're,
probably
familiar
with
them.
A
If
you're
interested
in
a
service
special
have
been
digging
in
kicking
the
tires
or
maybe
running
in
production
service,
discovery,
traffic
control
and
traffic.
Shifting
resiliency
aspects
like
circuit
breaking
traffic
and
telemetry
collection
and
and
it's
all
available
through
a
nice
api,
so
we
deploy
the
service
mesh
and
we
we
have
an
api
to
drive
and
change
the
behavior
of
of
that
mesh.
A
Now,
the
way
it's
implemented
in
most
of
the
incarnations
of
service
mesh
that
you'll
see
is
with
a
a
little
agent
or
a
little
proxy
that
lives
with
the
application
so
think
of
it
as
being
atomically
deployed
with
the
application
in
a
in
a
kubernetes
environment.
This
would
simply
be
you
know,
two
containers
in
a
single
pod
and
you
know
kubernetes
atomically
schedules
pods
onto
nodes
in
a
vm
world.
A
This
would
be
a
proxy
living
on
the
same
vm
as
an
application
instance,
and
when
that
application
tries
to
talk
to
another
service
on
the
network,
then
that
traffic
flows
through
its
local
proxy
and
if
the
application
goes
down,
that
proxy
is
down
and
vice
versa,
right.
There
they're
highly
co-located
that
proxy
can
implement
things
like
I've
mentioned,
load,
balancing
and
circuit
breaking
for
the
for
the
application.
A
In
the
event
things
on
the
network
misbehave-
and
we
know
that
that
they
do-
and
if
you
start
adding
these
proxies
to
more
of
your
application
instances,
then
configuring
them
observing
them
securing
them
all
this
stuff,
the
policies
around
it
that
becomes
quite
quite
challenging
unless
you
have
a
central
way
of
doing
that
and
that's
what
the
control
plane
comes
into
the
into
play.
So
the
mesh
has
made
up
these
proxies
and
some
way
to
configure
them
and
and
the
control
plane
is
what
the
administrators
then
of
the
network
will
use.
A
That's
what
provides
the
api
and
you
can
figure.
I
want
x,
number
of
retries
and
timeouts
and
the
circuit
breaking
policies
and
traffic
to
go
to
v1
or
v2
of
my
service,
and
so
you
can
figure
that
at
the
control
plane
now,
as
you
get
to
a
lots
and
lots
of
these
services
running
each
with
their
own
individual
proxy,
that's
what
forms
the
communications
mesh
and
hence
hence
the
name
master
service
mesh
for
for
describing
this
now
we've
been
here
at
solo,
have
been
involved
in
the
service
mesh
community.
A
For
quite
some
time
now
and
we've
we've
been
watching
each
of
the
different
instances,
I
I
particularly
have
been
interested
in
istio
and-
and
at
mentioned
some
of
these
other
ones
that
have
that
have
come
around
the
cncf.
Just
recently
did
a
survey
and
you
kind
of
have
to
dig
for
the
actual
results,
because
what
they
put
on
there
on
their
main
readout
of
the
the
of
the
data
didn't
really
show
this.
A
But
this
is
what's
in
the
raw
data
that
istio
is
by
far
one
of
the
dominant
is
a
service
mesh
implementations
that
people
are
taking
to
production
right
and
so
as
part
of
what
we've
been
doing
at
solo
working
with
this,
integrating
with
istio
and
so
forth.
Now
so
istio
has
become
an
integral
part
of
our
product,
but
that's
fine,
but
there's
still
challenges
to
adopting
a
service
mesh,
adopting
istio
understanding
which
one
to
choose
you
know
we've.
A
We
believe
that
the
the
tide
is
converging
on
istio
who's,
going
to
provide
support
for
these
projects
for
istio.
Specifically,
it's
a
very
fast-moving
complex
project
brings
a
lot
of
benefits,
but
you
know
in
an
enterprise
environment,
it's
not
suitable
to
just
pull
random
bits
off
of
the
open
source
community
things
like
multi-tenancy
and
getting
multiple
teams
to
deploy
using
a
service
mesh
managing
across
multiple
clusters.
A
This
is
a
non-trivial
exercise
to
deploy
your
services
across
multiple
clusters
and
get
them
to
communicate
and
and
be
you
know,
do
that
securely
and
observe
the
traffic
and
so
forth
between
the
clusters
identify
policies
about
which
services
are
allowed
to
communicate
with
each
other,
with
others
and
and
so
forth.
Some
of
these
clusters
might
be
running
on
premises.
A
Some
might
be
running
in
a
public
cloud
and
so
forth
and
and-
and
you
know,
figuring
out
how
developers
and
operations
will
work
on
this
platform,
all
right
so
with
docker
docker,
you
know
kind
of
fused
together
the
the
dev
world
and
the
ops
world
and
service
mesh
is
doing
the
same
thing,
but
not
without
some
some
challenges
there.
So
there
there
are
some
some
significant
challenges
in
adopting
and
operationalizing
it
in
an
enterprise.
I
think
that's
that's
the
most
important
part
right.
A
As
you
know,
some
of
the
conference
talks
makes
it
make
it
sound,
but
so
we've
been
very
deep
in
this
problem
space
for
a
while
now
and
we've
been
iterating
and
working
with
with
our
customers
on
what
is
what
is
suitable?
What
is
the
right
path?
What
is
success?
How
do
you
get
to
success
when
going
down
this
path,
because
we
know
it
delivers
quite
a
bit
of
benefits
in
terms
of
operational
simplicity,
security
and
and
being
very
quickly
able
to
adapt
to
the
changing
network
and
and
so
forth.
A
So
at
solo
we
have
a
product
called
glue.
Mesh
enterprise
and
glue
mesh
is
a
is
focused
on
solving
this.
These
sets
of
problems
that
people
have
when
adopting
a
service
mesh.
So
what
is
it?
Blue
mesh
enterprise
is
an
enterprise
distribution
of
istio
to
start
off,
and
with
that
comes
the
expected
level
of
enterprise
support
that
a
large
organization
would
need.
A
We
know
if
you're
familiar
with
istio,
that
issue
can
do
multi-cluster
communication
setting
that
up
and
more
importantly,
maintaining
that
in
an
enterprise
environment
is
not
trivial
and,
and
so
we've
solved
a
lot
of
problems
and
implemented
best
practices
and
so
forth
into
a
a
management
plan
that
can
be
used
to
to
federate
these.
These
different
istio
deployments.
A
A
So
you
still
have
a
centralized
pane
of
glass
through
which
to
manage
your
application
network,
which
at
that
point
could
be
made
up
of
istio
and
app
mesh
or
istio
and
azure
service
measures,
or
some
you
know,
set
of
different
providers
where
a
big
part
of
our
value
prop
is
we've
we've
sort
of
baked
some
of
these
best
practices
into
glue
mesh.
So
an
example
of
that
is
the
role-based
api,
which
I'll
show
you
in
a
second.
This
allows
you
to
customize
apis
for
a
particular
and
by
api.
A
A
You
know.
A
big
part
of
deploying
in
an
enterprise
is
to
be
able
to
be
backward
compatible
with
existing
assumptions
and
and
processes,
typically
around
security,
but
could
be
anything
right.
You
deploy
a
service
mesh
on
your
shiny,
kubernetes
cluster,
but
those
services
have
to
talk
with
existing
services.
That
might
run
somewhere
else
and
those
services
need
things
like
hmac
or
request
transformation.
Or
you
know
all
kinds
of
things
that
need
to
be
backward
compatible
with
the
existing
state
and
web
assembly
is
a
an
innovative
technology
that
allows
us
to
dynamically
program.
A
The
network
at
in
the
request
path,
using
any
language
that
that
you
know
that
you,
like
and
and
security,
and
so
being
able
to
define
access
control
policies.
These
kind
of
things,
maybe
better
better
shown
in
a
demo,
but
this
is
so
glue.
Mesh
enterprise
is
focused
on
solving
the
challenges
of
adopting
a
service
mesh
and
will
support
it
istio
in
production
and
give
you
access
to
these
these
non-trivial.
You
know
deployment
models
and
and
simplify
the
management
of
doing
that.
A
A
So,
let's
go
through
with
an
example
right
the
glue
mesh.
It's
a
it's:
a
distribution
of
a
service
mesh,
pretty
powerful,
can
do
all
these
things.
But
what
are
the
nuance?
What
what
is
the
the
nuance
here?
Because
you
don't
really
know
until
you've
tried,
deploying
a
service
mesh
and,
and,
like
I
said,
we've
we've
been
working
with
with
the
ecosystem
with
our
customers
and
our
partners
for
the
last
three
years.
This
is
something
that
we
know
very
deeply.
So
here
here
are
some
of
the
things
that
that
have
popped
out.
A
So
when
you
get
started,
you're
gonna
start
typically
by
onboarding.
You
know
so
if
you're
gonna
start
with
seo,
typically
starting
with
with
kubernetes
and
you're
gonna
bring
a
couple
services
in
there
and
you're
gonna
start
with
istio
right.
You're
gonna
need
some
ex,
so
so
some
advice
about
how
to
get
started
with
issue,
how
to
operationalize
it
and
it
starts
with
well,
if
things
go
wrong,
who
do
I
call
all
right
so
glue?
Mesh
includes
production
issue
of
support.
A
We
also
include
specialty,
builds
for
those
in
you
know,
in
in
government
that
require
a
certain
level
of
compliance.
So
with
fips.
We
know
folks
are
taking
a
look
at
additional
architectures
to
save
money
like
arm
so
getting
the
build
of
istio
that
you
need
comes
along
with
with
blue
mesh.
We
try
to
stay
as
close
to
upstream
as
possible.
We
have
no
intention
of
forking
issue.
A
This
is,
but
you
know
for
some
of
these
things
fips
and
arm,
and
those
were
there's
some
minor
build
level
things
that
we
have
to
have
to
alter.
We
provide
long
term
support
and,
if
you're
familiar
with
the
community,
the
community
does
the
existing
version
latest
version
and
the
one
behind,
or
just
previous
right
and
in
enterprise.
That's
not
very
tenable,
because
keeping
up
and
upgrading
istio
is
first
of
all,
not
not
that
easy.
A
But,
more
importantly,
if
it's,
if
you're,
if
you're
deployed
onto
a
kubernetes
cluster
and
istio,
requires
a
certain
version
of
kubernetes
and
the
next
new
version
of
istio
requires
the
next
new
version
of
kubernetes.
You
know,
locking
those
two
in
is
again
not
tenable
for
an
enterprise
which
typically
stays
on
kubernetes
clusters
much
longer
and
a
little
bit
slower.
A
So
we
support
n
minus
three
releases
of
istio
with
critical
security
patches.
We
will
provide
break
fix
production
patches
with
with
a
24
hour
or
sorry
one
hour,
severity,
one
sla
and
operational
and
architectural
best
practices.
You
get
to
work
with
our
engineers
who
are
very
experienced
in
this
in
this
space,
and
we
know
that
the
path
to
take
and
the
path
to
avoid,
and
so
just
having
access
to
that
knowledge
is,
is
really
important,
especially
when
you
first
get
started
now.
A
If
teams
that
are
using
services,
you
have
teams
that
are
maybe
releasing
and
managing
and
planning
for
high
availability
and
this
kind
of
stuff.
You
have
the
sre
teams,
you
have
the
platform
teams,
you're
doing
the
installation
and
maintenance,
and
maybe
you
know,
we've
seen
blurring
of
all
of
these
different
roles,
but
nevertheless
they
exist
in
some
form
again,
not
uniform
at
every.
It's
not
exactly
the
same
at
every
organization,
but
they
do.
They
do
exist
at
in
various
forms.
A
It
was
honestly
built
in
with
the
intention
that
something
else
on
top
of
it
would
be
kind
of
putting
putting
this
together
and
it
would
be
the
last
step
before
it
gets
to
to
istio.
So
it's
a
pretty
complex,
comprehensive
low-level
api
and
in
istio
you
have
things
like
virtual
service
destination
rule.
These
are
sort
of
the
core
api
constructs
that
you
would
configure
to.
You
know
in
this
particular
example.
As
a
service
provider
owner
you,
you
care
about
things
like
host,
name
and
and
path
based
routing,
maybe
traffic
splitting
you
care
about.
A
You
know
what
other
services
are
calling
you,
or
that
you're
calling
as
part
of
your
implementation
circuit
breaking
for
callers
that
are
calling
you
and
so
forth
right
and
in
istio.
These
are
the
these
are
the
resources
that
you
would
configure
for
each
service.
So
you
know
you
see
two
columns
here.
A
Right
now,
the
problem
with
that
is
this
is
becomes
an
extremely
and
highly
contended
set
of
resources.
So
because,
initially
you
can't
have
multiple
virtual
servers
attached
to
the
same
service.
They
don't
merge,
and
so
because
of
this
lower
level
api
and
the
fact
that
it's
not
built
it
wasn't
built
and
intended
for
specific
organizations.
A
What
we
see
people
try
to
do
is
use
these
resources
directly
and
start
pulling
their
hair
out
right,
because
this
content,
organizational
contention
for
these
resources
becomes
a
big
problem.
Now
these
are
just
in
one.
You
know
we
just
looked
at
it
from
the
lens
of
the
service
developers,
those
producing
services
and
consuming
services,
but
you
see
similar
things
between
the
non-traffic
specific
type
resources.
A
Things
excuse
me
things
that
specify
the
security
properties,
things
that
specify
the
edge
properties,
things
that
customize
the
behavior
of
the
control
plane
outside
of
the
out
of
the
box
apis
with
the
envoy
filter.
So
the
point
is
a
lot
of
different
apis
in
seo
powerful,
because
they're
very
low
level,
they
were
not
intended
or
yeah.
They
were
not
intended
or
built
for
out
of
the
box
usage
as
they
are,
and
you
start
to
see
this
with
the
organizational
contention
that
comes
comes
in,
and
so
that's
the
problem
we
tackle
head-on
with
blue
mesh.
A
So
starting
with
a
single
cluster
seo
cluster
operationalizing
getting
people
to
deploy
into
it.
We
reduce
the
api
surface
to
something
much
simpler
and
we
give
you
options
right.
So
the
the
api
surface
in
glue
mesh
is
basically
traffic
policy
and
access
policy
and
in
the
traffic
policy
you
can
specify
you
know,
header
matching
and
fault
injection
and
circuit
breaking
all
this
stuff.
But
as
the
administrator
of
the
platform,
you
can
say
you
know
what
for
my
service
consumers
they
all,
they
can
only
configure.
A
So
the
the
glue
mesh
role-based
apis
is
hugely
powerful
for
or
solving
some
of
these,
these
problems
and
it's
simplified
because
in
istio,
for
example,
in
other
service
meshes,
they
take
a
very
service
owner
view
of
the
config.
The
service
owner
is
the
only
one.
That's
going
to
be
configuring,
anything
everybody
else.
You
know
you're
on
your
own,
in
glue
mesh,
we
take
a
a
traffic
routing
approach
to
the
api,
which
is
a
little
bit
more
natural
way
of
thinking
about
it.
A
If
you're
a
client-
or
you
know
the
service
provider
or
managing
the
platform
or
whatever,
which
is
all
I
care
about-
is
traffic
going
from
this
group
to
this
group
source
and
destination
source
and
target,
and
what
is
the
policy
that
I'm
going
to
apply
to
that
traffic
right
now?
How
that
actually
gets
implemented
under
the
covers?
I
don't
really
care
so,
but
but
I
want
that
api
service
to
be
as
simple
as
possible.
So
let
me
just
show
you
real
quick.
A
A
A
So
I
can.
I
can
take
that
part
out
and
just
just
say
for
this
one
cluster.
You
know
if,
if
traffic's
going
from
the
product
page
to
the
reviews
page,
then
you
know
we
want.
We
want
retries
that
whatever
circuit
breaking
at
whatever
and
then
you
know
you
saw
this
this
slide
here.
We
specify
this
to
the
glue
mesh
management
plane
and
the
glue
mesh
management
plane
translates
that
to
the
appropriate
istio
resources.
A
All
right,
so
we
have
the
traffic
policy
we
maybe
on
maybe
on
the
service
owner
side.
Maybe
we
care
about
the
traffic,
shifting
capabilities
or
requests
and
and
pattern
matching
or
header
matching,
to
get
traffic
to
a
particular
version
and
and
so
forth
again
with
following
the
same
source
and
destination
source
and
target.
You
know
that
that's
the
main
model
behind
the
api
here
now
you're
wondering
well,
can
service
foo
specify
policy
for
service
bar
right,
because
we
don't
want
that.
A
So
here's
here's
what
the
admin
one
looks
like
in
this
case
we're
giving
access
to
everything
for
the
admin
for
the
the
traffic
policies
for
any
of
the
access
policies
which
we'll
look
at
in
a
second
failover
policies
and
so
forth.
So
we
can
be
very
fine
grain
in
how
we
kind
of
wrap
out.
You
know,
carve
out
what
exactly
is
a
service
owner?
What
exactly
is
a
service
client
and
what
exactly
is
a
sre
or
platform
owner
or
admin?
A
Or
you
know,
we
could
be
very
fine-grained
about
that,
and
I
hinted
at
this
in
this
api-
the
multi-cluster
capabilities
which
we're
going
to
get
to
right
now
again,
just
a
just
a
reminder
that
if
you,
if
you're
interested
you're
following
along,
you
have
questions
and
so
forth,
please
ask
them
in
in
the
chat
or
in
the
q
a
box,
okay,
so
you're
you're,
starting
with
service
mesh.
You
see
the
benefits
of
it.
A
So
we've
deployed
our
service
mesh
capability
across
three
different
clusters.
Now
with
istio,
specifically,
there's
there's
a
few
different
models
for
deploying
istio
across
clusters.
All
right,
you
can,
if
there's
assumptions
about
the
network
flat
networking,
you
can
maybe
share
a
control
plane
across
all
the
different
clusters.
A
That
means
you
know
running
running
different,
it's
id's
in
each
of
the
clusters
and
configuring
the
services
as
though
they're
independent
right,
you
can
do
things
to
give
them
some
whereabouts
about
where
the
other
services
exist.
So
istio
has
something
called
a
service
entry
where
you
can
manually
populate
a
registry
in
one
of
the
clusters
that
says
hey.
I
have
account
service
running
in
cluster
one,
but
I
also
have
an
account
service
running
on
cluster
three
and
maybe
that's
running
in
somewhere
else,
and
so
with
the
seo
service
entry.
A
What
we
can
do
is
tell
cluster
one
that
hey,
there's
also
another
account
service
on
cluster
three
right,
so
you
can
do
that
kind
of
service
discovery.
Now,
we've
seen
people
go
down
this
path.
They
start
to
go
one
cluster
to
three
clusters
to
five
to
ten
or
whatever,
and
they
say
you
know
basically
end
up
trying
to
write
their
own
automation
for
dealing
with
some
of
the
challenges
of
you
know
we
saw
earlier.
A
Each
service
needs
its
own
set
of
virtual
services
and
destination
rules,
sidecar
resources,
maybe
service
entries
now
and
all
of
all
of
this,
this
this
config
and
what
they
end
up
doing
is-
is
able
to
try
and
get
ops.
They
try.
Building
some
controllers
solving
this
problem
is
extremely
complex,
as
you
can
see
in
this
slide.
A
This
is
just
a
actually
a
simplification
of,
even
though
the
slide's
busy
it's
a
simplification
of
what
you
actually
have
to
do
to
get
this
to
work
the
first
time,
and
then
you
have
to
maintain
it
and
make
sure
that
as
services
move
scale
up
and
down
that
these,
these
these
configs
are
updated
or
moved.
Or
you
know
whatever
it
is,
so
you
can
see
the
account
visa
virtual
services,
the
account
service
entries
for
entries
in
a
different
cluster
and
so
forth.
A
A
Maybe
some
teams
deploy
their
service,
their
account
service
in
namespace
foo,
but
then
on
a
different
cluster
account
service
goes
to
namespace
bar
and
it
gets
it
gets
pretty
hairy
so
there,
even
even
a
operating
istio
in
a
multi-control
plane
fashion
is,
is
the
right
architecture
for
high
availability
and
and
fault
tolerance
it
it's.
It
takes
some
work,
takes
some
effort
to
keep
that
going,
and
so
there
are
things
like
going
between
clusters.
You
know
keeping
the
identity
domains
similar
or
having
them
separate
and
figuring
out
how
to
bridge
them.
A
Some
of
the
some
people
who
have
operated
istio
know
that
if
you
write
a
virtual
service
that
references
or
tells
traffic
to
go
to
v1
and
v2
before
you've
actually
specified
the
destination
rule
with
the
subsets
for
v2,
you
can
end
up
with
with
503s,
because
you
know,
although
istio's
config
model
is
built
to
be
eventually
consistent,
so
it
doesn't,
it
won't
tell
you
that
this
is
bad
config.
You
can
easily
get
yourself
into
a
situation
with
bad
config
and
so
defining
the
failover
semantics
and
the
and
the
routing
between
services.
A
A
So
when
I
deploy
the
account
service
in
cluster
one
which
needs
to
talk
to
the
user
service,
then
I'll
tell
cluster
one
about
the
user
service
in
cluster
two.
I
won't
actually
blue
mesh
management
plane
will
because
it
knows
where
their
services
are
running.
It
has
sophisticated
discovery
mechanisms
that
allow
it
to
find
what
services
are
running
on
what
clusters
and
then
do
all
the
bookkeeping,
for
you
know
enabling
access
where
needed
or
enabling
service
discovery
where,
where
needed.
A
So,
your
teams,
you
still
write
traffic
policies,
access
control,
access
policies
that
specify
routing
and
retries
and
header
matching
and
whatever,
and
you
think
of
it
in
terms
of
the
api
that
that
we
looked
at
a
second
ago,
the
traffic
policy
or
the
access
poly
policy
api,
which
is
predicated
on.
I
just
care
about
the
source.
I'm
I'm
worried
about
the
traffic
and
the
security
of
that
traffic.
What
cluster
it's
on
and
whether
it's
moved
or
one
part
has
failed,
and
now
it's
failing
over.
I
don't
care
about
that.
A
I
just
care
that
traffic
from
the
source
going
to
the
target
has
these
policies
associated
with
it,
and
so
that's
the
api
that
I
showed
earlier,
and
that
also
applies
to
multiple
clusters,
so
you
can
take
that
same
model
now,
you've
operated.
You
you've
established
that
your
organization
can
operate
in
a
single
istio
cluster
between
the
teams.
Now
the
fact
that
you've
gone
to
3
4
10
eighty
clusters
that
doesn't
matter
to
them
all
they
still
care
about
is
their
their
services
and
and
how
they
communicate
with
each
other.
A
A
The
virtual
mesh
is
a
resource
that
we
specify
right
here,
the
the
different
meshes
in
a
group
of
meshes
that
we
want
to
treat
as
though
they're
a
single
federated
set
of
meshes.
It
looks
like
a
single
mesh
and
we
write
our
api
objects
against
that
right,
so
we've
previously
created
the
virtual
mesh
and
then,
if
we
come
here
to
our
our
dashboard-
and
we
can
see,
we
have
one
mesh
configured,
but
if
we
click
on
the
meshes,
we
see
that
this
one
mesh
is
actually
the
virtual
mesh.
A
This
is
made
up
of
two
different
meshes
istio
running
in
cluster
one
and
istio
running.
I
clicked
on
it.
It's
still
running
on
cluster
one
and
istio
running
on
cluster.
Two
we
see
between
those
two
different
clusters.
We've
discovered
10,
different
different
services
made
up
of
13
different
workloads.
So
all
that
means
is
some.
Some
services
have
multiple
versions
or
multiple
replicas
or
any.
You
know
that
we
don't
have
any
any
failover
policies
set,
but
we
do
have
some
some
policies
defined
here.
A
It
looks
like
looks
like
I
didn't
clean
up
the
previous
demo.
That's
why?
Well,
let's
just
keep
going
and
see
what
happens
right
so
now
that
we
have
the
the
virtual
mesh
has
been
established.
The
glue
mesh
controllers
are
listening
for
for
api
changes.
Let's
see
what
happens
if
we
come
in
here
and
we
go
to
our
sample
application.
A
A
So
if
we
come
in
here
and
look
at
cluster
one,
we
can
see,
we
have
a
reviews.
Let
me
see
we
have
reviews
workloads,
v1
and
v2
running
in
in
cluster
one.
We
see
a
reviews
v3
running
in
in
cluster
two,
and
so
what
we
want
to
do
is
is
take
a
look
at
how
we
can
affect
the
traffic
between
the
services
and
between
the
clusters
using
glue
mesh.
A
So
the
first
thing
we're
going
to
do
is
we're
going
to
enable
access
policy
on
this
on
this
mesh
by
default.
It's
not,
and
so,
if
we
enable
that,
what
we'll
see
is
that
the
access
policy
controls
which
by
default
is
deny
all
kick,
should
kick
in
and
if
I
do
here
refresh,
we
should
see
after
a
second
actually,
you
know
what,
because
of
those
policies
that
I
didn't
clean
up
from
the
previous
demo,.
A
A
There
we
go,
but
it
just
takes
a
second
plus
a
live
demo
likes
to
give
me
give
me
keep
me
on
my
toes
here,
so
we've
gotten
into
this
state
now,
where
we're
completely
denied
and
we
have
to
specify
access
policies
to
allow
traffic
to
flow
so,
for
example,
in
this
access
policy,
we're
going
to
say
from
the
ingress
to
the
product
page.
Let's
enable
that-
and
this
happens
to
be-
we
are
explicitly
specifying
clusters
here.
We
could
give
it
a
list
of
clusters,
we
could
give
it
no
clusters.
A
A
All
right:
well,
oh
there
we
go
okay,
so
it
looks
like
the
seo
is
gonna
be
a
little
slow
for
me
for
my
demo.
Well,
we
we
created
this
access
policy
and
what
glue
mesh
did
was
it.
It
took
that
policy,
it's
it
looked
at
it
at
the
model,
looked
at
the
description
and
then
went
and
translated
that
to
istio
and
put
it
on
the
various
clusters.
A
So
if
we
come
back
here
and
look
at
our
policies,
we
should
see
the
ingress
gateway
policy
that
we
that
we
added
and
we
see
the
source
and
target
model
that
that
I've
been
referring
to.
So
we
can,
we
could
probably
keep
going.
It
seems
like
this
is
going
to
take
a
little
while
to
let's.
Why
don't
we
when
we
add
these
policies
back,
so
that
traffic
routing
will
work?
A
This
is
the
this.
Is
the
last
traffic
policy
we'll
give
that
a
second
let
istio
trickle
down
and
I'll
refresh
the
by
chance?
If
it's
sped
up,
no
we'll
give
it
a
second
to
do
its
thing,
I'm
going
to
continue
with
the
talk
and
then
we'll
come
back
and
we'll
pick
up
the
demo
from
when
it's
you
know
on
this
particular
cluster
response.
A
Okay,
so
now
let's
say
you,
you
got
seo
up
and
running
you're
using
glue
mesh
successfully
to
operate
across
multiple
clusters,
and
then
someone
in
your
team
decides
that
they
want
to
go
to
aws,
and
you
know
they're
going
to
take
you're
going
to
use
eks
they'll,
bring
you
steel
there,
but
they
for
ecs
or
for
ec2,
maybe
they're
thinking
about
maybe
using
appmesh
and
so
with
glue
mesh.
We
don't
really
care
what
the
underlying
mesh
is.
A
The
same
approach
in
in
the
api
and
the
functionality
for
managing
multiple
clusters
or
multiple
different
meshes
is
the
same
across
other
service
meshes
as
well,
and
with
glue
mesh.
We
can
oh,
hence
the
name
glue
the
different
service
meshes
together,
so
that
all
you
all
you
care
about
and
focused
on
is
is
the
networking
traffic
between
service
a
and
service
b,
regardless
of
where
it
lives?
Is
it
secure?
A
A
The
the
glue
mesh
management
plane
knows
about
the
different
clusters
knows
about
the
different
meshes
knows
how
to
translate
the
glue
mesh
api
into
the
correct
mesh
provider,
and
then
you
get
the
same
same
dashboard
capabilities
and
and
so
forth,
to
manage
your
mesh
from
a
single
pane
of
glass,
let's
refresh
and
see.
If
we
can
get
that
there,
we
go
now
we're
working
a
little
bit
better,
bouncing
back
and
forth
between
reviews,
v1
and
reviews
v2.
A
If
we
come
back
here
and
actually
look
at
a
traffic
policy,
we
saw
that
a
little
bit
earlier,
but
in
this
traffic
policy,
what
we're
going
to
say
is
when
you're
talking
to
the
review
service,
send
75
of
the
traffic
to
cluster
2
and
the
rest
of
it
bounce
back
and
forth
between
the
versions
on
cluster
one
right.
So
in
this,
in
this
case,
if
we
apply
this
traffic
policy
and
across
our
fingers,
then
what
we
should
see
is
the
traffic.
A
If
I
refresh
should
go
to
the
review
service,
which
has
red
stars
which
is
living
in
a
different
cluster
and
because
the
virtual
mesh,
or
because
the
virtual
mesh
concept
is
in
place
and
has
done
all
the
heavy
lifting
around
identity,
you
know
setting
up
the
certificates
correctly,
there's
from
the
same
route.
Now
the
trust
domains
are,
are
unified.
We
should
be
able
to
get
an
end
to
end
connection
from
cluster
one
to
cluster
two
and
and
and
see
that
that
traffic
flow.
A
A
A
And
then
I'll
I'll
get
into
this
last
part
here
about
extending
the
mesh.
Now,
we've
deployed
istios
across
the
our
different
networks
and
we
have
different
application
workloads
running
in
there.
But
you
know
we
need
to
implement
some
capabilities
inside
the
proxies
in
the
data
plane
in
the
request
path
that
make
it
behave
more
in
line
with
the
way
our
existing
applications
expect.
Maybe
they
need
to
add
additional
headers,
because
these
legacy
services
expect
it
or
we
need
to
process
a
jot
token
slightly
differently,
because
it's
not
standard
and
and
so
on.
A
A
In
fact,
solo
has
been
very
instrumental,
helping
the
developer
experience
around
web
assembly
and
for
for
istio
and
we're
bringing
that
to
the
blue
mesh
product
as
as
well,
and
so
with
webassembly
webassembly
is
a
way
of
writing
your
extensions
or
your
code.
In
whatever
language
you
want
and
then
compiling
it
down
into
webassembly
code
and
then
injecting
that
into
the
envoy
pipeline,
and
so
that
you
can
inject
that
as
a
filter.
A
That
might
be
specific
to
a
particular
organization.
It
follows
the
same
this
same
model,
so
the
the
web
assembly
support
you
know
is
is
able
to
support
multiple
different
languages
right
now.
The
the
developer
experience
around
this
is
amazing.
We
want
to
do
another
webinar
on
this
soon,
showing
the
build
and
and
sharing
and
deployment
of
web
assembly
now
come
on.
A
A
The
benefits
of
something
like
blue
mesh,
specifically
blue
mesh
is,
you
know,
istio
expertise,
istio
support
and
production,
these
additional
capabilities
which
are
tried
and
true
they
are.
We
learned
this
through
a
lot
of
blood,
sweat
and
tears
and
we're
bringing
some
of
these
best
practices
and
operational
practices
to
glue
mesh
to
allow
others
to
also
be
successful
in
deploying
and
scaling
their
service
mesh.
A
Now,
where
we
are
today,
you
can
get
started
today.
Our
istio
support
is,
you
know
you
can
get
glue
mesh
today,
get
istio
support
right
away.
The
roll-based
apis
are
in
beta,
but
you
know
very
soon,
we'll
be
we'll,
be
ready
and
fully
or
they're
in
beta
and
fully
supported,
but
will
be
ready
and
more
generally
available
very
soon
and
then.
Lastly,
this
is
the
approach
that
we've
seen
it
work
in
in
phases
with
our
our
customers,
which
is
starting
with
seo.
A
A
A
A
We've
been
building
on
an
envoy
for
the
last
three
years,
we're
running
in
production
with
very
large,
well-known
household
named
companies
and
so
from
from
the
gateway
on
down
like
we're.
We're
envoy,
right,
ng
or
kong
is
nginx
and
lua
for
the
gateway
and
and
now
they're
they're
they're
building
their
own
service
mesh,
but,
like
I
showed
you
in
so,
if
we
take
a
look
at
oh
where's,
this
oh
powerpoint,
is
all
jammed
up
on
me
here,
like
I
showed
you
earlier
in
the
cncf
survey.
A
A
Going
with
the
right
technology,
so
we
are
running
out
of
time
and
my
computer
is
being
really
really
flaky
here.
Hopefully
you
can
still
see
my
screen,
but
and
actually
the
the
chat
window
went
away
somewhere
else
now.
Well
sorry
for
these,
these
technical
difficulties
here,
please
do
you
know
so
again.
My
name
is
christian
reach
out
to
me.
If
you
have
any
question
reach
out
to
solo
here
on
this
page,
join
our
slack
happy
to
talk
more
and
and
and
help
you
through
your
service
mesh
adoption
journey.
A
A
A
A
We
can
see
all
of
the
istio-specific
resources
that
were
that
were
generated
right,
so
this
just
to
get
the
traffic
to
go
from
cluster
one
to
cluster
two
for
these
handful
of
services,
and
we
had
all
these
service
entries.
We
had
a
bunch
of
destination
rules,
envoy
filters
and
gateway,
just
one
gateway,
probably
two
gateways
and
then
the
authorization
policies.
So
to
answer
your
question
fernando,
if
you
can
still
hear
me,
the
authorization
policies
are
what
was
what
was
translated
from
from
the
glue
glue,
mesh
management.