►
From YouTube: Lightning Talk: Move Over API Gateway.... into Your Service Mesh- Marino Wijay, Solo.io
Description
Lightning Talk: Move Over API Gateway.... into Your Service Mesh- Marino Wijay, Solo.io
They say API Gateways are for your "north-south" traffic into your clusters and Service Mesh is for your "east-west" traffic. Is this really the case? As you deploy a service mesh for high availability, failover, and tenancy, you will find north/south and east/west start to converge. Instead of thinking of API Gateways and Service Mesh as separate and different, we should be thinking of them as the same thing. In this talk, we explore the role of modern API gateway and how we can make it part of the service mesh.
A
A
So
my
name
is
marina
wijay.
I
am
a
developer
advocate
at
solo.I,
o
I'm
from
canada.
So
I'm
glad
to
be
all
the
way
out
here
in
valencia.
I've
been
at
solo
for
about.
I
don't
know
two,
no
seven
months
now,
I
think,
and
prior
to
that
I
used
to
work
at
vmware
tanzu,
so
a
little
plug
for
my
vmware
tenzi
folks
over
there.
A
So,
let's
get
right
into
it
and
let's
talk
a
little
bit
about
service
meshes
and
api
gateways
and
specifically
an
api
gateway
that
might
be
envoy
based
and
and
the
istio
ingress
gateway.
So
when
we
look
at
these
two
systems,
what
does
an
api
gateway
do
for
us?
It's
effectively
providing
us
controls
to
do
things
like
rate
limiting,
to
be
able
to
detect
and
discern
what
our
upstream
services
are
provide.
A
On
the
other
hand,
when
you
look
at
the
istio
ingress
gateway
or
egress
egress
gateway,
whatever
you
want
to
call
it,
it
serves
its
its
own
purpose
in
that
it's
also
providing
ingress
capabilities
for
services
inside
the
mesh.
It's
also
doing
some
tls
termination
and
a
variety
of
other
services,
as
well
commonly
between
the
two
you're
going
to
see
that
there
is
observability
that
is
present.
A
But
the
thing
to
consider
here
is:
okay:
I
have
an
api
gateway
sitting
on
one
side,
one
part
of
my
cluster.
I
have
istio
running
in
another
part
of
my
cluster.
I
have
an
ingress
gateway
that
can
do
pretty
much
almost
the
same
and
I'm
missing
a
few
bits
and
pieces.
So
what
can
we
do
to
actually
merge
these
two
and
consolidate
them?
A
But
the
critical
part
here
is
that
this
is
our
front
door
once
we're
past
the
front
door,
like
anything,
can
go
on.
Anything
can
go
wrong
for
that
matter,
and
so,
let's
also
look
at
the
the
other
lens
here,
where
we
have
a
service
mesh
running
inside
of
our
kubernetes
cluster,
where
we're
not
so
concerned
about
that
front
door.
A
A
The
other
thing
to
consider
is
that,
as
you
start
to
scale
your
clusters,
as
you
start
to
scale
your
services
that
you
have
available
to
you,
the
challenges
that
that
come
up
are
like.
How
do
I
manage
all
of
these
different
objects
that
I
have
to
create?
How
do
I
manage
all
the
services,
all
the
upstreams,
all
the
routing
rules
that
I
need
to
have
in
place?
How
do
I
manage
different
versions
of
let's
say,
api
gateways
or
let's
say
our
service
meshes?
A
A
We
can
start
off
by
having
an
api
gateway,
something
that's
envoy
based
at
the
front
door
that
is
able
to.
You
know,
understand
the
requests
that
are
coming
in
and
route
them
appropriately
to
the
backend
and
then
on.
The
inside
will
have
service
mesh
or
an
istio
service
mesh,
that's
providing
that
east-west
security
using
service-to-service,
mtls
and
even
providing
us
a
level
of
observability,
and
you
know
off
to
the
side
you're,
seeing
virtual
machines
that
also
need
to
participate
in
this
entire
fabric.
A
A
Those
requests
that
are
coming
in
and
what
happens
is
specifically
istio
is
able
to
tie
itself
to
virtual
machines,
and
so
now
we
have
a
sidecar
that
sits
with
the
virtual
machine
that
allows
it
to
participate
in
the
mesh
and
I'm
not
going
to
talk
about
what
how
that
all
works.
But
the
idea
is
now
we
have
this
fluid
system,
a
fabric
which
allows
us
to
have
micro
services
and
vms
securely
communicating
with
each
other.
Then
we
scale
with
clusters.
A
Now
we
have
more
clusters,
we
have
more
services,
we
have
cross-cluster
communications,
we're
having
to
deploy
east-west
gateways
using
istio,
and
we
still
have
an
api
gateway
front
door,
which
means
we
have
two
sets
of
custom
resource
definitions
that
we
have
to
worry
about
which
in
actuality,
when
you
think
about
it,
it's
just
more
overhead
for
all
of
you.
So
how
do
we
address
it?
A
We
address
it
by
using
a
service,
mesh
management
plane
and
then
a
gateway
abstraction.
On
top
of
that,
what
this
allows
us
to
do
is
provide
all
those
same
capabilities
of
an
api
gateway
while
still
using
something
like
the
istio
ingress
gateway,
which
is
still
based
off
of
the
envoy
proxy
anyways,
we've
written
the
listeners
and
filters
and
the
filter
configurations
and
whatnot.
But
the
idea
behind
this
is
now.
I
don't
need
to
rely
on
a
single
single
entity.
I
don't
need
to
rely
on
a
separate,
cr
or
set
of
crs.
A
A
This
is
all
because
of
blue
mesh
gateway
and
what
we've
built
in
our
environment.
So
that
being
said,
if
you
are
looking
to
be
able
to
layer
into
a
service
mesh-
and
you
want
to
be
able
to
take
advantage
of
external
authorization
rate,
limiting
you
want
to
be
able
to
tie
into
oidc
systems
as
well-
maybe
even
use
some
open
policy
agent
to
allow
certain
objects
to
communicate
with
other
objects
or
conduct
actions
well
glue,
mesh
and
glue
mesh
gateway.
Are
your
answer?