►
From YouTube: Can You Replace API Management with Service Mesh?
Description
A commonly asked question is “can I replace the edge/API gateway or API management solution with a service mesh?” While the service mesh solves communication challenges between services in a cluster (east/west traffic), there still exists the need to manage the traffic entering and exiting a cluster (north/south traffic), and while complimentary, they are different traffic patterns. Additionally, not all applications are able to run in Kubernetes and service mesh or even as a container.
This talk covers:
* Evolving traffic patterns from the edge/ingress to service mesh
* How the traffic patterns differ and areas for integration
* Envoy as the underlying proxy technology for the modern application network
* Key capabilities of Envoy based networks
* How to incrementally adopt and operationalize across multiple clusters
Download the presentation https://speakerdeck.com/soloio/can-you-replace-api-management-with-service-mesh
Learn More https://www.solo.io
Join the community https://slack.solo.io
Request a demo https://lp.solo.io/lp-request-a-demo-overview
A
Today's
topic
is:
can
you
replace
api
management
with
a
service
mesh?
This
has
been.
This
is
a
fun
topic,
because
it's
probably
one
of
the
number
one
questions
that
we
always
get
when
we
are
out
there
talking
to
folks
in
the
community
and
companies
kind
of
looking
in
this
modern
api
space
with
the
rise
of
service,
mesh
and
envoy,
everyone
there's
been
a
lot
of
questions
on
like
where
does
it
go?
Is
what's
a
replacement
for
you
know?
What
can
I
replace
with
this
new
thing
and
how
do
they
work
together?
A
B
That
is
right.
Thank
you
betty.
Hopefully
you
can
hear
me
and,
as
betty
said,
that
this
is
a
very
common
question
and
it
it
there's
a
lot
to
unpack
when
we,
when
we
start
talking
about
this,
because
there
is
an
established
and
has
been
for
10
years
or
so
and
establish
practice
and
implementation
of
api
management
and
there's
now
this
new
thing
right,
service,
mesh
and
there's
this
overlap,
and
you
know,
there's
overlap
in
in
some
of
the
capabilities.
B
B
So
we're
going
to
try
to
help
you
understand
what
are
the
different
roles
that
you
should
be
aware
of
where
these
things
fit
and
what
can
be
replaced
with
what
in
in
terms
of
this
title,
so
my
name
is
christian
posta.
I
work
here
at
solo.
I've
been
here
almost
two
years
now
I've
been
involved
my
entire
career
in
building
services,
style
architectures.
B
You
know,
building
the
infrastructure
to
support
them,
including
in
previous
life.
You
know
building
the
the
the
foundational
pieces,
both
in
open
source
and
close
source,
that
kind
of
looked
like
what
kubernetes
was
doing
and
then,
when
kubernetes
came
along
kind
of
looked
like
what
the
service
mesh
was
doing
and
then,
when
the
service
mesh
came
along,
I
mean
both
kubernetes
and
service
mesh.
When
these
things
came
along,
the
light
bulb,
went
off
and
said:
yeah,
yeah,
okay,
that's
that's
the
thing.
B
We
don't
need
to
hand
cobble
these
things
together,
anymore,
and
I've
worked
with.
Teams
worked
with
organizations
all
over
the
world
to
help
build
these
types
of
cloud
applications
and
leverage.
This
cloud
infrastructure
to
build
things
like
microservices
to
build
things
like
the
some
of
the
devops,
tooling
and
automation
that
goes
on
top
of
that
to
enable
teams
to
go
faster
right,
that's
the
ultimate
goal
is
to
is
to
get
things
out
faster
and
so
I've
written
about
this
a
lot.
B
B
You
can
reach
out
to
me
if
you
have
any
questions
in
this
space
generally
about
any
of
these
particular
technologies,
or
anything
that
I
talk
about
today,
so
do
feel
free
to
to
reach
out
so
at
solo.
What
we
are
doing
is
we
are
helping
folks,
connect
their
applications
and
do
that
in
a
way
that
aligns
with
the
way
people
are
adopting
cloud
infrastructure,
and
so
that
means
the
problem
sets
are
not
all
that
new,
but
the
way
that
they're
being
deployed
and
implemented.
B
B
So
coming
back
to
the
talk
here,
the
inspiration
for
this,
or
rather
the
the
background
information
for
this
I've-
I've
documented
and
written
about
this
quite
a
bit
over
the
last
few
years,
and
if
you
go
check
out
the
the
blog
at
solo
or
my
own
personal
blog.
These
are
these
are
things
that
I've
gone
into
some
fairly
gory
detail
that
I'll
try
to
extrapolate
into
webinar
format
for
you
here,
so
it
basically
comes
down
to
to
this.
B
This
is
this
is
very
different
than
what
we
saw
in
previous
generations
of
technology
where
things
were
much
more
static
and
there
was
an
assumption
that
the
the
machines
would
never
go
down.
The
databases
would
never
go
down
and
everything
was
highly
redundant,
highly
available
and
so
forth,
and
they
did
go
down
and
the
applications
were
not
equipped
to
deal
with
that.
So
in
this
new
model,
this
this
elasticity
and
ephemerality
is
a
first
class
design
point
when
we
when
we
build
our
applications.
B
Right
now,
like
I
said,
some
of
these,
these
problems
are
not
entirely
new.
Just
the
context
is
different
in
the
past.
We
would
do
things
like
put
these
appliances
in
the
middle
of
our
architecture
and
force
all
of
the
traffic
through
that
right.
So
you
had
things
like
I
mean
going
back.
A
little
while
you
had
enterprise
application
integration,
you
had
things
like
enterprise
service
buses.
B
We
can
secure
it
and
that
will
that
will
solve
some
of
these
challenges
that
we
face
when
applications
need
to
talk
with
each
other
and
out
of
out
of
some
of
the
those
previous
generations
of
technologies
came
well
a
lot
of
that's
complicated,
trying
to
deal
with
the
protocol
translations
and
all
that
stuff
and
esps.
Why
don't
we
just
go
everything
to
rest,
we'll
move
everything
to
rest
and
json
and
http
and
we'll
expose
apis,
and
you
know
everything
will
be,
will
be
perfect
that
way,
and
that
gave
rise
to
the
api
management
solutions.
B
The
security
and
communication
challenges
around
authorizations
rate,
limiting
you
know,
telemetry
collection
and
so
forth,
and
then
start
to
build
capabilities
on
top
of
that
in
such
a
way
that
allows
you
to
monetize
api
usage,
implement
chargeback
within
your
enterprise
and
and
and
these
types
of
things,
which
is
all
very
useful
and
important
right.
So
some
some
folks
adopted
more
of
these
different
parts
of
api
management
than
others.
But
these
all
the
the
the
core
of
api
management
is
still.
You
know
it
has
a
lot
of
value
now.
B
Unfortunately,
they
got
implemented
in
a
very
similar
way
that
the
previous
generations
of
technology
was
implemented,
and
when
I
say
unfortunately,
I
don't
mean
because
it
was
bad,
but
I
mean
because
that
model
doesn't
fit
with
the
cloud
model,
with
the
elastic
ephemeral
model
and
the
decentralization
of
processes
and
so
forth
right.
So
the
the
implementation
worked
out
great
back
then,
but
it
doesn't
fit.
B
What
we're
trying
to
do
now-
and
you
know
some
of
some
of
the
things
that
crop
up
are
around
the
the
fact
that
this
type
of
technology
is
typically
implemented
in
a
very
centralized
manner
and
when
I
say
centralized,
I
mean
both
from
a
technology.
Standpoint
calls
go
from
our
service
to
another
service.
Through
this
this
box
and
as
well
from
a
ownership
standpoint,
you
have
a
specific
api
platform
team
that
typically
runs
these.
These
large
complex
resource,
intense
api
management
tools,
but
you
also
have
your
processes,
aligned
and
tied
to
this
centralization.
B
If
you
need
to
make
a
change
to
the
way,
routing
is
done
or
filtering
is
done
or
any
of
that
stuff.
On
the
api
management
tool,
you
have
to
file
tickets
and
coordinate
and
do
all
this
stuff
there
was
no.
There
was
no,
you
know
the
decentralization
of
the
process.
Wasn't
the
first
class
design
in
in
these
in
these
more
legacy.
Api
management,
vendors,
the
last
thing
I'll
say,
is
in
in
terms
of
the
evolution
of
technology.
B
B
B
We
see
how
in
in
enterprises,
large
enterprises,
it
might
have
been
adopted
or
implemented,
and
some
of
the
challenges
of
that
now,
if
we
fast
forward
a
little
bit
to
the
service
mesh
right
service
mesh,
is,
is
sort
of
the
the
alt
it's
implemented
in
a
highly
decentralized
way.
So
it
kind
of
attacks
some
of
these
the
shortcomings
of
existing
api
management,
but
it's
not
just
decentral.
It
was
built
specifically
to
handle
and
to
be
a
a
part
of
the
solution
to
services,
communicating
with
each
other
in
a
cloud
environment.
B
Now
what
we're
seeing
and
you
might
have
to
ask
yourself-
the
same
thing
is
what
we're
seeing
is
the
pendulum
swing
dramatically
from
one
end
to
all
the
way
to
the
other,
and
you
know
the
the
now
the
service
mesh
ends
up
being
the
the
hammer
that
we
use
to.
You
know
to
to
try
to
fix
everything
now
with
a
service
mesh.
B
B
B
When
you
know
when
people
start
talking
about
what
does
the
modern
architecture
look
like,
and
can
we
replace
the
the
api
gateway
or
the
api
management
solution?
So,
let's
take
a
little
bit
closer
look
at
what
the
service
mesh
is
doing
in
the
service
mesh.
What
we're!
What
we're
saying
is
deploy
a
little
agent
next
to
each
application
instance,
and
this
agent
will
be
responsible
for
things
like
timeouts
and
retries
and
circuit
breaking
telemetry
collection,
client,
side,
load,
balancing
service
discovery
right.
B
B
So
network
traffic
goes
through
this
proxy
and
will
arrive
at
other
services.
Potentially
with
that
proxy
could
arrive
at
databases,
message
queues
caches
that
kind
of
thing.
So
this
proxy
is
intended
to
intercept
from
the
application
or
to
the
application
any
of
the
network
traffic
and
from
there
we
can
write,
authentication
authorization
policies
about
the
traffic.
We
can
observe
it.
B
We
can
enable
transport
security
like
mutual
tls.
We
can
assign
identity
to
the
different
workloads
and
not
rely
on
ip
addresses
and
firewalls,
and
that
kind
of
stuff
excuse
me.
So
the
service
mesh
technology
is
a
solution
to
problems
that
are
not
new,
but
the
context
is
different
and
solves
those
problems
a
little
bit
more
elegantly,
especially
for
the
service
to
service
communication
use
cases.
B
So
a
typical
service
mesh
might
provide
these.
These
capabilities
service
discovery,
like
I
mentioned,
traffic
control
and
shaping
and
traffic
shadowing,
and
these
types
of
things
load
balancing
and
also
provides
a
nice
programmatic
or
api
to
drive
the
behavior.
So
you
can
write
automation
on
top
of
this
things
like
canary,
releasing
things
like
debugging
tools,
things
like
security,
you
know
reacting
to
security
events
and
so
forth,
so
the
service
mesh
provides
a
lot
of
value
for
services,
communicating
with
each
other.
B
Now
so,
we've
taken
a
look
at
the
api
management
where
it
fits
some
of
its
drawbacks.
In
in
previous
implementations,
we
looked
at
the
service,
mesh
and
sort
of
the
evolution.
I
made
the
point
that
we
that
were
the
pendulum
is
swinging
from
one
end
like
we
like
to
do
in
technology
all
the
way
to
the
far
part
of
the
side
of
the
other
end,
and
then
people
see
these
capabilities
of
the
service
mesh
and
they
say
yes,
that
is
going
to
solve
everything
when
it
comes
to
deploying
services
and
managing
the
communication
around
them.
B
How
do
you
get
untrusted
traffic
to
your
services
and
what
are
the
policies
that
enterprises
expect
to
be
able
to
enforce
and
implement
to
be
backward
compatible
with
to
conform
to
compliance,
and
you
know
regulatory
practices
and
so
forth?
What
are
those
capabilities
and
does
the
service
mesh
do
then,
and
the
answer
is
not
really
service
mesh
doesn't
cover
all
of
these
these
these
these
use
cases.
B
So
the
service
mesh
implement
has
brings
a
lot
of
good
capabilities,
the
the
model
that
it
has
the
decentralized
model,
the
focus
on
declarative
configuration
these
these
these
things
are
are
really
good,
but
the
capabilities
that
we
need
the
holistic
capabilities
that
we
need
in
an
enterprise.
That's
deploying
non-green
filled
type
scenarios
across
different
clouds,
with
the
constraints
that
an
enterprise
has.
How
do
we?
How
do
we
bridge
that
gap?
B
B
It's
it
definitely
starts
with
a
piece
of
technology
that
was
built
to
live
in
this
highly
dynamic
cloud,
world
and
layer,
on
top
of
on
top
of
that,
the
different
roles
and
responsibilities
needed
to
bridge
that
gap.
So,
let's
take
a
look
at
that
in
a
little
bit
more
detail.
So
envoy
is
a
proxy
anza
envoy
is
a
is
a
very
is
a
very
lightweight
proxy
that
was
built
at
lyft,
the
ridesharing
company,
specifically
to
address
these
types
of
problems
living
in
a
cloud
world,
something
maybe
like
kubernetes
nodes
are
coming
going.
B
B
So
envoy
ends
up
being
a
fundamental
piece
to
this
puzzle,
but
the
puzzle
isn't
just
one
thing
right,
so
we,
and
even
just
even
in
the
the
the
scenarios
where
envoy
is
applicable.
We
see
all
right
well,
this
kind
of
looks
like
the
service
mesh
case.
This
kind
of
looks
like
the
gateway
case
between
different
parts
of
the
organization.
B
B
So
now
this
is
where
you
know
in
the
evolution
of
this
technology
and
the
various
types
of
implementations
that
you
see
it
can
become
very
confusing
and
overwhelming
you
look
at
the
cncf
cloud
native.
You
know
that
that
landscape
map
that
it
has
and
you
look
under-
I
think
it's
service
proxy
or
service
mesh
or
gateway,
or
some
those
subsets
of
that
map,
and
even
looking
at
that
you're
like
what
is
what
is
all
this
stuff?
B
B
But,
as
I
said
at
the
beginning,
there's
there's
resources.
We
can
point
you
to
they
go
into
more
detail.
I
gave
you
my
contact
information
at
the
beginning,
I'll
put
it
up
at
the
end.
I
definitely
encourage
folks
to
reach
out
if
there
are
questions
or
if
I'm
not
clear
enough
on
on
what
I'm
saying
here
and
I
routinely
work
with
folks
in
the
in
the
community
to
help
help
them
understand
these.
B
These
differences
is
it's
it's
it's
important
right,
so
we
saw
that
the
the
service
mesh
is
good
at
handling
the
east-west
traffic
or
the
service
of
service
communication
traffic
right.
So
there
are
things
that
it
does.
It
does
well
traffic
control,
so
things
like
rollouts
to
different
versions,
rollouts
or
rather
traffic
control
based
on
content,
maybe
headers.
B
B
The
service
mesh
is
really
good
at
encrypting
the
traffic
between
services,
so
between
two
services
we
can
get
a
tls
so
or
mutual
tls
between
the
different
services,
so
that
that
traffic
can't
be
snooped
on
and
so
forth.
Some
service
meshes
also
use
that
as
an
opportunity
to
assign
identity
to
the
different
service
workloads.
B
B
But
those
are
capabilities
you
need
at
the
edge
as
well
in
a
gateway
right.
So
there
is
definitely
overlap
in
these
capabilities
and
that's
that's
fine.
All
right
they
are
using
in
some
cases
they
are
using.
The
same
technology,
like
I
said
envoy,
ends
up
being
sort
of
a
foundational
piece
to
a
lot
of
these
different
these
pieces
of
technology.
B
B
We're
going
to
see
in
the
gateway
case
that
envoy
plays
the
role
of
securing
boundaries
which
is
different
than
the
the
service
measure,
service
and
service
capabilities,
and
in
that
role,
envoy
or
a
gateway
needs
to
play
the
role
you
know
the
role
of
figuring
out
and
and
and
deducing
trust
for
traffic.
That's
coming
in
to
this
boundary
right
and
that
could
take
on
all
kinds
of
different
security
security.
Implementations
right,
you
might
do
things
like
especially-
and
this
is
the
key
part
in
an
enterprise-
there-
isn't
one
nice
uniform
way
of
doing
anything.
B
Really,
I
guess
but
doing
things
like
security
and
there
will
need
to
be
measures
taken
for
backward
compatibility
and
you'll
need
to
plug
this
in
somewhere.
You
don't
want
to
plug
it
in
everywhere.
You
don't
want
all
the
applications
to
to
own
the
this
responsibility,
so
typically
between
boundaries
is
where
you
would
assign
that
ownership
and
the
role
of
the
gateway
is
then
to
play
to
mediate
right
between
how
how
security
is
implemented.
B
In,
let's
say,
the
green
field
applications
versus
how
security
is
implemented
in
the
brownfield
applications-
and
you
know
play
that
mediation.
We
have
lots
of
customers
who
experience
this
pain
point
all
the
time
when
they
try
to
bring
in
these
these
types
of
technologies.
So
implementing
things
like
oauth,
auth,
2
flows,
integrating
with
oidc
things
like
ldap
integration,
then
stepping
out
a
little
bit
and
saying
well,
we
need
firewall
application
ruling.
We
need,
you
know
whitelist
blacklist,
sql
injection
detection,
all
of
these
types
of
things
at
the
edge.
B
We
need
message
transformation,
because
the
requests
coming
in
from
our
clients
might
not
be
in
the
right
shape
that
we
need
for
the
back
end
services.
We
also
assign
policies
and
maybe
sell
usage
quotas
to
different
users
or
or
attract
them
for
different
users
or
parts
of
our
organization
differently,
and
we
need
to
enforce
those
quotas.
We
need
to
enforce
rate
limiting
and
spike
arrest,
and
so
these
are.
These
are
boundary
concerns
where
the
gateway
would
play.
B
The
role
of
you
know
trying
to
solve
for
those
boundary
concerns
and,
as
you
start
to
build
this
out,
and
you
go
from
one-
let's
say
you
go
from
one
kubernetes
cluster
to
five.
Maybe
those
clusters
are
in
different
availability
zones,
maybe
the
different
lines
of
business
that
deploy
their
applications.
You
know
they
need
to
start
establishing
these
these
boundaries,
maybe
you're
deploying
on-premises
and
in
a
public
cloud.
B
You
need
you're,
definitely
going
to
need
the
service
to
service
communication
features
of
a
service
mesh
and
you're,
ultimately
going
to
need
something
to
help
manage
all
that
stuff,
because
that
gets
very
complicated
and
so
early
as
I
was
putting
the
slide
deck
together.
This
is
something
that
we
work
with
our
customers.
A
lot
with
right.
B
You
know
federating
these
different
deployments
and
that
ends
up
being
a
combination
of
modern
gateways
of
service
mesh
and
something
to
help
manage
that.
That's
been
a
fairly
consistent
architecture
that
that
we've
helped
our
our
customers
get
to,
and
so,
let's
at
solo,
what
we
see
is
the
heterogeneous
infrastructure
on-prem
in
the
cloud
across
multiple
clouds,
whatever
integrating
with
legacy
existing
deployments
existing
services-
and
you
know
it
kind
of
first-
starts
with
the
modernization
effort
of
well.
Let's
get
traffic
into
these
systems.
B
Let's
do
that
with
technology
that
was
built
for
this
type
of
environment
and
and
at
solo
we've
we
built
a
product
on
top
of
envoy
called
glue.
Glue,
as
its
name
implies,
is
a
way
to
stitch
together
these
heterogeneous
deployments
and
services,
whether
brownfield
or
greenfield
with
technology
that
was
built
for
the
cloud
and
built
to
go
forward
built
on
envoy
so
glue
is
a
an
api
gateway
built
on
envoy.
B
So
right
now,
that's
istio
istio
is
sort
of
the
dominant
leader,
and
so
we
do
offer
production
support
for
istio,
but
our
our
knowledge
and
our
expertise
goes
beyond
that.
It
goes
to
aws
app
mesh,
it
goes
to
console,
goes
to
things
like
open
service,
mesh
and
so
forth,
so
whatever's
on
void
base.
That's
our
core
competency
at
solo
and
building
these
types
of
networking
architectures
is
our
our.
You
know
core
competency.
B
So
that's
all
good
but,
like
I
mentioned,
as
you
start
to
deploy
this
out
across
multiple
different
sites,
different
clusters
and
try
to
build
a
uniform
policy.
You
know
automation.
These
types
of
things
becomes
important
to
have
something.
That's
able
to
understand
that
and
federate.
All
of
these
different
pieces
run
this
in
a
global
topology,
and
so
that's
where
we've
a
solo.
We
take
that
part
very,
very
seriously,
because
that
that
is
ultimately
what
we
want
to
do
is
solve
these
problems
and
make
it
operational,
and
our
federation
plane
allows
us
to
to
do
that.
B
You
know
restrictions
so
with
the
customer
without
customers.
What
we've
seen
is
this
need
to
customize
the
the
last
mile.
Let's
call
it
the
last
10
percent
of
getting
envoy
based
infrastructures
or
frameworks
into
their
architecture,
and
so,
although
we
we've
been
able
to
help
them,
do
that
by
extending
envoy
directly
or
extending
a
control,
plane
or
whatever
web
assembly,
is
that
future
direction
for
solving
this
type
of
problem?
B
And
this
is
something
that
we're
heavily
invested
in
well,
I
think
we
just
did
an
announcement
today
around
a
wasm
oci
spec
that
we
built
to
be
able
to
deploy
wasm
modules
into
envoy.
We
announced
the
webassembly
hub
back
in
december
last
year
as
a
way
of
managing
the
life
cycle
of
wasm,
extensions
for
envoy
and
and
so
forth,
and,
and
so
so
we
see
that
as
a
as
a
very
important
part
of
the
the
future
of
something
like
envoy,
where,
frankly
envoy,
is
where
all
the
innovation
in
this
l7
proxy
space
is
happening.
B
Envoy's
part
of
the
cncf
is
open,
and
you
know
that
things
like
webassembly
are
happening
in
in
that
community.
Now,
lastly,
is
one
of
the
capabilities
that
we
saw
in
api
management.
That's
very
important.
It
cannot
and
should
not
be
overlooked,
is
not
part
of.
Let's
say
a
service
mesh
per
se
is
a
developer
portal
and
building
the
capabilities
to
allow
teams
to
self-service,
to
write
policies
about
usage,
and
you
know
expose
their
apis
at
a
boundary
point,
whether
that's
external
to
partners,
other
parts
of
the
organization
or
internal.
B
For
you
know,
as
I
mentioned,
you
know,
usage
that
that's
an
important
capability
as
well,
so
back
to
the
question,
can
you
replace
api
management
with
a
service
mesh?
The
answer
is
no
not
by
itself
there's
a
lot
of
other
things
that
go
into
it
and
ultimately
replacing
api
management.
Isn't
the
goal
right?
B
B
So
I
am
going
to
attempt
to
demo.
I
was
running
into
some
google
cloud
issues.
Oh
okay,
we
might
be
in
good
shape
all
right.
We
gotta,
we
got
our
stuff
there,
all
right.
Let's
take
a
look,
so
the
first
thing
that
we're
gonna
look
at
is
using.
So,
let's,
let's
let's
say
we
start
with
we.
Maybe
the
pendulum
has
swung
all
the
whole
the
whole
way
right
and
we've.
We
said:
okay,
we're
doing
service
mesh
service.
B
You
know
cloud-native
architecture
like
this,
so
at
solo,
one
of
the
projects
that
we
have
is
called
the
developer
portal
for
istio.
So
this
might,
if
we
look
at
this
list
here,
this
might
knock
out.
Let's
say
that
one
and
and
that
one
all
right-
and
maybe
maybe
a
part
of
this
one-
I
don't
know
how
to
maybe
part
of
this
one
right.
B
B
So
what
we
want
to
do
what
we're
going
to
do
here
for
this
demo
is:
we
have
some
apis
and
they're
running
they're
in
seo
side
cars
deployed
here
you
can
see
that
what
we're
going
to
do
is
we're
going
to
we're
going
to
document
them
and
expose
them
in
a
portal
and
we're
going
to
wrap
them
with
some
rate
limiting
we're
going
to
wrap
them
with
some
basic
off
capabilities
all
right.
So,
let's,
let's
come
look
at
our
developer
portal
for
istio.
I
click
on
apis.
B
B
We
want
to
expose
them
to
outside
users,
but
we
want
to
expose
them
a
little
bit
differently
than
how
they're
implemented
in
in
the
back
end,
or
maybe
we
want
to.
We
will
expose
them.
The
same
way,
but
we
want
to
add
additional
policies
around
that,
and
so
that's
where
we
come
to
define
an
api
product
if
I
click
on
api
product,
let's
call
this
the
pet
store
zero.
B
Next
now
here
we
here,
we
can
just
pick
the
api
doc.
That
applies
right
so,
but
but
we
want
to
take
a
little
bit
more
complicated
use
case
where
we're
not
going
to
expose
it
exactly
how
it
is
to
end
users.
What
we're
going
to
say
is
the
search
capabilities
from
the
older
pet
store
is
what
we'll
expose,
but
then
for
adding
a
pet
we
want
to.
B
B
So
we'll
do
that
here,
we'll
give
a
default
route,
but
we
can
also
come
down
here
and
and
specify
the
route
for
each
individual
path
in
the
in
the
api,
we'll
just
give
it
a
default
route
at
the
moment
and
click
save
and
we'll
give
it
a
second
to
reconcile
in
the
back
end.
So
one
thing
I
do
want
to
point
out
here
is
that
everything
that
we
define
through
this
ui
is
actually
also
available
as
custom
resources.
B
B
Let's
see,
okay
get
virtual
service
dot.
Networking
we've
we've
automatically
created
this
pet
store
virtual
service,
which
means
that
I
should
be
able
to
set
up
all
the
dns
stuff
correctly
call
this
service
and
what
it's
done
is
set
it
up
on
the
istio
ingress
gateway.
So
it's
automated
so
we're
starting
to
turn
the
the
ingress
gateway
for
istio
into
a
lightweight
api
gateway,
and
so
from
here.
What
I
can
do
is
I
can
create
a
portal
now.
So
we'll
just
call
this
the
pet
store
portal.
B
B
B
B
So
now,
if
I
come
to
the
portal
and
click
on
it
and
go
into
it,
you
can
see
we
have
a
a
simple
portal
here,
which
is
is
customizable,
so
you
can
make
it
look.
However,
however,
you
like,
if
we
look
at
the
apis,
we
see
our
pet
store.
Api
is
indeed
there.
If
I
click
on
this,
we
can
get
the
documentation
for
it
now
from
here.
B
We
can
call
it
and
we
can
actually
might
be
useful
to
to
show
that
we
can
create
api
keys
for
call
being
able
to
call
it
so
now
that
I've
added
it
to
the
portal
I've
added
a
rate
plan
around
it.
If
I
try
call
it
it
shouldn't,
let
me
it
doesn't
so
to
be
able
to
call
it.
We
need
to.
We
need
to
pass
in
this.
B
This
api
key-
I
can
do
that
just
by
clicking
here,
we'll
give
it
an
api,
key
authorize,
authorize
and
then
now,
if
I
come
into
api
pets
and
say,
try
it
out
execute
if
I
call
it
using
using
the
api
keys
and
passing
in
the
api
key,
then
then
it
works
right.
So
again,
we've
set
up
istio's
ingress
gateway
to
be
able
now
to
perform.
Let's,
let's
take
this,
we
can
see
it's
performing
an
auth
challenge.
B
It
has
to
have
the
api
key.
Otherwise
it
won't
work,
but
if
we
call
it
too
many
times,
we'll
eventually
see
the
rate
limiting
kick
in
so
we've
added
rate
limiting
to
istio's
ingress
gateway.
So
we
sort
of
bridge
the
gap
there,
but
that's
not
everything
right.
So
come
back
and
come
back
to
our
list
here,
there's
still
things
like
security
flows,
web
application,
firewalling,
you
know
telemetry
collection
and
so
forth,
and
that's
where
our
api
gateway
built
on
envoy
called
glue
fits
into
the
picture.
B
You
know
if
we
look
at
our
if
we
look
at
our
security
authentication
authorization
being
able
to
plug
into
ldap
and
we
have
the
api
keys,
but
we
also
have
off
opa
open
policy
agent
for
doing
authorizations
and
you
can
write
your
own
plugins
as
well.
So
I
highly
encourage
you
and-
and
the
last
part
is
the
glue
plays
very
nicely
with
istio,
basically
extends
istio's
capabilities,
but
lives
natively
as
a
gateway
for
for
istio
tizen
with
mutual
tls
and
that
kind
of
stuff.
B
So
I
realized
here
that
I'm
running
out
of
time,
but
I
definitely
want
to
leave
you
with.
Let's
come
back
down
here
here,
I'll
leave,
my
my
my
contact
info
definitely
reach
out
to
me.
If
you
have
questions
outside
of
this,
I
also
want
to
leave
with
with
some
with
some
additional
resources
and
links
for
for
some
of
the
stuff
that
we
talked
about
here
today.
B
B
That's
a
great
question,
and
that
is
precisely
the
type
of
architecture
that
you
know
we
specialize
in
in
helping
folks
build
so
basically
what
it
what
it
ends
up.
Looking
like
is
a
thing
a
single
mesh
is,
you
know,
it
really
depends
on
definitions
here,
let's
take
istio,
for
example,
what
what
we
recommend
is
folks
deploy
istio
in
the
replicated
control,
plane
manner,
which
means
each
logical
boundary
has
its
own
control
plane
and,
by
extension,
the
that
logical.
B
That
boundary
should
also
map
up
with
the
other
properties
of
the
failure,
domains
that
you're
that
you're
trying
to
limit
so,
for
example,
kubernetes
kubernetes
itself
is
a
single
failure
domain
for
for
deployment
for
configuration,
for
you
know,
security
and
so
forth.
So,
ideally,
you
would
play
to
play
a
single
istio
control
plane
there
across
clusters.
B
You
know
you
will
have
separate
control
planes
and
now
the
problem
with
that
is
the
operational
overhead
and
management
of
that
from
a
security
standpoint
from
a
failure
domain
standpoint,
a
highly
availability
standpoint.
That
is
the
right
approach,
but
that
puts
a
lot
of
burden
on
operations
and
we
didn't
talk
about
it
today.
B
But
that's
where
our
service
mesh
hub
product
comes
into
play,
so
when
you
start
to
federate
these
different
mesh
deployments
across
different
installations
across
different
clusters,
the
operational
overhead
of
keeping
those
you
know
viable
is
is
not
zero,
so
service
mesh
hub
was
built
to
solve
that
exact.
That
exact
problem.
So
from
a
mesh
capability
standpoint,
you
know
federated
meshes
from
a
cross
boundary
across
lines
of
business.
We
typically
see
internal
gateways,
so
it's
where
something
like
glue
would
fit
in
across
availability
zones
or
regions.
B
B
Okay,
so
that's
that's
a
great
question.
It
obviously
goes.
It
illustrates
the
fact
that
I
didn't.
I
didn't
clarify
this
well
enough.
So
I'll
try
to
say
it
again
so
between
boundaries
between
lines
of
business,
for
example,
think
in
your
organization,
different
lines
of
business
within
the
line
of
business,
the
sidecar
proxy
can
correctly
handle
the
traffic
to
from
one
service
to
another.
B
B
I
want
all
of
these
different
capabilities
that
you
would
expect
at
the
boundary
to
be
implemented
and
the
service
mesh
that
that's
not
a
that's,
not
a
capability
that
it
it
has.
Nor
do
you
know
what
you
want
it.
You
don't
want
all
parts
of
the
organizations
their
you
know,
assumptions
about
how
requests
come
into
them
or
their
peculiarities
in
terms
of
transformation
and
so
forth,
leaking
into
every
single
sidecar
across
the
organization.
Right.
Just
that's,
that's
a
huge
mess
that
we
want
to
avoid
that.
B
A
Great-
and
we
are
just
two
minutes
over-
but
thanks
again
christian
for
for
the
talk
and
demo
today
and
for
everyone
with
all
your
questions,
we'll
try
to
get
as
many
of
them
answered
offline
as
possible,
and
we
will
see
you
at
the
next
online
event,
which
is
the
end
of
this
month,
we're
actually
having
live
online
service,
mesh,
multi-cluster
service
mesh
workshops.
So
you
can
go
to
our
events
page
and
register
for
those.