►
From YouTube: Sharpen That Edge! How a Service Mesh Enhances EdgeComputeOps - Marino Wijay & Kevin Dorosh, Solo.io
Description
Sharpen That Edge! How a Service Mesh Enhances EdgeComputeOps - Marino Wijay & Kevin Dorosh, Solo.io
Sometimes you go all in on the cloud; sometimes you need to sharpen that Edge a bit. When pursuing Edge Computing, the largest considerations for adoption are: - Ease of deployment - Zero-trust security posture - Resource allocation and consumption - Telemetry and Observability - Latency and application response times - Resilience and reliability Large enterprises in heavily regulated industries or the public sector must adopt practices like a zero-trust security posture both inside and at the edge of its application networks. They must simultaneously be able to determine application performance through telemetry, and mitigate issues. They need to ensure the resilience & reliability of the edge in the face of catastrophe, like a cluster or region failure. What's the right approach to meeting these conditions? Enter Ambient Mesh, the perfect vehicle for meeting these challenges! This talk dives into how Ambient Mesh offers a revolutionary data-plane architecture for Edge Computing. Ambient Mesh can configure both perimeter and internal proxies to deploy an enhanced security posture while slashing operational complexity and enabling incremental mesh adoption, all while reducing cost and computational overhead at the Edge.
A
All
right
good
afternoon,
everyone,
thank
you.
So
much
for
coming
to
our
talk
sharpen
that
Edge
Edge
compute
Ops.
We
are
going
to
talk
about
kubernetes
at
the
edge,
but
I
mean
you've
heard
enough
about
it.
We're
actually
going
to
talk
more
about
networking
problems
with
kubernetes
at
the
edge,
so
my
name
is
Marina
widget.
B
A
Awesome
thanks
Kevin.
Can
we
get
that?
Second?
Can
we
get
that
second
mic
working
too,
if
possible,
all
right,
so
we
already
know
what
the
edge
is,
but
I
wanted
to
create
a
I
wanted
to
create
a
little
bit
of
a
background
here,
because
when
we
decided
we
want
to
build
our
own
little
cloud
with
Edge
Computing,
with
whatever
options
that
are
available
to
us.
We
have
to
think
about
the
network.
The
network
is
probably
the
most
critical
aspect
of
it.
I
mean.
A
Maybe
there
are
other
perspectives
on
what
is
critical
with
the
edge,
but
from
my
perspective,
coming
from
a
network
engineering
background,
networking
is
critical
to
make
sure
that
you
know
we
have
connectivity
between
our
services
that
we
have
clusters
that
can
communicate
with
each
other
and
then
a
whole
wealth
of
other
things
too.
Around
security,
observability,
Automation
and
operations.
A
But
one
thing
I
want
to
point
out
is
that
there
are
a
few
kinds
of
edges.
There
is
the
content,
delivery
style
Edge,
where
you
know
you
might
have
played
with
a
CDN
and
then
there's
the
edge
that
you
roll
your
own.
Where
you
decide
hey
I
want
to
keep
take
complete
control
of
my
cloud
environment
or
the
the
cloud
environment
that
I've
built,
distribute
all
my
workloads
everywhere,
distribute
my
compute
everywhere
and
still
have
it
all
tied
together,
so
that
I
know
when,
let's
say
app
a
fails.
A
It
has
a
place
to
run
somewhere
else
or
I
have
a
good
resiliency
built
into
my
entire
Edge
compute
strategy,
but
before
we
actually,
you
know,
dig
deeper
into
the
networking
side
of
things.
Let's
talk
about
the
reasoning
behind
why?
Why
would
we
want
to
do
Edge,
compute
I
mean
I.
Think
there's
enough,
you
know,
reasoning
behind
why
we
would
want
to
do
it.
You
know,
there's
a
lot
of
iot
there's
a
lot
of
agricultural
systems
that
take
advantage
of
it.
In
fact,
I
think
Steven
mentioned
a
few
good,
excellent
use
cases.
A
This
is
an
excellent
talk
happening
later
on
today
about
a
particular
use
case,
but
when
we're
actually
starting
to
form
our
Edge
strategy,
there
are
several
key
things
we
have
to
think
about.
If
we're
deploying
to
thousands
of
locations,
we
have
to
first
understand
why
we
want
to
do
this.
Do
we
have
some
specific
applications
that
suffer
from
latency?
If
we're
having
to
hop
across
the
pond?
A
Do
we
have
any
sort
of
privacy
or
security
requirements,
as
previously
mentioned
in
in
the
last
talk,
or
do
we
have
any
sort
of
concerns
around
running
workloads
close
to
you
know
individual
users
more
like
a
geographical
distribution
of
our
workloads
and
apps,
but
then
it
also
comes
back
to
people
right.
Do
we
have
enough
people
to
support
the
solution
that
we
build?
Do
we
have
the
right
footprint
and
Hardware
to
go
out
and
deploy
I
mean
considering
Hardware,
you
have
to
think
about
procurement.
You
have
to
think
about
the
right
fit.
A
You
have
to
think
about
how
much
it's
going
to
cost
you
from
a
budget
standpoint
to
not
only
deploy
but
also
life
cycle
it
over
time,
because
guess
what
Hardware
doesn't
last
forever
as
we
know,
and
the
most
most
of
the
time
you
see
that
systems
are
swapped
out
every
three
to
four
years
because
of
newer,
Technologies,
faster
chips,
more
density
that
we
require
in
our
nodes.
But
that's
how
we
arrive
at
Edge
Computing.
A
We
start
to
see
that
we
can
pack
many
kinds
of
workloads
onto
a
single
little
node
that
you
might
have
seen
in
the
last
presentation
like
a
Nook,
but
we
also
have
to
consider
other
aspects
too.
How
do
we
get
services
to
talk
to
each
other
sure
we
can,
you
know,
employ
traditional
means
of
networking
like
an
mpls
technology,
or
you
know
some
sort
of
VPN
style
technology,
but
then
you
also
have
to
consider
the
other
layers
too,
like
authorization
authentication
being
able
to
provide
encryption
between
your
services
that
are
communicating
across.
A
You
know
various
edges
as
well
as
seeing
what's
actually
going
on.
Like
you
know,
hey
we
have
an
edge
down.
We
have
an
app
down
what
is
actually
causing
this.
So
as
we
start
to
dig
into
it,
we
want
to
focus
a
lot
on
the
the
networking
side
of
it
like
I
mentioned
previously,
so
that
falls
into
the
Realms
of
communication,
Cloud
devices
and
metrics
and
and
even
security
and
automation,
but
before
we
dive
into
that,
I
want
to
just
bring
your
attention
to
an
existing
solution
today.
A
I'll
mention
in
in
fact
that
there's
a
technology
called
Edge
mesh
that
allows
for
connectivity
between
all
these
different
Edge
locations
that
you
could
deploy,
but
there
are
limitations
with
something
around
Edge
mesh
around
achieving
zero
trust
security,
making
sure
that
you
can
see
what's
actually
going
on
and
capture
Telemetry,
kpis
and
metrics
from
your
apps.
It
only
provides
connectivity
at
a
very
basic
level,
so
you
start
to
think.
A
Okay,
if
I
want
mesh
like
functionality,
if
I
want
connectivity
at
the
layer,
7
Level,
you
know,
I
have
HTTP
Communications
going
on
all
over
the
place.
What
do
I
do
so?
Let's
talk
about
the
network
stack
first
and
then
we'll
start
to
dig
into
how
a
service
mesh
helps
with
this
a
true
service
mesh.
So
you
think
about
your
network
stack
for
a
second
and
you
could
either
go
with
cloud
or
x86
Hardware
that
you
prepare.
A
You
can
have
things
talking
to
each
other,
but
when
we're
starting
to
talk
between
various
different
Services,
we're
talking,
thousands
upon
thousands
of
services,
the
mesh
or
the
service
mesh
really
provides
a
significant
layer
that
helps
us
optimize,
those
Communications,
secure
them
and
and
see
what's
going
on.
But
let's
talk
about
service
mesh
specifically
and
see
how
this
helps
so
in
service
mesh.
There
are
three
key
things
that
it
provides.
A
I
mentioned
it
already
connectivity,
the
security
aspect
and
the
observability,
but
in
order
to
do
so,
it
uses
something
called
a
sidecar
proxy,
so
you
have
kubernetes
which
communicates
with
something
called
a
control
plane
or
the
istio-d
control
plane,
because
we're
talking
about
istio
in
this
case
and
istod
acts.
As
your
point
of
configuration,
your
point
of
management,
with
respect
to
how
your
side,
cars,
operate
your
side,
cars
are
something
that
are
deployed.
A
These
are
these
little
artifacts
that
are
deployed
alongside
your
main
application
container
and
they
do
all
the
routing
all
the
request,
responses
for
that
service
or
on
behalf
of
that
service.
But
here's
the
thing
if
you
look
on
the
very
far
left
there
there's
so
many
different
services
that
are
running,
let's
say
inside
of
your
environment
and
every
service
that
you
have
gets
a
sidecar,
so
that
consumes
CPU
and
memory.
Also,
when
you
think
about
this
from
an
operational
standpoint,
what
actually
happens
when
you
onboard
services
that
you
already
have
deployed
into
a
service
mesh?
A
You
actually
have
to
restart
your
services,
and
that
is
impactful.
That's
a
service
impact
at
that
point,
which
means
there
could
be
an
outage
or
you
actually
have
to
schedule
a
maintenance
to
take
these
Services
offline
for
a
short
period
of
time,
so
that
they
can
come
back
online
with
your
sidecar
now.
In
order
to
get
away
from
this,
there
were
so
many
different
approaches
out
there,
but
I
will
say
that
solo
and
Google
work
together
to
develop
something
called
ambient
mesh,
a
sidecarless
approach.
A
Now
this
sidecarless
approach
means
the
sidecar
proxy
itself
is
no
longer
deployed.
However,
all
the
capabilities
of
the
istio
service
mesh
still
exist.
How
is
this
possible?
So
if
you
actually
look
on
the
far
right
diagram
there,
we
have
two
things
called
The,
L4
proxy
and
then
the
L7
proxy.
If
you
actually
combine
these
two,
this
is
your
sidecar
except
we've.
Just
moved
it
away
from
the
actual
workload
itself.
A
Now
the
layer
4
proxy,
which
we'll
refer
to
as
the
Z
tunnel,
going
forward
basically
acts
as
the
sidecar
on
behalf
of
multiple
workloads
that
exist
on
the
same
node.
So
the
Z
tunnel
is
a
Daemon
set
and
effectively
will
provide
layer,
4
connectivity,
layer,
4
authorization
policies
as
well
as
mtls,
so
that
you
can
still
provide
encryption
between
your
services
that
are
communicating
with
each
other.
Then,
when
you
decide
you
want
layer,
7
authorization
or
you're
you're,
trying
to
capture
some
level
of
observability
at
that
layer.
A
This
is
where
you
would
deploy
a
layer
7
proxy,
which
we
refer
to
as
the
Waypoint
proxy.
Now
the
Waypoint
proxy
is
is
still
based
on
if
you're
familiar
with
Envoy
the
envoy
proxy,
which
effectively
has
always
been
the
basis
for
How
We
Do
service
mesh
with
istio.
However,
with
the
Z
tunnel
or
the
layer
4
proxy,
we
actually
developed
a
lightweight
rust-based
proxy
to
strictly
focus
on
layer,
4
connectivity
in
that
mtls.
A
The
reason
behind
this
was
to
optimize
how
this
would
work
to
reduce
the
footprint
of
the
actual
side
car
itself,
just
to
focus
on
those
two
key
features
and
then
still
ensure
that
we
provide
full
service
mesh
functionality.
Now,
how
does
this
look?
If
we
actually
decide
hey,
we
want
to
deploy
Edge
Computing.
We
also
want
to
use
a
service
mesh
and
then
we
decide.
Oh,
we
have
multiple
clusters
enter
multi-cluster
ambient
mesh,
so
ambient
mesh
is
sidecar
lists.
A
Multi-Cluster,
ambient
mesh
or
multi-network
ambient
mesh
is
the
same
thing
except
now:
you're
scaling
with
so
many
different
kinds
of
clusters.
They
could
be
kubernetes
clusters
that
exist
in
your
Cloud
platform
that
you've
built
so
that
you're,
using
as
a
service,
these
could
be
data
center,
kubernetes
clusters
or
even
Edge
clusters.
But
the
interesting
thing
here
is
the
way
this
all
works.
A
A
Maybe
something
like
k3d
or
maybe
kind
I
mean
kind
is
not
super
production,
but
you
consider
the
fact
that
you
want
to
use
something
lightweight
that
doesn't
consume
a
lot
of
resources,
but
still
provide
you
the
functionality
of
kubernetes,
and
then
you
also
want
to
consider
yeah.
You've
got
your
cni
layer,
but
your
istio
ambient
mesh
layer
as
well,
so
that
gets
deployed
into
the
cluster.
There
are
a
few
components
that
do
get
deployed
like
istio
d,
as
well
as
your
z-tunnel,
because
you
need
it
between
different
nodes
as
well
as
the
Waypoint.
A
If
you
decide,
you
want
layer,
7
authorization,
there's
also
one
more
thing
that
gets
deployed
that
maybe
you
all
have
never
really
seen
before,
but
it's
called
istio
cni
and
it
actually
acts
as
the
mechanism
to
Route
traffic
into
the
Z
tunnel
from
The
Source
workload.
So,
let's
just
say
in
this
environment
book
info
is
split
up
into
two
different.
You
know:
clusters
book
info
is
just
a
bunch
of
microservices
that
produce
a
page
that
tells
us.
A
A
Well,
obviously,
we'll
need
access
to
a
load
balancer,
because
that
load
balancer
gives
us
that
external
connectivity
inbound,
but
the
other
thing
that
gets
deployed
is
something
called
the
East-West
Gateway
in
istio,
so
the
East-West
Gateway
Services
traffic
that
goes
either
from
one
cluster
to
the
next
cluster
and
ensures
that
we
could
get
traffic
all
the
way
through
and
ensure
that
requests
make
it
through
the
through
the
mesh.
Now
how
this
all
works
is
Z
tunnel
is
co-located
with
the
workloads
or
the
source
workloads.
A
The
identity
is
captured
of
a
source
workload
shared
with
z-tunnel
so
that
it
can
impersonate
its
ID
Z
tunnel
will
will
basically
indicate
to
the
other
end
to
the
destination
side.
Hey
you
know,
I
have
a
node
that
or
sorry
I
have
a
service
that
needs
to
communicate
with
you
now
that
service,
communicating
with
that
destination
workload
needs
to
pass
through
a
few
things,
and
if
you
actually
follow
the
red
line
book
info
is
communicating
with
a
z
tunnel.
Z
tunnel
is
actually
tunneling
to
the
East-West
Gateway.
A
The
East-West
Gateway
is
tunneling
to
that
to
a
destination
Z
tunnel
which
you're
not
seeing
the
Z
tunnels
right
now,
but
finally,
the
traffic
is
unencap
or
sorry.
The
traffic
while
it
is
encrypted,
is
actually
unencapsulated,
so
it
could
be
passed
directly
to
the
other
services.
The
reverse
is
entirely
possible
too.
So
what
you
actually
have
here
is
tunneling.
Are
you
all
familiar
with
ipsec?
A
Yes,
can
I
get
some
nods
sure
this
is
very
similar
to
how
ipsec
works?
Now,
interestingly
enough,
if
you
see
this
red
line
that
follows
all
the
way
through
to
the
East-West
Gateway
and
into
book
info,
this
is
actually
double
encapsulation
that
we're
doing
here
now,
I'm
going
to
pass
it
to
Kevin,
because
Kevin's
going
to
explain
a
little
bit
more
about
this
double
encapsulation
and
why
we
do
it
with
Z
tunnels
and
East-West
gateways.
A
B
B
B
One
of
the
things
that's
majorly
different
about
what
we're
able
to
do
here
is
that
when
we
look
at
this
request
flow,
we
go
from.
You
know.
One
Z
tunnel
is
all
we
need
in
our
local.
You
know
Edge
device
or
cluster
right
and
everything
else
lives
in
your
remote,
which
could
be
your
cloud
and
another
Network.
We
want
to
make
sure
that
these
communications
are
secure.
The
real
goal
here
is
to
get
mesh
like
functionality.
B
You
know
standardize
but
bring
it
to
Edge
devices,
and
we
part
of
the
reason
we
can
do
this
or
what's
improved.
Is
that
zetano
or
the
zero
trust
tunnel
is
implicitly
designed
to
be
very
minimalistic.
The
XDS
configure
is
tailored
to
this
use
case.
It
runs
on
the
order
of
megabytes,
whereas,
like
a
simple
Envoy
runs
much
larger
right,
and
this
means
that
we
can
bring
mesh
functionality
to
devices
at
a
much
lower
cost
than
we
could
before
further.
B
We
can
do
it
more
securely
than
we
used
to
if
you're
familiar
with
istio
and
how
multi-cluster
works.
For
you
know
the
classic
sidecar
model
they
would
do
like
Sni
routing,
there's
some
potential
issues
there
with
being
able
to
like
DDOS
backing
pods.
There's,
no
validation
done
once.
You've
reach
the
remote
Network.
We
improve
on
this
model
here
with
istio
ambient
multi-cluster,
because
we
do
this
double
Tunnel
right.
So
the
there
the
tunnel
has
two
TLS
encryptions
and
two
different
identities.
The
outer
one
is
on
the
right
you
can
see.
B
We
have
H
bone
outer
and
enter
H
bone
is
just
the
istio
protocol.
It's
basically
an
HTTP
connect
tunnel.
It's
just
stands
for
hdb
based
overlay
Network
and
that's
basically,
what
we're
building
here
these
this
network
of
Z
tunnels
are
basically
an
overlay
Network,
and
this
allows
us
to
standardize
and
bring
our
Edge
devices
to
a
like,
broader
network.
B
If
we
want
to
right,
we
can
do
all
of
our
compute
locally
and
you
know
on
the
edge
device
and
then
phone
home
you
know
periodically
when
we
need
to
securely,
and
so
that
outer
identity
is
the
Z
tunnel
identity.
It
allows
us
for
to
do
connection
reuse.
If
that
doesn't
verify,
we
kill
the
connection,
and
then
the
inner
tunnel
goes
to
the
final
destination,
in
this
case
service,
B
yeah.
That's
the
for
this.
A
Slide
awesome,
so
one
of
the
biggest
challenges
is:
if
you
try
to
do
istio
multi-cluster
at
scale,
it
actually
is
very
challenging.
There's
a
lot
of
different
elements
you
have
to
consider.
One
of
them
is
actually
trust.
Another
one
is
Automation
and
how
you
employ
something
like
gitups.
So
when
you
start
to
think
at
that
level
of
scale,
you're,
not
just
using
a
single
cluster
with
istio
or
even
istio
ambient
mesh,
or
even
a
single
edge
environment,
you're.
Actually
thinking
about
multiple
Edge
environments,
you
have
to
start
thinking.
Okay.
A
How
can
I
manage
this
under
a
single
platform?
So
sorry,
I
have
to
plug
glue
platform,
because
glue
platform
enables
this.
It
takes
a
git
Ops
approach
to
ensuring
that
you
could
run
multiple
clusters.
Multiple
Edge
locations
still
have
istio
ambient
mesh
in
place,
but
you're
actually
using
a
centralized
control
plane
to
push
out
configurations.
So
if
you
look
up
at
the
very
top,
we
use
glue
platform
to
provide
a
set
of
crds
that
effectively
translate
into
istio
resources.
A
Now,
as
long
as
I
configure
this
single
set
of
crds,
this
gets
applied
to
the
necessary
Edge
locations
as
I
would
need
it
to
and
because
of
that
now,
I'm,
actually
simplifying
My
overall
operations,
because
onboarding
becomes
easier
lifecycle.
Management
of
my
environments,
running
istio,
becomes
significantly
easier
and
now
I
can
see
literally
every
single
environment
under
the
same
observability
platform.
A
So
if
you're
starting
to
think
about
that
scale,
especially
when
it
comes
to
service
mesh
and
Edge
Computing
check
out
glue
platform
so
with
that
I'm
actually
going
to
pass
it
to
Kevin
to
actually
run
a
quick
demo
and
he's
actually
going
to
show
you
how
ambient
mesh
works
in
the
multi-cluster
multi-network
environment.
Take
it
away,
Kevin.
B
So
yeah
have
I
taken
the
liberty
of
kind
of
setting
up
two
clusters
here
for
us
to
take
a
jump
into
the
first.
One
here
is
basically
like
representing
our
our
remote
Cloud
cluster.
So
this
is.
We
can
look
at
all
the
pods
that
we
have
in
here.
We
have
default
namespace
with
details
product
page
ratings.
This
kind
of
just
is
the
classic
istio.
You
know
example
product
like
service.
It's
not
it's
not
really
that
relevant,
except
that
we're.
This
is
what
we're
going
to
query
at
the
end.
B
You
know
we're
going
to
phone
home
to
a
remote
service
and
just
like
Mourinho
talked
about,
we
have
the
cni
nodes.
This
Ingress
Gateway
is
our
our.
You
know:
Ingress
Gateway.
This
is
an
Envoy
proxy
and
then
we
have
the
Z
tunnels,
which
are
the
zero
trust
tunnels
and
then
in
our
remote
cluster.
You
know
in
our
Edge
cluster,
it's
much
more
minimal,
so
we
just
have
istio.
We
really
didn't
need
the
Ingress
Gateway
here,
but
we
have
a
sleep
pod.
B
This
is
just
representing
like
one
process
that
we
want
to
run
on
an
edge
device
and
then
everything
else
is
very
limited.
Z-Tunnel
is
just
you
know
the
only
other
component
that
you
really
need
to
go
ahead
and
phone
home
and
it's
getting
all
that
configuration
pushed
down
by
istio
D,
and
so
if
we
want
to
go
ahead
and
set
this
up
so
that
we
can
go
ahead
and
you
know
phone
home,
let's
go
ahead
and
apply
some
configuration.
I'm
gonna
have
to
scroll
through
this.
B
So
we
can
take
a
look
at
everything
here,
starting
from
the
top,
we
have
an
initio
Gateway
which
tells
us
to
configure
our.
You
know:
Ingress
gateway
to
listen
on
Port
15008
for
h-bone.
This
is
going
to
help
us
be
the
destination
for
our
traffic
for
decapsulating
that
outer
H
bone.
We
mentioned
briefly,
you
know
a
Double
encapsulated
H
bone.
This
is
telling
us
to
listen
and
decapsulate
that
outer
one
you
know
validate
that
we
Veritas
traffic
is
coming
from
within
the
mesh,
and
then
we
have
a
service
entry
here.
B
B
You
know,
istio
is
identity
based.
We
use
spiffy
for
identities,
that's
all
standard
and
built
in,
and
then
that
app
is
going
to
select
here
this
workload
entry,
this
brickland
entry
in
our
environment.
You
know
this
addresses
the
address
of
the
East
West
Gateway.
In
this
example,
you
know
predetermined
that
this
is
the
IP
that
we're
going
to
be
using.
B
B
And
then
we
can
go
ahead
and
make
a
request,
and
what
we're
going
to
see
here
is
it's
hard
to
read.
But
what
I
want
to
highlight
here
is
so
we're
making
a
request
to
the
service
entry.
I
o
that
that
service
entry
host
that
we
had
defined
on
90
80
to
the
product
page.
The
idea
here
is
that
we
want
to
hit
that
Ingress
Gateway
and
get
in
the
first
cluster
and
then
that
service
in
that
first
cluster.
B
We're
actually
failing
that
request
because
of
a
TLS
verification
error,
the
self-signed
certificate's
kind
of
a
misleading
error
here,
but
basically
what
we
we
didn't
do
here
is
we've
got
two
disjoint.
You
know
istio
configurations.
We
need
to
unify
our
root
of
trust,
because
this
is
a
demo
I'm
going
to
be
lazy
and
just
copy
that
secret
from
two
to
one.
But
realistically
we
would
have
generated
those
secrets
with
the
same
root
trust
so
now
that
we've
gone
ahead
and
done
that
we
should
be
able
to
move
beyond
that
that
error
for
making
requests.
B
We
see
a
TLS
error,
but
now
we're
getting
a
different
one.
So
again,
I
talked
a
little
bit
about
we're
doing
double
validation
here
of
identity,
to
make
sure
that
our
traffic
is
secure
to
tls's.
We
can
see
here
that
we
have
a
sand
verification
error,
so
we're
basically
getting
the
wrong
identity.
You
can
see
that
we
expected
the
identity,
bad
Ingress,
Gateway
service
accounts,
but
we
got
a
good
account,
and
so
what
we
have
here
is
actually
a
misconfiguration
error.
B
If
we
look
on
the
left
at
the
service
entry
that
we
had
applied
earlier,
you
can
see
that
the
subject-
alt
name-
has
bad
Ingress
Gateway.
You
know
this
is
about
it.
You
know
configuration
error,
something
that
maybe
we
could
you
know
improve
upon
if
it
were
generated
or
handled
for
us
by
a
platform.
But
if
we
want
to
go
ahead
and
comp,
you
know
fix
this
error,
we
can
apply
the
new
resource
and
if
we
do
that.
B
So
now
that
we
fixed
that
error,
we
can
do
the
same
thing
and
again
we're
going
to
get
an
identity
error,
but
just
to
highlight
that
we've
done
a
double
tunnel
here.
This
error
is
actually
a
different
one.
It's
still
a
San
error,
but
now
we've
actually
got
an
error
validating
the
inner
tunnel,
so
we've
actually
detuniled
the
outer
one,
and
now
we
can
see
that
we
have
a
bad
value
for
the
the
surface
account
on
the
the
default
namespace
and
this
this
identity
value
came
from
the
workload
entry
which
was
which
was
here.
B
We
had
again
misconfigured
our
Resources
with
a
bad
value.
If
we
go
ahead
and
correct
that,
then
we
should
be
good
to
go
and
I
expect
this
to
work
beautiful
awesome.
So
we
got
a
request
served
by
review
Z1.
This
is
like
a
full
web
page.
We've
kind
of
successfully
demonstrated
here
that
we're
able
to
use
H
bone
and
go
to
our
East-West
Gateway
make
a
multi-network
request
with
istio
ambient,
and
you
know
that's
that's
what
we
have
here
for
the
demo.
A
Awesome,
thank
you
so
much
Kevin,
so
if
you
just
saw
all
of
that,
would
you
be
willing
to
sit
there
and
do
this
a
thousand
times
over
for
all
your
Edge
locations,
nope
nope?
This
is
why
this
is
exactly
why
I
think
you
all
should
come
talk
to
us,
the
solo
Booth,
to
learn
a
little
bit
more
about
blue
platform
and
how
we
simplify
this
process.
Kevin.
A
Can
you
switch
back
to
the
presentation
so
I
want
to
just
tie
off
here
with
a
few
Edge
use
cases
I'm
not
going
to
enumerate
or
list
them
all
out,
but
I
want
you
to
think
if
you
currently
are
working
for
an
organization
that
maps
to
any
one
of
these
use
cases.
Yes,
I'm
sure
you
can
certainly
figure
out
the
edge
Computing
piece
of
it,
but
when
it
actually
comes
to
the
networking,
I
will
be
very
honest
with
you.
A
You
will
struggle
unless
you
consider
something
production
grade
like
a
service
mesh,
so
come
chat
with
us,
learn
a
little
bit
more
about.
If
you,
if
you
don't
know
how
to
service
mesh
Works,
come
learn
from
us,
we
can
teach
you
a
little
bit
more
about
it.
We're
going
to
be
here
at
kubecon
for
the
next
few
days.
Kevin
and
I
are
just
going
to
be
hanging
around
the
booth.
A
We
actually
I
will
say
I'm
actually
doing
a
workshop
tomorrow,
which
I
think
you
all
should
come
to
it's
about
Network
foundations,
and
that's
also
going
to
set
you
up
to
understand
how
a
service
mesh
works.
I
can't
remember
where
it
is
it's
somewhere,
but
it's
one
of
the
first
workshops
in
the
morning
come
check
it
out,
but
I
just
want
to
say
to
wrap
up
when
you
think
about
Edge
Computing.
It's
not
just
about
the
number
of
resources
you
have
available
on
your
your
system.
A
It's
not
just
about
the
kinds
of
apps
that
you're
going
to
deploy,
but
it's
also
about
the
the
platform
that
you
have
to
consider.
If
you're
going
to
be
managing
multiple
environments,
it's
also
about
the
fact
that
you
have
various
different
connectivity
options,
but
these
connectivity
options
present
their
own
challenges.
A
If
you
actually
look
want
to
look
more
about
or
want
to
look
into
more
about
istio
ambient
mesh,
there's
an
e-book
that
you
can
download
as
well
or
come
by
our
booth,
we
probably
might
have
a
whole
bunch
waiting
for
you
and
finally,
if
you
want
to
learn
more
about
application,
networking
hit
up
solo.
Academy
I
want
to.
Thank
you
all
for
your
time.
I
want
to
thank
Kevin
for
an
excellent
demo.
I
wish
you
all
an
amazing
Kube
Edge
day
and
a
kubecon
thanks.
Everyone.