►
From YouTube: Envoy Proxy is Your Gateway to Service Mesh
Description
A slight change in schedule for October - Join us virtually on the 3rd Wednesday of the month, October 21st for a guide to Envoy from Lawrence Gadban of solo.io!
Kubernetes and Service Mesh are patterns in building new applications that decouple dependencies between the application code, infrastructure and how the services should communicate. With microservices, the network becomes critical for a properly functioning application teams need to consider both North / South traffic (incoming requests from end users to the cluster) and East / West (intra cluster) communication between the services. In this talk we'll dig into the role of Envoy as the modern data plane for north/south and east/west traffic, their integration points, the respective control planes, and areas of extensibility.
https://www.meetup.com/orchestructure/events/273409528/
A
A
A
This
we've
had
a
relatively
steady
stream
of
presenters
who
have
come
to
us
wanting
to
talk
even
in
this
time,
and
yes,
bob
is
very
burned
out
and
and
by
the
way
we
are
going
to
use
slack
our
slack
channel
hashtag
orchestra
in
the
main
a2
slack
network.
If
you
want
to
ask
questions
or
provide
feedback
or
just
tell
bob
how
great
he
looks
today,
but
you
know
it's
you
guys
that
make
this
possible.
It's
the
reason
that
we've
gone
on
this
year
doing
virtual
events.
A
We
very
much
consider
not
doing
them,
and
you
know
how
much
value
are
people
really
getting?
I
think
at
this
point
we've
done
enough
and
people
are
probably
a
little
tired
of
these
sorts
of
things,
and
so
I
think
a
little
break
is
needed
and
with
the
holidays
coming,
I
just
want
to
say
from
from
all
of
us
at
orchard
structure.
I
hope
everyone
has
the
best
safest
holiday.
You
can
and
we
all
we
all
love
you.
A
We
miss
you,
I'm
really
hoping,
and
I
and
the
team
is
really
hoping
that
we
can
do
something
in
person.
Maybe
in
q1
of
next
year
we'll
see
how
things
go.
Obviously,
safety
is
kind
of
our
primary
concern
here,
but
I
want
to
thank
all
of
you.
It
really
means
a
lot,
the
feedback,
the
the
tweets
that
I
get
and
you
know
we
we
couldn't
do
this
without
you.
A
So
thank
you
for
that
and
thank
you
for
tuning
in
I'm
gonna
shut,
my
mouth
and,
as
you
can
tell
I'm
a
great
cncf
ambassador,
kubecon
cloudnativecon
north
america
is
coming
up.
We
just
got
done
with
eu
and
there's
other
re
invents
and
a
ton
of
other
stuff.
That's
that's
going
on.
Boyton
just
happened.
A
A
We
want
to
still
communicate
as
much
as
possible.
In
slack,
I'm
still
doing
you
know,
google
meets
with
people
in
the
evening,
sometimes
catching
up
with,
with
long-term
members
and
and
the
people
that
have
really
helped
us
through
throughout
the
way
find
our
way.
So
thank
you
to
everyone.
We
hope
you're
doing
well
and
you're,
staying
safe
with
that,
I'm
going
to
shut
my
mouth
and
give
it
over
to
lawrence
at
solo.I
o.
Take
it
away
lawrence.
B
A
B
B
B
Microservices
has
been
a
a
very
popular
topic
for
for
quite
some
time
now,
and
you
know
there
are
pros
and
cons
to
it,
but
at
this
there
there
are
some
really
valuable
benef
benefits
that
that
going
to
a
micro
service
approach
bring,
and
some
of
them
are
technical.
So
you
know-
maybe
that's
you
know
you're
talking
about
when
you
have.
B
If
that's
in
a
monolithic
infrastructure,
you
know
you
have
to
you
when
you
make
a
change,
you're,
deploying
that
entire
unit,
you
know
so
you're
talking
about
batching
up
a
bunch
of
changes
and
scheduling
a
friday
night
deployment
right
and
so
microservices
help
with
that
type
of
you
know
alleviating
that
type
of
need,
and
some
of
the
benefits
are
organizational.
So
prior
to
solo,
I
worked
at
a
very
large
financial
services
company
and
you
know
what
what
what
you
see
in
most
organizations
that
I've
worked
with.
B
In
my
experience,
is
you
know
you
have
you
know,
teams
that
are
that
are
broken
up
and
the
the
logical
way
of
breaking
up
the
teams
is,
you
know
you
give
them
a
piece
of
functionality
right,
so
there's
a
search
team
or
a
billing
team
or
or
whatever
right,
and
that
that
just
makes
sense
from
an
organizational
point
of
view
and
one
of
the
things
that
going
to
a
more
service-based
architecture
enables
is
now
you
can
say:
okay,
this
team,
the
search
team.
You
know
they're
gonna
own
from
from
top
to
bottom.
B
Everything
relates
to
search
or
for
billing
or
for
accounts
and
and
what
that
enables
is
now
the
teams
can
do
with
their
own
pace
and
now
they
can
make
their
own
technology
decisions
etc,
and
so
there's
a
lot
of
benefit
to
to
doing
that.
Because
you
know
developer
velocity
is
one
of
the
most
important
things
you
can
have
right
and
happy
developers.
Is
you
know
good
for
everybody,
so
you
know
there's
a
lot
of
reasons
that
people
are
going
through
this
journey,
but
it
isn't
something
that
solves
everything
right.
B
So
you
know
in
this
in
this
visual
we're
looking
at
you
know,
monolith
to
microservices
and
then
to
throw
another
thing
into
the
mix
right
you're
talking
various
clouds
right.
There
may
be
different
platforms
in
play,
and
you
know
this
doesn't
even
include
on-prem
right.
You
still
probably
have
some
on-prem
stuff
to
worry
about,
and
so
what
you
need
to
consider.
There
are
a
lot
of
things
that
come
into
play
when
you're
talking
about
going
to
this
architecture,
one
of
which
is,
you
know.
How
do
you
manage
api
so
before?
B
If
you
just
had
a
single
monolithic
application
right,
you
you
had,
you
didn't,
have
to
worry
about.
Okay,
now,
I'm
exposing
20
different
entry
points
into
my
infrastructure
and
now
you're
exposing
apis
right.
So
you
need
to
manage
those
apis
and
kind
of
along
that
same
that
same
topic.
You
know:
how
do
you
enforce
security
now,
you're
introducing
you
know,
20
different
entry
points.
You
know
20
different
apis
you're
exposing
and
if
everything
is
a
network
hop,
you
know
and
you're
jumping
from
on-prem
to
cloud
and
vice
versa.
B
Right
security
is
very
important,
and
so
you
need
to
you
need
to
be.
You
need
to
be
sure
that
you're
you're
properly
enforcing
your
security
and
that
obviously
changes
based
off
your
organization,
but
but
I
would
be
very
surprised
if,
if
you
don't
have
you
know
more
security
constraints
or
more
security
concerns,
when
you
go
to
a
cloud-native,
microservice
type
of
deployment
and
then
one
of
the
other
things
that's
important
is
is
how
do
you
observe
this?
B
So
you
know
what
used
to
be
just
a
bunch
of
function,
calls
or
whatever
in
in
a
single
application.
Now,
you're
talking
about
20,
different
service,
hops
right,
so
20
different
network
hops,
you're,
jumping
to
different
pods.
If
you're
talking
in
kubernetes
right,
you
may
be
going
from
on-prem
to
public
cloud
and
you
need
a
way
to
observe
all
of
that
traffic.
You
know
again
going
coming
from
my
previous
employer,
you
know
when
you,
when
you're,
trying
to
when
you're
trying
to
troubleshoot
an
issue.
B
That's
that's
related
to
you
know
a
micro
service
style
deployment.
It
can
very
quickly
get
you
know
very
overwhelming
and
very
very
hard
to
troubleshoot,
and
so
you
need
some.
You
need
tools
to
help
you
with
the
fact
that,
okay,
now
I
have
you
know,
I
need
to
look
in
20
different
places
to
figure
out
what's
going
on,
and
so
you
know
with
with
these
challenges
that
come
with
the
microservice
style
architecture.
B
You
know,
one
of
the
common
tools
that
has
come
into
into
play
is
the
service
mesh
right
and
service
mesh
is
something
that's
also
become
very
popular,
and
it's
something
that
you
know
it's.
It's
very
hype
right
now,
which
is
great.
I
mean
it's.
It's
an
awesome
piece
of
tooling
and
the
the
way
that
it
works.
You
know
kind
of
at
the
high
level.
B
Right
is,
if
you
have
a
bunch
of
services
talking
to
each
other
right,
the
the
service
mesh
is
trying
to
solve
all
the
challenges
we
were
just
talking
about
by
by
putting
a
piece
of
networking.
You
know
software
that
lives
alongside
your
application
right.
So
in
this
diagram,
this
is
kind
of
the
the
standard,
kubernetes
and
envoy
deployment,
where
you
have
a
kubernetes
workload.
B
So
you
know
you
have
a
pod
right,
you
have
you,
have
your
application
container
running
in
a
kubernetes
pod
and
then,
alongside
of
it
and
kind
of
the
sidecar
pattern,
is
an
envoy
proxy
and
and
this
helps
because
now
you
have
the
envoy
proxy,
that's
responsible
for
all
of
the
network
communication
between
these
various
services,
and
so
so.
This
is
a
nice
solution
to
to
trying
to
solve
kind
of
the
you
know
the
the
distributed
service
model.
B
In
order
for
this
to
work,
though,
you
need
to
give
the
envoy
proxies,
or
you
know,
if
you're
not
using
envoy,
that's
fine,
but
you
need
something
that
drives
the
configuration
for
these
proxies.
These
sidecar
proxies
because
they
need
to
know
the
state
of
you
know
what
so
you
how
you're,
however,
you're
configuring,
your
your
infrastructure,
then
you'll
be
able
to
in
inspect
your
infrastructure.
In
order
to
understand
you
know,
what
can
I
even
route
to
you
know?
B
How
do
I
find
these
various
locations
that
I
need
to
route
to,
and
so
that's
the
job
of
the
control
plane
right.
So
the
control
plane
is
something
that
will
watch
the
underlying
infrastructure.
So
for
talking
kubernetes,
you
know
the
control
plane,
something
that's
you
know
inspecting
or
it's
talking
to
the
kubernetes
api,
and
it's
getting.
You
know
relevant
information
for
one.
How
do
I
configure
my
mesh
and
two?
You
know
what
services
do
I
have
available
right?
B
What
endpoints
do
I
have
available
to
route
to
and
the
control
plane
is
responsible
for
understanding
that
and
sending
that
data
to
these
sidecar
proxies
so
that
they
are
as
up-to-date
as
they
can
be,
and
then
you
know
when
you're
taking
a
step
back
and
looking
at
kind
of
a
whole
topology
of
something
like
this
right.
You
have
a
handful
of
services
or,
however
many
services
you
have
running
in
your
cluster
and
those
services
have
onboard
proxies
or
you
know,
proxies
side
card
with.
B
You
know
that
that
go
along
and
that's
how
the
network
communication
happens,
and
then
you
have
that's
the
east-west
component
of
a
service
mesh
right,
but
there's
also
a
north-south
component
to
it,
and
that
that
is
how
does
traffic
even
get
into
the
mesh,
and
that
can
be
from
say,
a
client
that
could
be
from
another
piece
of
infrastructure.
So
that
could
be
your
legacy.
You
know
on-prem
infrastructure
whatever,
but
you
still
need
to
get.
You
still
need
to
get
traffic
into
the
mesh
right
for
for
the
for
the
east-west
traffic
to
be
useful.
B
Something
has
to
you
know.
Someone
has
to
initiate
that
that
the
reason
for
those
services
talk
to
each
other
right,
and
so
that's
that's
the
north
south
component
of
the
service
mesh,
and
so
you
know
again,
the
service
mesh
is,
you
know,
really
popular
tool
for
valid
reasons.
It
solves
a
lot
of
problems.
B
First
of
all,
do
you
even
need
a
service
mesh
and-
and
I
think
a
lot
of
folks
are
eventually
going
to
need
a
service
mesh?
I
think
what
we've
seen
you
know
as
I've
been
working
here.
You
know,
as
I've
been
talking
to
folks.
You
know
there
are
a
lot
of
valid
reasons
for
people
to
use
a
service
mesh,
but
maybe
they're
not
there.
Yet
maybe
they
don't
need
it
quite
yet,
and
so
you
need
to
ask
yourself:
do
I
actually
need
a
service
mesh
and
some
of
those
some
of
the
things
that
drive?
B
Those
kind
of
questions
are,
you
know,
do
you
have
a
mix
of
application,
languages
or
frameworks,
and
the
reason
that
question
is
important
is
because
most
of
the
things
that
you
are
most
of
the
features
that
you
need
out
of
a
service
mesh,
most
of
those
most
of
those
features
you
can
implement
inside
of
the
application
right.
So
one
of
the
you
know,
one
of
the
common
use
cases
for
a
service
mesh
is
fault
tolerance,
so
you
can
do
things
like
retries.
B
So
if
you
have
a
single
like,
if
your
organization
is
a
java
shop
and
everyone's
using
java,
you
know
you
have
some
standard
libraries
that
you
use.
You
could
easily
build
your
fault
tolerance
into
the
applications
themselves,
and
you
know
again
talking
java
right.
That's
where
the
histrix
library
from
netflix
comes
into
play.
I
think
that's
kind
of
you
know.
B
That's
been
sunsetted
it's
in
maintenance
mode,
but
there's
newer
ones
like
resilience
for
jay
right,
and
these
are
tools
that
that
provide
some
of
the
benefits
of
you
know:
service
meshes
fault,
tolerance
like
retries,
et
cetera,
and
those
are
built
into
the
into
the
actual
application.
Using
these
libraries-
or
maybe
you
build
a
custom
library
to
do
it,
and
so
that
you
know
that's
valid
right,
you
can
do
you
can
get
those
benefits
by
using
an
application
library.
B
So
if
you
have
a
single,
if
you
have
a
single
language
that
you
use
and
you
have
kind
of
a
standard
set
of
libraries
that
you
you
promote,
you
know
you
don't
maybe
you
maybe
you
don't
need
a
service
mesh
right,
you
might
be
able
to
get
the
benefits
of
it
without
having
to
introduce
a
service
mesh.
Once
you
start
talking
about
okay,
you
know
this
team
is
going
to
use
java.
B
This
team
is
going
to
use,
go
and
so
on
right
then
it
starts
to
get
more
tricky,
especially
if
you're
trying
to
custom
build
this
stuff,
because
now
you
have
to
implement
that
logic
in
you
know
two
or
three
or
four
or
five
languages,
and
then
it
quickly
goes
grows
out
of
control.
So
that's
when
you
might
think
okay,
you
know
what
a
service
mesh
might
be
beneficial
to
us.
B
Another
question
that
you
can
ask
is
you
know:
do
I
have
a
large
amount
of
microservices
in
general
because
if
you
only
have
you
know
10
to
20
or
so
services,
the
service
mesh
is
probably
overkill
for
that.
You
probably
don't
need
to
introduce
that
level
of
complexity
to
your
environment,
to
solve
10
services,
communicating
across
each
other.
So
but
but
you
know,
if
you
know
that
your
organization's
going
to
grow
or
you
you're
just
in
general,
in
a
large
organization,
you
know,
maybe
a
service
mesh
does
make
sense.
B
B
You
don't
really
need
a
service
mesh,
because
there's
no
reason
to
have
that
east-west
component
to
it
you're
just
you
know,
making
a
call
and
you're
going
through
maybe
a
gateway
whatever
and
you're
getting
your
result,
your
response
back
to
your
single
page,
client
and
in
that
case,
there's
no
need
for
a
service
mesh.
So
you
know
the
the
type
of
calls
that
are
happening
in
your
application,
that
that
makes
a
that
has
a
that.
B
Has
you
have
to
consider
that
when
you
decide
if
you
need
a
service
mesh
or
not,
and
then
finally
we
call
out
you
know,
are
you
comfortable
with
your
infrastructure
stack
and
the
reason
is
because
a
service
mesh?
So
again,
let's
talk
kubernetes,
you
know,
service
mesh
is
very
tightly
coupled
to
your
infrastructure
right.
So
when
you're
talking
when
you're
talking
istio,
you
know
you
have
side
cars,
you
have
all
of
the
kubernetes
type
of
configuration,
all
the
custom
resources
you
have.
B
You
know
you're
introducing
a
lot
of
additional
things
to
your
infrastructure
that
are
very
important
because
you're
talking
you
know,
service
service
calls
right.
So
if
something
goes
wrong,
you
could
very
quickly
be
hurting
from
a
from
an
availability
perspective,
and
so,
when
you
start
looking
at,
are
you
ready
for
a
service
mesh
having
having
a
good
grasp
of
your
infrastructure
is
very
important?
B
B
So
one
of
them
is,
you
know
which
one
to
choose,
so
we
already
mentioned
istio,
but
you
know
there.
There
are
quite
a
few
service
meshes
out
there.
I
will
say
that
istio
seems
to
be
kind
of
the
most
popular
one
right
now,
but
there
are.
There
are
lots
of
other
ones,
and
you
know,
for
example,
your
decision
may
be
your
your
decision
may
come
down
to
what
platform
you
run
on.
So
if
you're,
an
aws
company
in
aws
shop
and
you're,
you
know
you're
committed
to
running
everything
on
aws.
B
It
may
make
a
lot
of
sense
for
you
to
choose
app
mesh
right,
aws
app
mesh,
which
is
an
onboard
based
mesh.
So
if
you're
using
you
know,
managed
aws
services,
why
would
you
not
use
a
managed,
aws
mesh?
So
picking
the
right
one
is
is
also
something
that
you
have
to
consider,
and
maybe
you
know,
maybe
you
don't
want
to
you-
know
the
famous
vendor
lock-in
term
right
that
that
might
be
something
that
will
sway
you,
but
making
that
decision
is
important
because
migrating
off
of
a
service
mesh
is
not
something
that's
trivial
right.
B
So
you
want
to
you
know
it's
a
you
need
to
pick
the
right
one,
but
at
the
same
time
you
don't
basically
what
I'm
getting
is
it's
it's
challenging
to
decide
which
mesh
to
which
mesh
to
use
then
kind
of
related
to
that
is
who's
going
to
provide
support
to
it,
and
this
this
is
probably
more
relevant
to
you,
know
bigger
enterprises
or
companies
that
that
have
regular
regulatory
reasons
for
requiring
enterprise
support.
Basically,
you
know,
do
you
want?
B
Do
you
need
enterprise
support
for
your
mesh
and
if
so,
how
are
you
going
to
get
it
right?
So
so
this
may
kind
of
be
this
may
kind
of
be
an
easy
decision
for
you.
If
you're
talking
like
you
know
so,
for
example,
if
you're
running
open
shift
right,
openshift
has
a
it
has
its
own
flavor
of
istio.
I
think
it's
called
red
hat
service
mesh
now
and
that
you
know
that
comes
with
your
with
your
open
shift.
So
you
know
you,
you
may
already
have
the
choice
made
for
you.
B
You
may
decide:
okay,
I
need
to
go
red
hat
service
mesh
and
then
I'm
gonna
have
them
support
it,
but
then
what
if
you
want
to
use
a
feature?
That's
in
the
newer
version
of
this
deal.
That's
not
in
red
head
service
mesh!
So
it's
it's
kind
of
a
you
know,
there's
a
little
bit
of
trickiness
there
and
deciding
okay,
which
one
and
who's
going
to
support
it.
B
Another
challenge
is
multi-tenancy
and
the
reason
this
is
challenging.
If
you're,
not,
if
you
don't
have
a
multi-tenant
environment,
then
this
is
probably
not
relevant,
but
for
some
folks
that
do
have
multi-tenancy
in
place,
you
know
figuring
out
how
you're
going
to
solve
that
with
service
mesh
is
challenging
because
you
know:
are
they
all
going
to
participate,
participate
in
the
same
mesh?
How
do
you
ensure
that
they
can't
talk
to
each
other?
Then
you
get
into
things
like
okay?
B
B
Managing
multiple
clusters
is
an
interesting
one.
So
there
are
many
reasons
why
you
may
use
multiple
clusters,
the
the
most
common
of
which
that
I
can
think
of
would
be
if
you're
running
for
high
availability.
You
have
kind
of
replicated
clusters
in
different
regions
right,
and
so
you
have
a
mesh.
You
have
a
cluster
in
us
west
and
a
cluster
in
usbs,
and
you
have
a
mesh
installed
in
both
of
those,
but
it's
really
the
same
mesh.
What
happens
if
you
want
to
perform
a
failover
right?
B
B
The
next
one
would
be
delineation
between
developers
and
operations.
This
is
this
is
kind
of
a
nebulous
one.
But
ultimately
you
know
when
you
start
talking
about
some
of
the
features
of
mesh
right.
The
the
the
lines
get
a
little
blurry
between
developers
and
operations
and
that
in
general,
is
the
case
kind
of
with
the
way
that
everything
is
going
right,
the
whole
devops
model
and
it
makes
a
lot
of
sense.
B
So,
if
you're
going
towards
a
micro
service
approach,
which
you
know
probably
means
you're
going
to
towards
you
know,
a
team
will
own
from
top
to
bottom,
their
application
or
their
service.
That
means
that
they're
probably
responsible
for
the
the
quote,
unquote
operational
component
as
well
right
so
now
now
it
may
make
sense
for
them
to
own
all
of
the
configs
right,
so
they
own
the
fault,
tolerance
configs,
they
own
the
security
configs.
But
but
if
not,
you
know
basically
figuring
out
who
who
will
own?
B
What
in
a
service
match
service
mesh
gets
a
little
blurry
and
then
finally
legacy
hybrid
environments.
You
know
most
case.
In
most
cases
we
don't
have
the
luxury
of
going
pure
green
field
right.
So
you
have
to
you
have
to
consider
your
legacy
environments.
You
have
to
consider
working
in
a
hybrid
model.
You
have
to
consider
on-prem
and
public
cloud,
and
so
when
you're
going
service
mesh,
you
know
what
do
you
do
about
those
legacy
environments?
Are
they
part
of
the
mesh?
Are
they
not
part
of
the
mesh?
B
If
you
do
want
them
to
be
part
of
the
mesh
depending
on
which
mesh
you
choose,
you
know
that
that
can
be
a
tough
problem
to
solve,
and
so
you
know
really
really.
What
I'm
getting
at
here
is.
Just
you
know,
service
mesh
is
great.
It's
just.
There
are
a
lot
of
things
you
need
to
consider,
and
it's
not
you
know
it's
not
just
okay,
let's
just
say
we're
going
mesh
and
then
it
will
start
working
right
there.
B
There
are
some
challenges
and
problems
you'll
need
to
work
through,
and
then
you
know
one
of
the
things
that
you'll
you'll
consider.
This
is
kind
of.
You
know
kind
of
fun,
but
you
know
really
when
you're
talking.
Okay,
now
we
have
a
mesh,
and
now
every
service
can
talk
to
every
other
service.
You
can
quickly
get
into
this
death
star
architecture
where,
if
you
have
no
kind
of
logical
separation
of
the
services,
now
you
get
into
this
unmanageable
spaghetti
ball
of.
B
B
So
then
you
know
what
what
are?
What
are
some
options
that
that
help
with
kind
of
this
okay,
we
want
a
service
mesh,
maybe
we're
not
quite
ready
for
one
or
you
know,
you're
going
down
the
journey
and
it's
you
you
don't
want
to
fully.
You
know,
commit
you
say:
okay,
we're
going
to
install
the
mesh
in
our
cluster
and
we'll
figure
it
out
right.
B
So
we're
going-
let's
say
let's
say:
you're
going
some
new
services
or
you're
migrating
existing
service
and
that's
going
to
be
kind
of
your
basis
for
your
cloud
native
or
your
micro
services
model.
So
you
have
a
bunch
of
on-prem
stuff
and
then
you're
rewriting
one
of
those
services.
And
that's
going
to
be
your.
You
know
your
new
infrastructure
right.
B
So
if
you
start
with
a
gateway
model
right,
you
can
put
something
at
the
the
logical
edge
of
that
of
that
infrastructure
and
that's
something
that
you
can
use
to
kind
of
augment
and
complement
the
the
existing
setup.
And
so
now
you
can
start
routing
traffic
to
that
gateway
and
that
gateway
can
then
route
to
the
new
services.
B
So
we're
talking
the
journey
from
service
mesh
or
from
from
no
service
mesh
to
service
mesh
and
we're
saying,
okay,
we
want
to
introduce
a
gateway
either
way
you're
there.
There
are
different
concerns
when
you're
talking,
okay,
what's
inside,
of
the
mesh
versus,
what's
at
the
edge
and
and
we'll
go
through
some
of
those
right
now
so
again,
the
edge
kind
of
represents
that
north-south
traffic
right.
So
you
have
a
client
or
you
have
a
legacy
component,
whatever
it
is,
is
initiating
a
call
to
a
service
that
lives
in
your
mesh.
B
That
north-south
component
is
what
we're
talking
about
right.
Now,
that's
the
edge,
and
so
there
there's
definitely
some
overlap
between
north-south
and
east-west
there's.
There's
overlap
between
the
functionality
you
need
in
your
mesh
and
the
functionality
you
need
at
the
edge,
and
so
traffic
control
and
routing
is
kind
of
a
no-brainer
right.
You
need
to
be
able
to
route
your
traffic.
You
want
to
control
that
tls
mtls
very
important
in
general.
B
You
know,
as
we
talked
about
you
know,
as
you're,
going
to
a
hybrid
world
as
you're,
going
through
to
everything
as
a
network
call
network
encryption
is
very
important
right,
you
know.
That's
one
of
the
the
mtls
piece
is
one
of
the
main
benefits
of
using
a
service
mesh
right
now
you
can
get.
You
know
you
can
ensure
that
now
every
single
piece,
every
single
network
call
is
really
not
only
going
to
be
encrypted,
but
you're
also
validating
the
clients
right.
So
you
can
very
like
fine
tune,
very
much
control.
B
You
know
which
clients
can
talk
or
which
service
can
talk
to
each
other
right
at
the
edge.
You
still
want
that
level
of
control
right.
Maybe
you
don't
need
mtls
at
the
edge,
but
you
definitely
want
to
be
able
to
from
the
downstream
from
a
downstream
perspective,
but
you
definitely
want
that
to
be
network
encrypted,
and
then
you,
also
more
than
likely,
are
going
to
want
your
edge
component
to
be
able
to
mtls
into
the
into
the
mesh
right.
B
Otherwise,
it's
not
going
to
be
able
to
participate
in
the
mesh
observability
for
all
the
reasons
we've
talked
about
is
very
important
and
you
don't
want
to
have
a
missing
hop
right,
so
you
want
an
edge
component
that
that
can
participate
in
the
same
observability
that
the
mesh
can
and
policy
enforcement
kind
of
goes
alongside
with
the
tls
mtls
piece.
You
know
you
this
this
time
you
want
to
make
application
layer
decisions
right.
So
let's
say
you're
using
jots.
B
If
you
have
an
environment
where
the
jot
that's
used
at
the
edge
is
the
same
as
the
mesh,
then
that's
perfect
right.
You
can
just
either
you
can
enforce
that
the
jot's
present
on
an
ingressing
call
and
then
pass
that
along
and
every
single
hop
can
validate
that,
and
there
are
other
lots
of
other
ways
to
do
that
right.
So
open
policy
agents
becoming
more
popular,
but
there
are
a
lot
of
ways
of
enforcing
policies
right
and
you're
going
to
want
to
do
that.
B
B
So
a
lot
of
the
time
you
know
like
one
of
the
common
common
use
cases
for
ingressing
into
the
mesh
is
from
a
user-based
request
right
and
a
user-initiated
request,
and
so
I'm
I'm
a
user,
and
I'm
in
my
browser,
I'm
using
a
user.
My
browser
is
my
user
agent
and
I'm
going
to
access
my
website.
You
know
your
or
the
the
website
of
the
the
company
that
is
implementing
the
mesh
that
that
initial
call
that
oidc
component
is
is
user
facing
right.
It's
not
as
much.
B
It's
not
something
that's
going
to
happen
inside
of
the
mesh.
It's
something
that
happens
as
a
call
ingresses
into
your
cluster
and
so
at
the
edge
is
where
you
more
than
likely
want
to
do.
Oibc
right,
and
so
that's
not
something
that
that
is.
You
know,
that's
not
something!
That's
more!
That's
not
really
a
mesh
concern,
and
not
only
that.
B
It's
not
there's
not
a
there's,
not
really
an
an
accepted
or
standard
way
of
performing
something
like
oidc
within
the
mesh
I'll
caveat
that
there
and
say
that
there
actually
is
some
cool
work
being
done
to
to
do
that.
But
it's
not
quite
there
yet
web
application
firewall
is
similar
a
lot
of
the
times
your
concerns.
There
are
user
data
right
either.
You
know
untrusted
user
data
coming
into
your
system
or
the
user
data.
That's
going
or
the
data
that's
leaving
the
cluster
right.
B
So
you
usually
want
to
laugh
at
that
edge
layer
to
be
able
to
inspect
that
traffic,
and
you
know
you
want
to
deny
a
cross-site
16
request
or
something
like
that-
not
terribly
important
inside
of
the
mesh,
the
next
two
message:
transformation
and
api
surface.
Those
are
related
so
with
message
transformation.
B
What
let
me,
let
me
start
with
the
api
surface
surface
one.
So
so
a
lot
of
the
times.
The
api
that
you're,
exposing
at
the
edge
of
your
environment,
isn't
necessarily
a
one-to-one
mapping
to
the
internal
implementation
of
that
api
right.
So
you
have
you
know
the
way
that
you're
implementing
the
service
isn't
necessarily
what
you
want
to
expose
to
the
world
right.
You
want
your
api
to
be
defined,
for
ease
of
kind
of
you
know,
communication
right,
but
the
internals
may
be
something
different,
and
so
an
an
edge
concern
is
okay,
one.
B
How
do
I
expose
this
api?
You
know
in
a
user-friendly
way,
but
then
you
may
need
to
transform
the
message.
So
if
someone
is
making
requests
to
your
api,
you
may
need
to
massage
that
request
to
fit
the
internals
right
and
that's
that's
usually
done
at
the
edge
another
example
of
kind
of
message.
Transformation.
B
Let's
say
that
you
have
a
jot
that
you
know
or
a
json
web
token,
that's
on
the
request
and
that's
how
you're
performing
some
sort
of
authentication
or
even
authorization
and
the
the
the
concern
at
the
edge
is
that
you
need
to
make
sure
that
a
certain
claim
is
there
or
something
like
that,
and
so
you
could
do
that
at
the
edge.
But
then
you
may
have
a
need
for
that
that
claim
later
on
inside
of
the
mesh,
and
so
what
you
could
do
at
the
edge
is
okay,
I'm
going
to
validate
this.
B
This
job
is
present,
but
what
I'm
going
to
do
is
I'm
also
going
to
pull
out
the
claim
here
and
I'm
going
to
add
it
as
a
header
and
then
that
header
will
be
present
inside
of
the
rest
of
the
mesh
call.
So
you
don't
have
to
you
know
you
can
easily
do
what
you
need
to
do
with
that
data
without
having
to
worry
about
doing
it
at
every
single
and
then
rate
limiting
and
other
kind
of
security
concerns.
You
know
there
there
are.
B
You
know
in
this
case
a
lot
of
these
are
what
you
could
call
kind
of
table
stakes
for
proxies,
but
you
know
there's
also
a
lot
of
cool
things
that
envoy
does
pretty
much
better
than
others
than
the
others,
and
so,
like
the
customizable
load,
balancing
you
know,
fault
tolerance,
shadowing
rate,
limiting
all
that
stuff.
You
know
those
are
all
really
good
features.
B
So
you
you
have
a
config
file,
that's
you
know
some
sort
of
text
file
or
some
sort
of
you
know
whatever
format
and
that's
what
configures
the
proxy
and
then,
if
you
ever
want
to
change
it,
you
need
to
update
that
file
and
you
need
to
reload
the
proxy.
So
in
you
know,
h8
proxy,
for
example,
they
have
some
cool
stuff
and
I'm
sure
other
proxies
do
it.
But
it's
a
proxy
right.
You
can
modify
your
config
file,
reload
it
and
then
there
will
be
cool
thing.
B
B
So
things
are
changing
constantly
in
in
in
one
of
these
cloud
native
kubernetes
environments,
and
so
in
order
to
actually
provide
value.
The
the
proxies
that
you
use
need
to
be
able
to
accept
those
configuration
changes.
Dynamically
right
and
envoy
was
designed
with
the
from
the
ground
up
to
support
that.
So
you
can
configure
envoy
statically
and
that's
something
that
we'll
look
at
here
in
a
second.
But
you
can
also
do
everything
you
can
do
statically
with
a
dynamic
api
and
that
that's
really
powerful.
B
For
for
that's
how
service
mesh
works
right,
that's
how
using
envoy
as
a
gateway
work,
because
they
they're
getting
dynamically
configured
according
to
the
state
of
your
infrastructure.
You
don't
have
to
worry
about.
You,
know,
reloading
processes
and
making
sure
that
connections
are
passed
around
et
cetera
right
you,
you
get
the
benefits
of
the
fully
dynamic
infrastructure
inside
of
your
proxy,
and
so
this
is
kind
of
like
the
summary
of
like
what
what
we'll
use
envoy
as
when
it
comes
to
a
gateway
right.
So
you
introduce
that
api
kind
of
tier
at
the
front
side.
B
You
know
downstream
of
envoy,
but
then
you
get
all
the
benefits
of
envoy
on
the
back
side.
So
in
this
example
right
we're
using.
We
have
an
api,
that's
exposed,
and
you
know
it
may
route
to
the
monolith.
The
old
monolith
or
may
need
to
do
a
grpc
call
to
service
a
or
website
called
a
service
b,
and
maybe
you
want
to
do
some
percentage
of
traffic.
You
know
like
a
canary
or
blue
green
or
something
to
service
b.
B
B
It
can
pull
configuration
from
a
variety
of
locations,
kubernetes
or
console
or
flat
files,
and
since
it's
just
a
simple
container,
it
can
run
anywhere
pretty
much
and
then
it
dynamically
will
configure
your
envoy
data
plane
to
match
the
configuration
that
you
have
set,
and
so
finally,
one
of
the
sections
that
I'm
going
to
kind
of
skim
through
this,
but
it
is
important
to
kind
of
at
least
you
know,
visualize.
It
so
kind
of
the
initial
adoption
pattern
that
we've
been
talking
about
is
using
an
envoy
edge
gateway
or
proxy
edge
proxy
right.
B
So
in
this
case
we
have
glue
as
a
control,
plane
and
envoy
as
our
data
plane.
We
have
a
handful
of
services
that
are
running
inside
of
let's
call
this
a
kubernetes
cluster
and
we
have
five
services
here
that
are
running
in
three
different
name
spaces
or
something
right.
And
so,
if
you
only
you
know
your
first
step,
you
probably
will
not
have
that
many
services
right.
B
But
then
you
know
maybe
you're
growing
your
environment
and
you
start
introducing
a
bunch
of
workloads
because
you're
happy
with
how
how
the
you
know
envoy
and
how
your
kubernetes
migration
is
going,
and
maybe
you
need
to
start
introducing
some
decoupling
points
you
know
or
a
multi-tier
gateway
is
kind
of
what
this
can
be
called,
and
what
this
means
is
that
now,
rather
than
so
so
now
you
start
having.
You
know
east-west
calls
in
in
some
form
or
fashion.
B
B
However,
you
logically
want
to
break
this
up
right
and
this
is
going
to
be
very
dependent
on
your
organization,
your
architecture,
but
the
important
part
is
really
that
using
gateways
gives
you
flexibility
right.
It
gives
you
decoupling
points,
because
it
allows
you
to
introduce
a
a
point
where
you
can
control
the
traffic
right
and
whatever
that
means
in
your
environment.
B
You
can
do
that
with
with
kind
of
you
know,
tar
with
strategically
placing
gateways
in
your
in
your
architecture
and
then
kind
of
going
one
step
further.
You
know
this
is
kind
of
you
know
very
a
loud
slide,
but
you
know
when
you
start
talking
about
having
a
service
mesh.
Let's
say
that
you
have
three
different
service
meshes.
You
know
whether
or
not
the
same
cluster.
B
That's
fine,
but
you
still
have
kind
of
your
your
initial
ingress
tier
right
and
since
the
traffic's
flowing
through
here,
you
get
the
flexibility
to
route
the
traffic
cover
you
want,
and
then
you
know
again.
You
start
having
service.
East-West
traffic
service
service
calls
inside
of
your
meshes,
but
rather
than
having
everything
in
the
same
mesh
or
rather
than
having
everything
know
about
all
the
other
services.
B
These
decoupling
gateways
allow
you
to
introduce
logical
separation
right,
and
so
this
is
how
you
can
help
this
helps
you
avoid
that
death,
star
architecture
that
we
were
talking
about
earlier,
where
you
know,
if
every
service
calls
every
other
service,
it
can
quickly
spiral
out
of
control,
and
so
having
flexible
decoupling
points.
Allow
you
to
get
a
grasp
of
your
architecture
and
put
logical
boundaries
in
place
and
then
kind
of
looking
forward.
B
So
envoy
again,
you
know
awesome
tool
and
it
also
helps
enable
some
some
pretty
cool
capabilities
in
the
future,
and
the
future
is
not
that
far
off
at
this
point.
So
this
is
one
example
where
you
know
a
couple
of
other
tools.
We
have
at
solo
at
least
where,
as
you
start
growing
your
your
gateway
and
mesh
deployments
right,
you
probably
are
going
to
want
tools
to
help
manage
those,
and
so
you
know,
federation
of
gateway
and
federation
of
mesh
is
going
to.
B
We
think
going
to
become
more
and
more
important,
and
so
there
are
some
options
there,
but
but
really
you
can
utilize.
Some
of
the
awesome
features
of
envoy
like,
for
example,
local
locality
awareness
to
be
able
to
to
handle
things
like
failovers,
where
you
can
say.
Okay,
I
want
all
of
my
service
calls
to
stay
local
to
one
mesh
or
one.
You
know
whatever.
B
Whatever
that
boundary
is,
but
if
a
service
goes
down,
I
want
to
be
able
to
fail
over
to
another
one
or
if
I
have
a
zone
outage
right,
I
should
be
able
to
fail
over,
and
so
you
can,
as
you
start,
introducing
smarter
tools
on
top
of
something
as
powerful
as
envoy.
You
get
to
you
know,
talk
about
the
federation
and
the
failover,
and
you
know
envoy
enables
us
to
do
that
and
then
another
really
really
cool
piece
of
technology
is
web
assembly
and
specifically
using
extending
envoy
with
webassembly.
B
This
is
actually
something
that
just
recently
landed
in
upstream
envoy.
Where
now
you
can
so
the
the
main
way
that
you
configure
your
extend
envoy
is
through
writing
filters
for
it,
and
so
now
you
can
be
prior
to
prior
to
webassembly.
You
know
in
the
current
state
really
you
need
to
write
an
envoy
filter
as
in
c
plus,
and
you
need
to
build
that
into
on
the
on
void
binary.
But
web
assembly
allows
a
way
for
you
to
not
not
only
use
c
plus
plus,
but
you
know
any
language
in
theory.
B
It's
really
in
theory
any
language,
but
in
reality
it's
it's
any
language
that
can
compile
to
the
web
assembly
assembly.
That
envoy
expects.
But
you
can
write
filters
in
your
in
whatever
language
like,
let's
say,
assembly
script,
which
is
pretty
much
javascript.
But
you
know
it's
something
that
targets
webassembly,
that
works
in
envoy,
but
you
can
write
a
filter
in
assembly
script
and
then
you
can
dynamically
load
that
into
envoy,
so
you
don't
have
to
build
it
into
it.
B
So
it's
really
what
it
means
is
that
now
you
can
start
becoming
a
very
you
know
you
can
start
you
have
a
lot
of
customization
and
and
extendability.
It
opens
up
the
door
for
a
lot
of
that,
because
now
you
don't
have
to
compile
it,
you
can.
You
can
start
writing
modules
and
sharing
them,
and
you
know
you
don't
have
to
you:
don't
have
to
re
rebuild
envoy,
you
can
just
dynamically
pull
them
in.
B
So
this
is
going
to
open
up
the
door
for
a
lot
of
customization
of
envoy,
and
it's
really
you
know
we.
We
think
it's
going
to
be
really
powerful,
because
we
think
that
you
know
so,
as
as
we
work
with
folks,
you
know
that
are
using
glue
or
any
of
our
other
tools.
You
know
one
of
the
things
is
that
they
have
a
specific
use
case
to
them.
B
That
you
know
honestly
makes
a
lot
of
sense
for
their
their
organization,
but
it's
not
something
that
we
would
build
into
our
products
or
build
you
know,
so
we
wouldn't
take
that
that
functionality
and
build
it
into
a
general
purpose-
filter
for
example,
because
it
doesn't
quite
make
sense
in
any
other
organization
and
the
reason
that
they
don't
want
to
do.
It
is
because
there's
you
know
it's
not.
The
barrier
of
entry
is
fairly
high.
B
You
need
to
write
c
plus
plus,
and
you
need
to
take
on
the
build
process
yourself,
but
this,
the
web
assembly
capabilities
kind
of
you
know,
break
down
that
that
that
barrier
and
now
you
can
quickly
on
your
own.
You
know,
as
an
organization
customize
envoy,
customize
your
proxies
as
you
see
the
need
to
do
so.
B
Okay,
so
for
a
quick
demo,
what
I
want
to
show
is
the
key
to
all
of
this.
Stuff
is
envoy
right,
and
so
in
order,
in
order
to
really
understand
what's
happening
is
we
need
to?
We
need
to
understand
how
envoy
works
and
we
need
to
understand
how
to
configure
envoy
again,
one
of
the
main
value
propositions
of
envoy
is
the
dynamic
configuration,
and
so
what
what?
B
So
this
is
this:
is
it
it
is
what
40
48
lines
of
configuration
and
really
quickly
going
through
this?
What
what
the
the
environment
that
I'm
setting
up?
I
have
a
simple.
I
have
a
simple
json,
json
style,
api,
that's
called
pet
store
and
it
just
returned
some
json
and
what
I
want
to
do
is
route
to
it.
B
You
know
the
the
in
this
case
tcp
right,
which
is
really
just
moving
around
bytes
and
stuff.
But
here
we
have
a
network
filter,
that's
called
the
http
connection
manager,
and
that
is
how
I
actually
you
know,
that's
how
I
actually
do
http
style
processing,
and
so
this
this
network
filter
then
gets
configured
with
some
with
one
important
thing
is
the
routing
config.
So
this
is
the
route
table
right,
and
this
is
very
basic.
B
There's
a
single
route
and
the
important
part
to
look
at
is
I'm
listen,
my
route
will
this
route
will
apply
for
any
dome?
I'm
I'm
setting
up
a
virtual
host
and
the
domain
for
that
virtual
host
is
star,
which
means
anything
right,
so
any
domain
when
it
when
an
http
request
comes
in
and
the
host
header
has
any
anything
this
this
route,
this
virtual
host
applies
and
then
I
have
a
single
route
which
I'm
doing
a
prefix
of
slash.
B
So
this
is
a
path
prefix
of
the
root
path,
which
essentially
means
any
request
right,
so
any
for
any
request
again
on
any
domain.
What
I
want
to
do
is
I
want
to
route,
and
I
want
to
route
to
a
cluster.
That's
called
pet
store
and
we'll
get
into
the
cluster
here
in
a
second,
then
I
have
an
http
filter
set
up
and
the
hdp
filter
is
important
because
that
so
we
just
talked
about
network
filters
now,
once
we
want
to
actually
do
things,
you
know
handle
http
style
events.
So
let's
say
you
you
have.
B
We
have
just
decoded
the
headers.
You
know
there's
something
that
needs
to
happen
or
we
just
decoded
the
body
and
there's
something
that
needs
to
happen.
The
router
is
a
special
http
filter,
because
that's
what
actually
does
the
routing
of
the
so
as
the
trust
comes
into
envoy,
then
envoy,
says:
hey.
I
need
to
route
this
request
somewhere
else.
B
The
type
this
is
kind
of
the
service
discovery
type
in
this
case
we're
using
strict
dns,
which
means
that,
based
off
of
if
we
look
down
here
based
off
of
the
hostname
for
this
cluster,
I'm
going
to
envoy's
going
to
asynchronously
resolve
this.
This
name
and
again
this
is
going
to
run
in
the
kubernetes
cluster.
So
it's
going
to
resolve
against
the
service
name
of
this
service
and
it's
going
to
get
in
this
case.
B
It
would
get
the
service
ip
and
so
based
off
the
ip
that
I've
gotten
for
this
for
the
service
name,
that
is
my
endpoint
or
those
are
my
endpoints
that
I'm
going
to
route
to
and
then
the
port
defines
you
know
based
off
those
ips,
given
that
ip
and
port
combination-
those
are
my
endpoints
that
I
can
that
I
can
load
balance
across
and
then
finally,
there's
an
admin
interface,
that's
defined
here.
That's
not
super
interesting,
but
we
will.
We
can
look
at
the
admin
interface.
B
B
A
B
B
But
again
my
routing
config
said
any
path
right,
so
it's
going
to
forward
that
request
to
the
pet
store
application.
So
when
I
curl
this
now
I
get
my
response
and
envoy
is
what
fronted
you
know.
It
was
acting
as
a
front
proxy
for
the
pet
store
and
then
really
quickly.
What
I
also
want
to
do
is
now,
if
I
look
in
the
envoy
configuration
so
I'm
going
to
port
forward
now
to
that
that
admin
interface,
which
was
at
ten
thousand
one
now,
if
I
in
a
browser,
go
to
localhost
1001.
B
B
So
here
in
the
cluster
definition,
you
know
we
we
defined
our
pet
store
cluster
and
we
defined
the
pet
store
cluster
to
to
resolve
the
pet
store
service
name.
So
you
can
see
here
that
there
is
a
pet
store
cluster
and
there
is
an
ip
address
associated
with
it.
So
if
we
really
quickly
go
over
here
and
if
we
check
what
our
service
p
is
you'll
see
that
pet
store
is
10.,
111,
174,
20
right,
and
so
that
is
the
ip
address
here.
B
So
we
we
have
asynchronously
resolved
the
service
name
to
get
the
service
ip
address
which,
ultimately
behind
the
scenes,
corresponds
to
a
set
of
kubernetes
endpoints.
So
what
it's
really
doing
is
you
know?
Q
proxy
has
set
up
some
iptables
rules.
That
say
when
you
make
a
request
to
this
ipa,
I'm
really
going
to
forward
that
connection,
that
those
packets
to
another
endpoint,
which
is
my
pod
and
so
by
using
the
service
name
and
defining
that
as
my
cluster.
B
A
Yeah
well
so
this
would
be
a
great
time
for
anyone
who
has
questions
to
go
ahead
and
put
them
in
the
chat
lawrence.
That
was
awesome.
Thank
you
so
much
especially
for
the
the
demo.
Hopefully,
everyone
could
see
it
and,
of
course
this
is
being
streamed
on
youtube
and
should
be
available
shortly
after
for
google,
playback
and
whatnot.
So
please
leave
any
questions.
There's
none
right
now,
so
I'll
ask
a
question,
and
this
is
really
maybe
kind
of
oddball.
A
But
what
is
your
take
on
the
current
state
of
the
world
when
it
comes
to
adoption
around
these
things?
I
think
you
know
service
mesh,
maybe
came
a
little
bit
early
and
promised
to
solve
problems
that
people
might
not
have
been
having
yet,
I
think,
that's
kind
of
the
general
feel
in
a
lot
of
cases.
I'm
sure
if
you
ask
a
a
kind
of
majority
who
is
using
service
mesh
who's
worked
with
envoy
before,
especially
in
more
production
environments.
The
answer
is,
probably
you
know
not
many
right.
A
B
So
that
that
that's
a
great
question
I
I
think
you're
spot
on
as
far
as
like
service
mesh
kind
of
maybe
coming
a
little
too
early.
You
know
it's
been,
it's
been
talked
about
for
a
while
now
and
it
definitely
does
solve
problems,
but
I
I
agree.
I
think
that
you
know
the
the
real
problems
that
you
you
you
have
aren't.
Necessarily
you
know
the
the
problems
that
it's
trying
to
solve
are
not
problems
that
you
most
folks
will
have
ran
into
yet.
B
We
we
have
lots
of.
You
know
pretty
big
customers
that
that
are
starting
to
get
serious
with
okay,
let's
either
go
with
a
service
mesh
or
let's
get
serious
about
using.
You
know,
for
example,
glue
or
really
just
let's
use
envoy
in
production,
and
I
think
that
that's
really
starting
to
pick
up.
I
would
say
that
you
know
in
the
next
year
or
so
I
think
that
adoption
is
definitely
going
to
continue.
B
I
think,
as
far
as
service
mesh
goes,
I
think
that
a
lot
of
organizations
are
flirting
with
it
and
I
so
you
know
over
the
last
year
or
so.
I
think
that
that
that
kind
of
flirting
has
happened,
but
I
I
think
that
that
it's
starting
to
get
to
a
point
where
people
are
going
to
start
really
using
it
in
production.
So
I
know
of
a
couple-
and
I
know
that
I
know
of
more
that
are
seriously
thinking
about
okay.
B
How
do
I
really
make
this
happen
in
production
and
the
the
reason
is
you
know,
as
they've
decided
to
you
know,
architecturally
decided:
let's
go
down
this
micro
services
approach,
the
the
the
problems
that
service
mesh
promises
to
solve,
they're
real
problems-
it's
just
they
haven't
run
into
them,
yet
right.
So
as
their
micro
service,
their
kind
of
array
of
microservice
starts
growing.
The
need
for
a
service
mesh
makes
sense
and
that's
kind
of
where
you
know
in
the
talk
we
were
talking
about,
like
the
challenges
and
the
considerations.
B
You
know,
if
you
look
at
the
service
mesh
with
those
in
your
in
in
your
mind
as
you
make
those
decisions,
it
definitely
makes
sense
that
you
know
you
will
be
able
to
to.
You
know
you'll
be
able
to
solve
the
problems
without
shooting
yourself
in
the
foot.
So
I
I
personally
think
that
you
know
based
off
what
I've
seen.
A
Awesome,
thank
you
for
the
the
in-depth
answer
and
you
know
I
kind
of
kind
of
agree
not
that
I
am
anywhere
near
as
close
as
you
guys
are,
and
I
think
what
solo
is
doing
for
people
who
are
trying
to
adopt.
This
is
great
because
it
gives
them
clarity
and
and
some
tooling
around
it,
and
it
makes
it
easier
to
digest
me
having
kind
of
a
networking
background.
I
really
kind
of
clearly
see
what
this
brings
to
the
table
right.
A
It's
a
lot
more
control
and
a
lot
more
of
uncovering
the
shadows
of
network
traffic
and
what
you
can
do
with
it
service
to
service
and
whatnot.
So
that's
great
to
hear
it
looks
like
one
like
steve
is
typing,
but
he's
still
typing
so
in
the
interest
of
of
giving
everyone
their
evening
back
lawrence.
Where
can
we
learn
more
about
you?
What's
you
know?
Maybe
twitter
or
social
media?
How
can
we
we
talk
to
you.
B
So
I
am
not
too
into
social
media,
at
least
not
yet,
but
I
hang
out
in
solo
slack,
so
we
have
a
pretty
active
slack
if
you're
interested
please
join
and
we
can
maybe
we
can
send
out
some
links
or
something,
but
we
we
have
a
pretty
active
slack,
so
I'm
hanging
out
in
there
and
then
you
know
we're
trying
to
still
go
to
meetups.
I
think
you
kind
of
alluded
to
it
earlier.
You
know,
I
think
kind
of
people
are
getting
a
little
tired
of
the
virtual
event.
B
A
Thank
you
so
much
you've,
given
the
introspection
to
something
that
a
lot
of
people
are
just
starting
to
understand
and
don't
really
really
fully
get,
but
there's
just
a
strong
interest
for,
and
so
you
really
kind
of
given
us
a
zero
to
100
of
what
the
lowdown
is
and
what
the
possibilities
are.
So
that's,
fantastic
all
the
best
with
solo
with
you
know
your
team,
and
hopefully
things
are
growing
for
you
even
throughout
this
this
pandemic.
So
from
from
me
personally,
I
want
to
thank
everyone
again.
A
A
If
you
have
any
more
questions
or
you
just
kind
of
want
to
chat
with
lauren,
let
me
know
and
and
we'll
connect
you
guys
of
course,
so
thank
you
so
much
and
we're
looking
forward
to
at
some
point
meeting
you
in
the
future
in
person.
I
would
love
to
hang
out
with
the
the
solo
guys
get
some
drinks
too
guys
and
gil.
So
thank
you
so
much
for
for
participating
and
helping
make
this
meet
up.
This
meetup
happened
so
take
care
everybody,
that's
it
for
me,
jeff
and
bob.