►
From YouTube: Introducing the Developer Portal for Istio Service Mesh
Description
Service mesh is quickly becoming the industry standard for communication management in the microservices environment. Currently, there is no efficient way for organizations to catalog the APIs running in their service mesh, making it difficult to securely enable developers both inside and outside the company to leverage these APIs in their development process.
The new Istio Developer Portal makes it easy for an application team to catalog the APIs running within a service mesh, and provides a great user experience to help document, securely expose and consume APIs.
In this session we will discuss and demonstrate the Istio Developer Portal:
* Secure API management to internal developers and external partners
* Declarative architecture and GitOps workflows
* Flexible security solutions, integrations and policies
* Developer experience and onboarding
Learn more https://www.solo.io/products/istio-developer-portal/
Request a Trial https://lp.solo.io/lp-request-a-trial-general
Questions? Join the community at https://slack.solo.io
A
A
So
my
name
is
Christian.
My
background
is
in
building
large
scale
services
based
architectures
and
I've
done
this
at
large
enterprises.
I've
done
this
with
my
work
at
some
of
the
cloud.
You
know
the
vanguard
of
the
cloud
platforms
and
wet
scale.
Companies
I've
been
involved
in
open
source
now
for
quite
a
long
time
contributing
to
open
source
the
especially
around
communication.
So
things
like
building
resilient
systems
around
service
matches
something
that
I've
been
interested
in
the
last
three
years
or
so
I've
written
I
vote.
A
The
first
book
on
SEO,
for
example,
I'm,
currently
writing
with
my
co-author
SEO
in
action
and
I've
written
books
on
micro
services
and
so
forth,
and
I
generally
like
to
blog
and
talk
and
share
my
experiences
working
with
customers
as
an
architect
as
a
as
someone
who
can
help
influence
these
these
architectures
and
these
implementations
and
I
like
to
blog
about
them
and
share
them
with
folks,
including
through
slides,
so
check
out
the
SlideShare
that
I
have
there.
I
came
to
Seoul
about
a
year
and
a
half
ago
from
Red
Hat
were
there.
A
I
was
the
chief
architect
of
cloud
application
development
and
we
started
to
get
into
this
service
mesh
stuff
there
at
Red,
Hat
I
was
a
very
big
advocate
of
it,
and
I
saw
it
as
much
more
strategic
to
the
API
evolution
and
API
management
evolution.
Then
then,
at
some
other
folks,
so
I
came
to
solo
specifically
to
focus
on
this
problem.
Now
I've
been
around
for
long
enough
to
know
that
getting
applications
to
talk
with
each
other
sharing
information
about
those
applications
and
those
endpoints
isn't
entirely
a
new
problem.
A
And
so
here
it's
solo.
What
we're
doing
is
we're
building
helping
to
build
this
communications
backbone
for
applications,
so
application
level.
Networking
that
solves
some
similar
problems
that
we
saw
in
the
past,
but
does
it
in
a
much
more
elegant
way
for
the
underlying
infrastructure
that
we're
deploying
to
today,
where
things
like
containers
things
like
kubernetes
things
like
public
cloud
things
like
even
VMS
on
OpenStack
or
something
you
know
these,
these
pieces
of
infrastructure
are
ephemeral,
they're
scaling
and
auto
scaling.
The
applications
in
them
are
becoming
unhealthy.
A
The
applications
in
them
might
just
be
revving
very
quickly
right.
The
whole
point
of
adopting
some
of
this
infrastructure
and
the
application
architectures
to
to
enable
yes,
like
micro
services,
is
to
be
able,
go
faster
and
deliver
things
faster
right.
So
the
assumptions
of
the
applications
and
the
infrastructure
underlying
have
have
changed.
Now.
At
solo,
we've
got
the
attention
of
the
industry
we're
exploding.
A
Now
the
we've
made
key
contributions
and
collaborations
with
industry
partners
like
Microsoft,
where
we
are
working
on
things
like
the
surface
mesh
interface
with
them,
something
that
we
developed
early
on
and
in
2018
we're
working
with
hashey
core.
We
integrate
very
nicely
with
Hashi
core.
In
fact,
we
wrote
the
original
blueconnect
or
the
precursor
to
console
connect.
So
our
expertise
is
in
Envoy,
proxy
and
service
bench.
We,
you
know
we're
working
closely
with
Google
around
webassembly
and
sto
and
so
forth.
A
Is
they
looked
at
the
capabilities
like
security
and
observability,
and
they
said
well,
let's
just
run
all
our
traffic
through
that,
and
so
they
built
all
these
processes.
You
know
if
you,
if
you
wanted
to
expose
an
API,
you
have
to
go
to
this
team.
You
had
to
open
up
tickets
and
everything
would
flow
through
this
centralized
point.
So
at
stola
we're
looking
at
how
do
we
build
prophecies
in
technology
to
solve
those
problems?
A
In
a
more
elegant
way,
in
a
decentralized
way,
when
we
start
going
to
cloud
public
public
cloud
on-premises
or
wherever
you
need
to
you
know,
security
is
is
number
one
you
have
to
solve
for
things
like
authentication,
authorization,
keeping
traffic
communication
encrypted
and
building
up
a
more
of
a
zero
trust
model
versus
our
previous
iterations
of
perimeter,
based
security
and
so
forth.
And,
lastly,
how
do
we
manage
this
whole
thing?
How
do
we
observe
and
understand
what's
happening
across
things
like
service
mesh
things
that
might
be
running
on
premises
or
in
a
public
cloud?
A
And
so
so
that's
what
we're
focused
on
building
here
at
Sullivan
and
we're
gonna,
we're
gonna,
see
that
and
how
things
are
you
see
a
developer
portal
tie
it
ties
in
so
we're
building
foundationally
on
on
boi
proxy.
We
saw
very
early
on
the
potential
with
Envoy
things
like
it's
dynamic
configuration
things
like
its
extensibility
to
be
able
to
plug
in
additional
protocols,
additional
features
and
so
forth,
and
we
noticed
this
pretty
early
on
is
this
could
be.
A
It
should
be
the
foundational
piece
to
building
distributed
systems
in
a
cloud-like
environment
like
a
kubernetes
like
a
public
cloud
and-
and
you
know
the
assumptions
that
come
along
with
it.
You
need
something,
that's
highly
dynamic,
something
that
can
be
updated
without
dropping
connections,
something
that's
highly
performant
and
can
be
extended
to
keep
up
with
the
fast
pace
of
innovation.
That's
happening
in
the
cloud
native
ecosystem
and
so
on.
Voip
rocks
the
mood
we
picked
on
Vallejo
as
our.
So
it's
all.
A
Our
foundational
competency
is
in
envoy,
which
extends
to
these
various
parts
of
the
architecture
to
be
able
to
just
solve
some
of
these
problems,
and
it's
all
we
see
the
journey
as
sort
of
iterative
and
starting
with
solving
some
of
the
solving
some
of
the
problems
at
the
edge
of
your
application
architecture.
We
built
glue
as
an
edge
or
API
gateway,
built
on
top
of
Envoy,
that
you
can
use
with
or
without
a
service
mesh
and
gives
a
lower
barrier
to
entry
for
adopting
envoy
based
technology
and
solves
the.
A
You
know
that
the
problems
of
the
edge
in
a
nice
cloud
native
way
you
know
I,
can
explain
that
in
a
second
now,
a
big
part
of
decentralizing,
your
API
infrastructure
is
adopting
the
capabilities
that
the
service
mesh
brings
so
resilient
traffic
control
in
an
east-west
traffic
manner,
strict
identity
and
encryption
between
the
services,
observability
and
and
and
so
forth,
and,
if
so
low.
What
we.
A
What
we're
seeing
is
that's
a
great
envoy,
based
service
measures,
are
a
great
solution
to
that
east-west
problem,
but,
as
you
start
to
build
out
more
clusters
that
east-west
problem
starts
to
get
blurry.
Where
is
what
exactly
is
east-west
and
managing
multiple
clusters
of
service
mesh
and
getting
them
to
interact
and
interoperate
with
each
other
is
a
realistic
problem
that
we
already
see
our
customers
have
and
is
a
growing
problem.
Each
public
cloud
vendor
will
have
its
own
service
mesh
and
there's
already
or
not.
A
A
Between
the
load,
balancing
identity,
Federation
traffic
control,
access
control
and
so
forth
between
different
service
mesh
clusters
and
lastly,
we
understand
that
envoy
is
a
very
forward-looking
project
and
is
innovative,
and
we
want
to
help
and
be
part
of
that
innovation,
especially
around
customizing
envoy,
and
making
it
more
powerful
for
those
last
mile
integration
use
cases
that
you
have
when
you
try
to
bring
in
an
envoy
based
solution.
So
webassembly
allows
you
to
inject
your
own
custom
code
into
envoy
proxy
and
a
secure
and
dynamic
way.
A
A
So
again,
we
are
looking
at
this
through
the
lens
of
decentralization
through
building
up
on
zero
trust
principles
and
providing
a
holistic
management
for
your
API
infrastructure.
They
saw
an
ongoing
whether
that's
service
mesh,
whether
that's
edge
gateways,
whether
that's
a
combination
of
both
and
whether
that's
on
premises
or
in
a
public
cloud.
So
we're
able
to
kind
of
unify
all
of
these
deployments
into
a
single
pane
of
glass
that
allows
you
to
control
and
secure
your
traffic
as
well
as
expose
and
share
the
capabilities
of
your
API
with
other
parts
of
the
organization.
A
A
We're
envoy
provides
the
backbone
of
these
communication
channels,
and
then
we
need
a
way
to
expose
these
api's.
We
need
a
way
to
discover
them.
We
need
a
way
to
document
them
and
do
that
in
such
a
way
that
everyone
provides
boundaries
where
API
and
boundaries
are
needed.
You
know
once
you
start
deploying
tons
of
micro
services
all
over
the
place.
You
know
your
application
architecture
and
the
boundaries
within
that
architectures
start
to
dissolve
away,
but
that's
that's
not
necessarily
a
good
thing.
We
still
want
some
structure.
A
So
looking
at
developer
portals,
it
starts
with
securing
the
edge.
That's
where
traffic
starts
to
come
into
your
infrastructure,
and
you
know
there
are
some
key
capabilities
at
the
edge
when
you
look
at
this.
The
three
principles
that
I
mentioned:
decentralization,
zero
trust
and
manageability,
so
at
the
edge.
What
we
need
is
to
establish
and
force
and
identify
trust
levels
for
traffic.
Coming
in
to
these
boundaries,
we
need
to
authenticate
the
user
and
potentially
the
system
that
is
being
used
to
call
in
to
our
architecture.
A
We
need
to
be
able
to
write
fine-grain
authorization
rules
of
the
capabilities
that
they're
allowed
to
have
access
to,
as
they
start
to
make
their
first
steps
into
your
application
architecture,
and
we
want
encryption
from
you
know,
come
likely
coming
in
to
the
gateway,
but
is
especially
once
we
start
to
make
our
calls
into
the
application
architecture.
We
we
want
to
be
able
to
pass
along
additional
metadata
about
the
request,
identity
about
the
user
and
these
types
of
things,
and
we
need
that
traffic
to
be
encrypted.
A
We
also
need
a
place,
a
place
to
apply
traffic
policies
and
traffic.
Routing
rules
like
I,
said
part
of
the
part
of
the
reason
for
going
to
a
micro
services
and
cloud.
Our
infrastructure
is
to
be
able
to
make
things
make
changes
to
the
system
faster.
So
we
know
there's
going
to
be
iterations,
we
know
there's
going
to
be
new
versions,
we
need
to
be
able
to
control
the
the
traffic
routing
so
that
we
can
limit
exposure
to
some
of
these
changes
to
production
users
in
a
controlled
way.
A
A
The
role
in
general
of
the
gateway
is
sort
of
the
abstract
away,
some
of
the
details
of
the
services
behind
it,
so
that
each
service
doesn't
have
to
solve
forever
for
these
types
of
capabilities
and
the
API
that
you
end
up
exposing
on
the
API
gateway
can
be
viewed
in
terms
of
what's
best
for
the
client,
not
in
terms
of
how
it
was
implemented,
and
so
you
can
so
the
API
gateway
and
the
edge
provides
not
only
these
these
security
parameters
on
behalf
of
services,
but
also
a
abstraction
layer.
So
you
can
decouple
these.
A
You
know
implementation
and
and
usage
of
the
service,
so
I
solo,
as
I
mentioned
briefly
earlier,
that
we
built
blue
specifically
for
this
problem.
Blue
is
an
API
gateway
built
on
envoy
proxy
that
enables
this
more
sophisticated,
zero
trust
networking
at
the
edge
type
proxy.
So
it's
since
it
built
on
tango,
we'll
get
all
the
Envoy
things
out
of
the
box
like
traffic
routing
like
the
telemetry
and
observability,
like
circuit,
braking
and
so
forth,
and
as
solo
we've
added
things
like
edge
filters
that
live
inside
of
envoy.
That
can
do
things
like
web
application
firewall.
A
We
have
some
filters
that
extend
it
have
a
very
simple
control
plane
that
enables
things
like
external
author,
8
limiting
and
a
declarative
configuration,
and
you
know
glue-
is
what
we're
well
suited
for
the
edge
glue.
Also
has
a
developer
portal
and
everything
we
do
in
glue
and
actually
any
of
our
products
is
based
on
declarative
configuration.
So
we
can
use
C,
RDS
and
kubernetes
to
configure
glue
and
to
configure
the
development
portal.
A
Let
me
let
me
give
you
a
quick,
the
PCAT
glue,
so
here's
the
glue
dashboard
glue
like
I,
said
it's
a
edge
proxy.
We
can
configure
very
sophisticated
security
mechanisms
around
it's
built
on
envoy.
You
can
see
the
health
of
the
unblurred
proxy
here.
It
has
a
death
portal,
which
I
mentioned.
We
can
define
API
based
on,
let's
say
the
open,
API
spec.
A
We
can
expose
them
in
portals
that
are
that
are
controlled
by
user
self-service
mechanisms,
so
people
can
come
in
sign
up
for
and
get
API
keys,
be
able
to
call
in
to
these
services.
Glu
also
does
things
like
discovery,
automatic
discovery
of
runtime
services.
So,
for
example,
we
have
in
this
case
where
we're
connected
to
AWS.
We
can
see
what
aww
lambdas
might
be
running
in
our
AWS
account
or
services
might
be
running
on
ec2.
A
We
can
also
see
things
like
some
of
our
services
running
kubernetes
that
were
automatically
discovered
our
G
RPC
services
and
we
can
inspect
those
services
using
G
RPC
reflection
and
build
up
a
runtime
catalog
of
what
is
what
is
available
in
our
in
our
system.
We
do
the
same
thing
with
open,
API,
spec
services,
in
this
case
the
default
pet
store,
and
so
we
can.
We
can
get
deep
introspection,
understanding,
what's
right,
actually
happening
at
runtime
and
then
from
there.
We
can
compare
that
with.
A
A
Maybe
it's
doing
some
simple
pass
through
to
or
maybe
some
some
more
sophisticated
routing
to
services
that
might
run
in
them
in
the
mesh.
Now
those
API
is
when
they
are,
you
know,
deployed
inside
of
a
mesh.
They
might
be
that
might
be
exposed
to
maybe
external
users
through
an
API
developer
portal,
maybe
using
glue
or
something
else
now
for
the
services
running
inside
the
mesh,
where
you
as
I
said
I
already
have
it.
A
You
know
it's
you're
using
SEO
the
single
as
a
pass-through
to
get
into
the
mesh
and
the
traffic's
likely
already
trusted
and
so
forth.
Then
what
you
still
want
to
need
to
be
able
to
do
is
identify
what
are
those
api's
catalogued
them
in
a
way
that
you
can
share
them
with
other
parts
of
the
organization
and
still
build
things
like
policies
about
how
frequently
users
can
call
them?
You
know
you
still
want
to
track
which
users
are
calling
your
your
services,
your
api's.
A
You
want
to
give
access
keys
to
be
able
to
do
that,
and
you
don't
want
to
use
a
separate,
a
pap,
a
gateway
to
do
that.
You
want
to
do
this
sto
and
that's
why
I
solo,
but
we
built
the
developer
portal
for
for
SEO,
because
we
see
this
problem
of
managing
and
documenting
api's
as
a
holistic
problem.
This
is
not
just
for
external
a
pianist.
This
stretches
across
the
communication
boundaries
that
you
have
any
API
is
that
you
try
to
expose.
A
So
the
API
developer
portal
is
specifically
to
solve
those
problems
where
your
APS
are
running
in
a
service
match
like
SEO,
and
you
want
to
expose
them
to
other
users
within
your
organization.
Others
applications
that
might
already
be
deployed
inside
of
the
mesh,
and
you
need
a
nice
consistent
way
to
organize
them.
So
the
ingress
or
sorry,
the
developer
portal
for
sto
adds
things
like
the
ability
to
expose
api's
they're,
already
running
in
your
mesh
as
it
is
and
I
specify.
A
It
has
some
customization
capability,
so
you
can
customize
them
for
exactly
the
API
product
that
you're
building
or
that
you're
sharing
or
the
branding
that
you
may
have
in
your
organization
and
and
so
forth,
so
how
it
works.
So
the
ACO
developer
portal
has
two
main
components.
One
is
the
the
portal
component
where
we're
exposing
these
you
eyes
and
and
the
api's
in
in
the
in
the
portal
and
the
other,
is
a
controller
component
that
is
watching
for
the
configuration
that
you
use
to
drive.
A
The
developer
portal,
which
I
mentioned
earlier,
is
based
on
custom
resources
and
we're
gonna,
look
at
that
and
then
what
the
controller
does
then
is
taking
that
configuration
whether
it's
specified
in
the
UI
or
specified
in
a
custom
resource
directly.
We
use
that
to
drive
the
behavior
of
the
sto
ingress
gateway,
so
we
know
that
sto
ingress
gateway
is
very
powerful
for
routing.
So
it's
do
developer
portal.
It
is
building
things
like
virtual
services
and
destination
rules
and
so
forth.
A
A
So
you
can
see
the
controller
part.
What
we're
doing
is
watching
these
custom
resources,
which
again
could
be
generated
by
hand
by
templates
by
helm
or
by
a
user
interface
that
comes
with
the
developer
portal
and
we're
watching
specs
like
API
Docs,
which
is
where
we
specify
our
API
documentation
things
like
API
products,
which
is
where
we
specify
them
amalgamation
of
different
api's
that
we
want
to
expose
as
a
single
product.
A
Let
me
see
if
I
can
give
you
a
quick
demo,
an
overview
of
that
we
saw
glue
and
how
glue
is
a
bit
more
powerful
in
terms
of
what
it
can
do.
Glue
has
its
developer
portal,
which
is
the
same.
It's
very
similar,
the
same
development
portal
that
we
see
in
the
UI,
at
least
with
the
issue
of
the
developer
portal
for
SEO.
So
we
can
see
here.
If
we
click
on
ap,
is
we
don't
have
any
API
is
defined,
don't
have
any
portals
define?
What
we
want
to
do
is
create
some
new
API.
A
A
Resources
spec,
let's
do
in
the
classic
pet
store
example-
we're
going
to
create
this
API
doc,
and
if
we
click
on
it,
we
can
come
in
and
see
that
his
it
is
identified.
You
know
it's,
it's
looked
at
the
doc,
it's
identified
the
different
operations,
but
it
gives
us
an
API
editor.
If
we
want
to
go
in
and
make
some
customizations
to
it
and
from
here
we
can
also,
you
know,
look
we're
gonna
create
another
one
as
part
of
this
demo,
because
I
want
to
show
a
use
case
where
we
aggregate
or
stitch
together.
A
Multiple
different
API
is
to
form
an
API
that
we
expose.
So
let's
create
that
and
we
see
the
pet
store
special
anti
store
classic
have
been
created.
Now,
if
we
go
to
API
products,
what
we
can
do
is
specify
the
API
product,
though
the
API
is
set
of
API
is
that
we
want
to
expose
on
honesty
of
ingress
gateway.
So
this
is.
A
A
And
from
here,
based
on
the
docks,
the
AP
aspects
that
we've
created,
we
can
pick
the
different
operations
that
will
be
included
in
this
API
product.
So
maybe
what
we
want
to
do
is
that
we
have
a
version
1
or
a
cloud
classic
version
of
pet
store,
and
we
want
to
keep
its
search
functionality
by
by
finding
pets.
But
then,
when
we
add
pets,
we
want
to
do
that
to
the
new
upgraded
b2
version
of
the
pet
store.
So
if
I
click
create
the
API
product,
we
should
now
see
our
API
product
here.
A
If
I
click
into
it,
we
can
see
some
of
the
details
about
the
API
itself.
We
can
here
will
edit
this
and
give
it
some
default
route
binding,
so
that
if
we
were
to
call
this
that
it
would
let's
save
this
and
that
we
would
be
able
to
fault
around
you
you
can
you
can
see.
This
is
starting
to
map
a
little
bit
to
the
sto
capabilities.
A
We
can
also
specify
routes,
routing
actions
for
four
different
components
in
the
in
the
API
product.
So
now
we've
we've
created
our
API
Docs
we've
created
in
our
API
product,
but
we
haven't
exposed
anything.
Yet
we
haven't
given
anybody
the
ability
to
call
it
or
we're
not
cataloging
it
in
a
in
a
portal
or
anything
before
we
do
that,
let's
go
in
and
create
a
plan,
a
usage
plan
for
this
API.
Let's
call
this
a
pet
store
plan
and
in
this
in
this
area,
we'll
give
it
limiting
of
five
requests
per
hour.
A
So
if
you
were
to
call
this,
it's
five
requests
for
hours
and
then
we
see
that
that
plan
so
before
we
go
on
I
want
to
want
to
come
back
and
point
out
that
all
of
these
all
everything
that's
happening
in
the
developer
portal
is
driven
by
CR
DC,
our
custom
resources.
Alright.
So
why
do
you
get
CR
D
on
this
super
nice
cluster.
A
We
should
see
things
like
the
API
Docs,
so
if
I
do
get
the
API
Docs
and
all
the
namespaces,
we
should
see,
we
have
the
API
doc
for
pet
store,
classic
and
pet
store
special.
If
we
actually
look
at
one
of
them,
we
can
see
that
it
has.
It
has
linked
it
to
where
the
doc
exists.
In
this
case,
it's
a
config
map
and
this
back
end
is
pluggable.
A
A
We
see
the
API
product
and
in
the
resource
and
the
custom
resource
we
specified,
the
different
API
switch
come
from
the
classic
API
dock
and
these
operations,
as
well
as
the
special
API
dock,
and
only
this
operation.
You
can
see
the
default
routing
that
we've
specified
some
image
details
and
the
usage
plans
that
we've
attached
to
this
and
in
the
status.
What
we
end
up
seeing
is
the
actual
open,
API
spec
that
we
will
expose
externally.
A
So
as
a
user
of
the
developer
portal
for
this
do
these
is
this:
is
the
API
cc
this
Amalgamated
api
so
that
all
that
it
looks
good?
Let's
expose
this
API
in
a
portal.
So
if
I
click
create
portal,
this
name
of
those
posts
or
pet
store
portal,
so
the
host,
when
two
three
four
and
I'm
running
this
locally,
if
I
click
on
upload
an
image,
that's
upload.
This.
A
A
The
API
that
we
want
to
expose
on
this
portal
will
expose
the
API
or
the
API
product
that
we
want
to
expose,
and
here
is
the
pet
store.
I
have
a
user
pretty
created
here
and
access?
So
if
we,
if
we
click,
create
the
portal,
what
we
should
see
is
our
portal
get
created
here?
If
I
click
on
it,
you
can
see,
we
do
have
access
to
customizing
some
of
the
some
of
the
branding
components.
So
let's
say
we
want
we
wanna
change.
A
A
A
A
All
right,
so,
let's,
let's
take
a
look
at
some
stuff
here
we
changed.
We
did
change
some
of
that.
That's
all
good!
That's
all
right!
Primary
logo
published
API
products,
so
we
so
this
is.
This
is
a
maybe
a
good
example
to
point
out
here.
That's
all.
We
would
believe
in
being
able
to
delegate
API
and
delegate
responsibility
for
different
components
in
the
API
and
so
in
glue.
For
example,
we
have
the
ability
to
delegate
out
the
routing
rules
to
actual
developer
teams,
so
your
operations
team
can
own
the
security
components.
A
Your
developer
teams
can
own
the
routing
and
transformation
components,
and
we
do
that
using
delegation
and
matching
so
using
especially
in
kubernetes.
This
is
a
powerful
approach
is
to
use
labels
to
then
go
at
runtime
dynamically
find
the
components
that
should
be
part
of
that
late
part
of
that
group
and
in
this
case,
for
portals
we're
expecting
a
matched
label.
A
That
looks
like
this
to
appear
on
the
API
of
Kronik,
which
means
your
portal
and
the
branding
and
all
that
stuff
can
be
owned
by
one
part
of
the
organization
and
specifying
the
EP
is,
and
the
routing
rules.
All
that
stuff
can
be
owned
by
by
a
different
one.
So
that's
the
the
match
label
that
we
are
expecting
to
find
on
our
API
product.
Let's
do
and.
A
No,
it's
still
not
still
not
published,
so
the
demo
seems
to
have
kind
of
a
little
bit
sideways
on
me
right
here,
but
what
I
was
what
I
was
planning
to
show
and
maybe
I
could
show
the
glue.
That
portal
is
that,
once
you
published
your
portals
and
it
would
work
exactly
the
same
way
for
for
the
ischial
portal?
Is
click
on
that?
Oh.
A
Actually,
because
of
the
port
forwarding
and
the
localhost
here,
the
portal
does
does
come
up,
but
I
don't
think
the
API
is
are
quickly
associated
all
right.
Well,
something's
going
something's
a
bit
strange,
maybe
running
glue
an
sto
side-by-side
here
for
the
developer
portal,
stuff
there's
it
might
be
stopping
on.
It
said
I'm,
not
sure,
but
demo
gods
were
not
my
side,
but
this
is.
This
is
effectively
what
it
would
look
like.
You
would
have
the
the
portal
with
the
the
pet
store.
Api
is
exposed
and
you
know
you
can
you
can
call
them.
A
A
Key
I
would
be
denied
if
I
do
use
that
key
and
do
it
too
many
times.
So
that's
three,
four
five,
the
next
time
here
we
should
see
that
our
quota
and
policy
about
usage
kicks
in.
Let's
see
that
that's
been
enforced
there
and
all
of
this
all
of
this
it
is
being
driven
by
NIST
iam
and
they.
So
here's
the
here's
that
sto
virtual
services
that
were
generated
automatically
by
the
by
the
developer
portal.
So
we
can
see
that
we
can
see
the
Envoy
filters
that
were
that
were
added
to
support
the
virtual.
A
A
A
We
can
see
the
the
configuration
for
rate-limiting
and
external
off
and
and
so
forth.
So
it's
configured
that
way
so
wrapping
up
here
and
and
and
kind
of
reiterating
what
we
saw.
The
the
developer
portal
gives
you
a
way
of
specifying
your
API.
Is
that
run
in
your
SEO
service
to
automatically
generate
the
configuration
that
you'll
need
to
be
able
to
call
those
services?
A
You
can
put
things
like
API
key
security
rate,
limiting
policy
around
that
and
allow
that
a
lot
of
developers
to
access
these
api's
and
you
can
customize
the
look
and
feel
of
the
portal
and
and
so
forth.
So
I
encourage
you
to
come
stop
by
our
slack
and
you
know,
get
your
hands
on
the
SEO
developer
portal
or
the
glue
developer
portal
and
give
us
feedback.
A
But
we
think
that
the
division
that
we're
driving
to
here
resonates
with
a
lot
of
our
customers
and
prospects
and,
if
you'd
like
to
get
involved
both
on
the
open
source
side
and
the
you
know,
help
as
a
customer
to
help
drive
the
implementation
of
this.
We
would
love
that
so
definitely
if
they
reach
out
to
us.
B
A
So
you
can
see
glue
is
a
little
more
broad
in
its
implement
and
how
and
how
you
actually
implement
it
and
use
it
to
secure
the
edge
of
your
application
architecture,
so
the
next.
The
next
part
of
that
you
know
that
architecture
would
be
if
you're
using
SEO
and
you
have
glue
in
front
of
it.
Ceo
as
well,
then
just
use
the
glue
developer
portal
because
we
can
still
control
all
of
the
tree.
A
All
of
the
configurations
for
glue
through
the
glue
developer
forum
now,
like
I,
said,
if
you
end
up
with
an
architecture
and
a
common
one
that
we
see
kind
of
springing
up,
is
for
right
and
wrong
right.
There's
there's
pros
and
cons
about
this,
for
what
we
see
springing
up
is
deploying
glue
in
its
own
kubernetes
cluster,
and
maybe
you
have
a
bunch
of
different
glue
glue,
proxies
there
right,
maybe
different
applications
or
like,
but
you
need
an
edge
and
you
want
that
edge
to
be
kind
of
located
in
its
own
kubernetes
cluster.
A
Now
from
there
we
can
apply.
You
know:
zero
trust,
security
policies.
We
can
apply
things
like
the
centralized
configuration
and
allowing
the
teams
to
to
manage
their
own
configurations
and
so
forth
and
still
have
kind
of
from
an
operational
standpoint.
The
the
proxy
is
deployed
in
a
single
kubernetes
cluster.
A
Now,
when
those
when
those
proxies
try
to
route,
they
won't
route
to
any
services
living
in
that
cluster,
their
rut
to
other
clusters,
where
others
where
the
services
will
actually
live
sort
of
leaf
clusters-
and
this
can
be
connected
up
with
sto
for
that
hop
to
the
other
cluster.
But
then,
once
the
traffic
gets
into
that
leaf
cluster,
you
might
not
have
or
need
a
full-blown
API
gateway
in
that
cluster,
maybe
you're
just
using
the
isseo
ingress
gateway
there,
and
so
that's
where
you
know
it's
part
of
the
slides.
A
So
you
have
a
few
different
options
depending
on
your
architecture.
That's
why
I'm
saying
reach
out
to
us,
because
we've
seen
the
myriad
of
different
architectures,
we
can
give
you
the
pros
and
cons
of
each
and
more
importantly,
you
know
kind
of
give
guidance
for
what's
best
for
your
specific
use
case.
A
A
A
B
There's
question
here
on
you-
and
you
actually
touched
on
this
briefly,
but
you
know
you've
shown
that
the
developer
portal
can
expose
API
products
on
the
ingress
gateway.
What
if
they
don't
what?
If
the
user
doesn't
want
to
expose
them
publicly,
but
use
that
to
enforce
concepts
inside
the
service
mesh
like
rate
limits
and
security?
Is
that
a
feasible
use
case
so.
B
A
And
whether
that
gateway
is
exposed
publicly,
that's
a
different,
that's
a
different
consideration.
Now,
if
they're,
asking
specifically,
can
use
a
developer
portal
to
enforce
policy
between
the
services
running
in
the
mesh,
not
necessarily
the
traffic
coming
into
ingress
Gateway,
the
answer
that
is,
that
is
not
something
that
we
can
do
right
now,.
B
A
So
everything
running
through
the
through
the
Gateway
here,
just
like
an
sto,
is
tracked
by
envoy,
and
we
can.
We
can
get
all
of
the
telemetry
everything
that
you
can
get
out
of
envoy
now
for
a
higher
level,
like
per
user,
for
a
customer
per
application
type
statistics.
That
is
something
that
we
were
able
to
capture
as
well,
and
we
do
that
for
loop.
So
we
should.
A
B
A
A
B
A
A
A
Following
either
either
following
a
Opa,
Opa
plugins
that
we
have-
or
we
did
this
specifically
for
this
type
of
integration-
the
OPA,
the
api
keys,
the
LDAP,
the
EDC,
all
the
stuff
that
we've
implemented
in
Glu
at
the
edge
efficient
fire
rolling
all
this
stuff
and
actually
implemented
as
a
set
of
external
plugins.
And
these
plugins.