►
Description
Gloo is a next generation API gateway and ingress controller built with Envoy Proxy to connect, secure and control APIs to any application including legacy monoliths, microservices and serverless functions. Attend this session to get a deeper look at these new features, what use cases they address and a live demo.
Highlights of the release include:
* Developer portal for streamline developer onboarding and productivity
* Simplifying Gloo extensibility with WebAssembly
* Improvements around system performance and stability
* Usability and troubleshooting enhancements
Download the presentation
https://speakerdeck.com/soloio/gloo-api-gateway-1-dot-3-developer-portal-and-more-enhancements
Learn more about Gloo
Website https://www.solo.io/products/gloo/
Download Gloo open source https://docs.solo.io/gloo/latest/
Request trial of Gloo Enterprise https://lp.solo.io/lp-request-a-trial-general
Questions? https://slack.solo.io
B
So,
as
Betty
said,
I'm
gonna
talk
today
about
glue
1.3
1.3
was
our
latest
stable
release
of
glue
if
you're
following
along,
we,
we
typically
release
a
new
kind
of
minor
version
of
glue
every
quarter,
so
we're
currently
working
towards
the
1/4
release.
1/3
was
released
at
the
end
of
the
first
quarter
and
in
this
session,
I
really
want
to
highlight
a
few
of
the
the
key
changes
that
went
into
1/3,
both
internal
and
of
performance
and
stability
side,
as
well
as
new
functionality
with
the
developer
portal.
B
But
before
we
dive
into
it,
let's
just
kind
of
step
back
a
second
and
take
the
10,000
foot
view
if
you're
relatively
new
to
glue,
what
is
it
glue
is
an
API
gateway,
which
is
you
know,
a
piece
of
software.
That's
designed
to
address
challenges
that
organizations
face
as
they
are
kind
of
migrating
towards
some
modern,
innovative
development
practices.
So
often
when
we
talk
to
big
enterprises,
they're
actually
undergoing
several
changes
or
transformations,
one
of
which
is
is
migrating
away
from.
B
You
know
legacy
monolithic
applications
and
development
patterns
towards
micro
services
along
the
way,
often
taking
advantage
of
new
cloud
offerings,
whether
it's
managed
cloud
services
or
things
like
serverless
technology
and
and
then
obviously,
in
terms
of
how
you
run,
how
you
can
hew
package
and
distribute
and
actually
run
software
kind
of
migrating
to
containers
into
container
orchestration
systems
like
kubernetes
and
so,
ideally,
when
you're
choosing
an
api
gateway,
you're
kind
of
one
thinking
about
the
challenges
that
come
from
micro
services.
So
how
do
you
manage
all
these
new
api
is?
B
How
do
you
secure
them,
ensure
that
the
traffic
that's
hitting
your
services
is
secure
and
authorized?
You
want
to
observe,
what's
happening,
be
able
to
kind
of
manage
the
traffic
over
time,
maybe
for
your
upgrade,
workflows
and
so
forth,
but
also
you
want
your
gateway
to
help
with
the
migration
towards
these
new
technologies,
so
being
able
to
kind
of
start
to
deploy
more
of
a
hybrid
cloud
set
up
and
take
advantage
of
things
like
kubernetes
with
the
right
choice
of
gateway.
You
can.
B
You
can
start
to
achieve
all
of
that,
so
glues,
an
API
gateway,
that's
built.
On
top
of
Envoy
glue
as
a
control
point
for
envoy
and
envoy
acts
as
our
data
plane
and
there's
a
couple
key
characteristics
of
glue.
So,
first
of
all,
we
were
kind
of
by
being
built
with
envoy
we're
kind
of
looking
at
where
the
community
is
going
in
terms
of
the
proxy
implementation
envoy.
B
So
if
you
are
an
organization
that
hasn't
yet
gotten
to
kubernetes
or
might
not
go
that
direction,
but
still
want
to
take
advantage
of
kind
of
these
modern
technologies
like
envoy,
you
can
deploy
glue
on
you
know
and
use
it
use.
Other
backends,
like
the
hash
e
stack
to
store
your
configuration
to
orchestrate
changes
and
to
manage
your
secrets.
B
The
other
nice
thing
about
glue
is
that
it's
been
it's
very
flexible
and
extensible,
so
we
want
to
be
able
to
integrate
and
connect
any
application,
regardless
of
where
it
is
or
what
it
looks
like
and
across
any
infrastructure
or
in
any
kind
of
complex,
realistic
enterprise
environment,
and
we
also
built
it
to
be
pluggable.
So
we
can
see
that
new
functionality
is
coming
in
envoy
all
the
time.
B
Glue
was
launched
back
in
2018-2019
early
2019.
At
this
point,
we've
got
a
large
number
of
customers
and
companies
that
are
using
glue.
So
here
you
know
some
logos.
Companies
like
ADP
Park,
Mobile
advantage,
pretty
large
kind
of
well-known
organizations
are
now
using
glue
to
kind
of
drive
their
production,
use
cases
and
I'd
encourage
you.
If
you
want
to
get
a
better
understanding
of
exactly
how
those
organizations
are
using
glue,
we've
got
a
number
of
testimonials
on
our
website.
B
So,
with
the
background
over
the
way,
let's
talk
about
glue,
1.3,
so
glue
1-3
was
released
as
I
mentioned
at
the
beginning
of
at
the
end
of
q1.
So
really
the
you
know,
April
1st
April
2nd
is
when
the
initial
version
came
out
as
you've
probably
noticed
working
with
solo
or
kind
of
watching
solo.
We
we
try
to
push
out
changes
very
quickly,
so
we've
we've
shipped
a
couple
patch
releases
since
then,
I
think
we're
on
one
three.
Six
is
the
version
that
I'm
going
to
be
showcasing
here
today.
B
The
highlights
four
one
three
for
us.
First
and
foremost,
are
the
developer
portal,
so
I'm
going
to
be
giving
a
demo
and
I'll
go
into
a
lot
more
detail
about
this
in
the
second
half
of
this
presentation
also
I'll
come
back
to
that,
but
there
were
a
number
of
other
improvements
or
highlights
to
call
out
for
this
release.
B
We
are
starting
to
experimentally,
support
webassembly.
If
you
go
to
our
website
you'll
notice,
we've
got
a
new
site
that
we've
published
called
webassembly.
Hubbed
we've
been
doing
some
work
with
Google
and
with
the
broader
envoy
community
to
help
make
webassembly
the
future
of
how
you
innovate
and
customize
the
behavior
of
convoy
and
so
with
glue.
B
Beyond
that,
we
made
a
number
of
enhancements
to
better
support
use
cases
around
K
native.
We
made
a
large
focus
of
the
quarter
as
a
team
on
just
the
stability
and
performance
of
glue,
as
well
as
kind
of
the
usability
and
diagnosing
when
there's
a
problem
being
a
little
troubleshoot
and
fix
that
problem
and,
finally,
related
to
all
of
that,
we've
made
a
major
emphasis
on
improving
and
making
the
documentation
much
more
useful
for
everyone.
B
So
just
to
go,
you
know
double
click.
On
those
a
little
bit,
it's
we've
been
with
glue.
We've
been
kind
of
a
provider
for
K
native
serving
for
about
a
year.
Now
we
made
a
series
of
enhancements
together
with
our
community
and
actually
I
meant
to
say-
and
this
is
you
know
it's
a
good
time
to
mention
a
lot
of
the
improvements
both
in
terms
of
feedback,
but
also
in
terms
of
the
code
itself
have
come
from.
You
know
just
a
great
engagement
that
we're
getting
from
our
community.
B
We
really
appreciate
both
the
feedback
and
the
contributions,
and
there
were
a
number
of
folks
that
contributed
changes
to
a
lot
of
the
stuff
that
we'll
be
talking
about
today.
So
you
can
see
the
names
on
the
right
and
I'm
excited
to
see
that
this
number
is
growing
so
for
one-four.
I
expect
we'll
have
even
longer
lists,
as
the
users
are
finding
ways
to
actually
make
contributions
back
to
glue,
which
is
great
to
see,
and
that's
how
you
know
a
lot
of
the
feedback
and
kind
of
contributions
for
K
native
came
about.
B
I
also
mentioned
documentation
too,
to
kind
of
like
highlight
what
that
looks
like.
We
now
have
how
much
more
organized
set
of
Doc's.
So
if
you
go
to
the
docs
website,
which
I
highly
recommend
you
doing,
if
you're
kind
of
researching
or
trying
to
use
glue,
we
now
have
much
better
organized
a
structure,
there's
a
comprehensive
set
of
guides
and
we
tried
to
organize
it
in
a
way
that
you
can
more
intuitively,
find
what
you're
looking
for.
B
B
While
a
central
team
can
kind
of
manage,
the
domain
can
manage
how
that
all
wires
up
together
in
a
virtual
service,
and
we
had
a
customer
that
needed
some
more
fine-grained
ability
to
customize
the
the
ordering
of
the
routes
when
they
get
assembled
in
that
way,
and
so
we
we
introduced
another
feature
called
weights
on
Route
tables
to
help
kind
of
inform
glue
when
there
is
some
important
kind
of
input
about
how
the
rats
should
be
ordered.
And
then
the
other
thing
that
to
call
out
is
we've.
B
We've
done
work
to
ensure
you
know
we
basically
most
of
our
customers
are
operating
in
some
kind
of
limited
or
zero
trust
environment
where
all
communications
should
be
secure
should
be
mutual
TLS,
and
so,
where
this
hasn't
been
the
case
or
you
know
whether
it's
between
glue
and
the
pieces
of
the
data
plane.
So
we,
for
instance,
we
needed
to
expand
the
ability
for
glue
to
talk
to
Cortana,
to
talk
to
the
external
law
server,
to
support
the
TLS
use
cases
that
our
customers
have.
B
Finally,
there's
there's
a
laundry
list
of
just
small
improvements:
either
you
know
performance
stability,
usability
just
to
kind
of
make
the
experience
of
working
with
glue
as
good
as
possible
for
all
of
our
users.
I'm
not
going
to
go
through
them
one
by
one,
but
you
know
a
big
emphasis
was
considering
it.
You
know
urgent
priority
anytime.
We
found
that
we
could
report
errors
more
clearly
out.
B
So
the
the
big
thing
I
want
to
focus
on
and
the
rest
of
the
webinar
is
our
developer
portal,
which
is
a
real
kind
of
new
large
functionality
in
the
one
three
release,
and
it's
going
to
be
a
continued
investment
for
us
moving
forward.
So
in
one
three,
this
is
really
our
MVP,
but
now
I
wanted
to
share
kind
of
how
we're
thinking
about
the
developer
portal.
B
So
far
with
Glu
we've
seen
that
we
can
kind
of
manage
routes,
we
can
secure
them,
but
we're
not
necessarily
kind
of
we
weren't,
necessarily
supporting
the
experience
of
I
want
to
kind
of
pack
a
bunch
of
these
routes
into
an
API
bundle.
I
want
to
expose
that
bundle
to
potential
developers
that
are
building
against
these
api's
so
that
they
can
explore
the
documentation
they
can
request,
API
keys
and
actually
securely
access,
those
api's
and
so
from
them.
In
that
sense,
to
enable
that
we
saw
kind
of
two
pieces
of
the
workflow.
B
First
there's
an
administrative
side
where
someone
is
actually
kind
of
configuring.
A
portal,
an
actual
site
that
we
want
to
add
API,
is
into
specifying
what
those
API
czar,
who
has
access
to
them
and
managing
kind
of
the
scope
when
for
for
API
keys
that
users
can
generate
so
that's
kind
of
the
administrative
side
and
and
in
addition
to
that,
there's
some
lightweight
customizations
so
want
to
be
able
to.
B
Then
there's
the
developer
experience
so
I
need
to
be
able
to
serve
a
website
that
I
can
login
to
or
I
can
have
developers
log
into
and
can
see
the
api's
that
they
have
access
to,
can
explore
the
documentation
and
can
generate
API
keys,
and
so
that's
the
developer
side
and
and
with
the
developer
portal
1/3
release.
We
wanted
to
provide
an
MVP,
an
initial
version
of
both
of
those
experiences
with
that
I'll
shift
into
a
demo
to
show
you.
So,
let's
take
a
look
at
the
developer
portal.
B
The
first
thing
that
we're
going
to
do
is
install
Glu
Enterprise
and
in
1:3
we
now
have
a
new
helm
value
that
we
can
turn
on
to
actually
deploy
the
developer
portal.
So
let's
do
the
install
the
home
value
for
reference
is
here.
It's
called
dev
portal
enabled
true,
so
just
a
single
value
that
we
can
use
to
turn
on
this
feature.
B
Basically,
this
creates
a
service
and
a
deployment,
it's
just
a
simple
API
and
we're
going
to
expose
it
in
Glu
with
a
virtual
service.
That
kind
of
looks
like
this.
So
if
we
will
create
a
virtual
service,
called
pet
store,
we're
going
to
include
some
cores
configurations
so
that
later,
when
we
access
this
through
a
dev
portal,
things
work
fine
and
we're
going
to
be
doing
a
bunch
of
port
forwarding,
rather
than
worry
about
DNS.
So
I'm
just
going
to
access
this
on
the
domain.
B
I'm
going
to
make
sure
that
glues
looks
like
glues,
fully
running,
we
can
see
the
dev
portal
resources
there
and
we
should
immediately
see
this
service
exposed
in
through
envoy,
so
I'm
going
to
port
forward
set
up
my
port
forward
now
so
setup
have
envoy
to
port
forwarded
on
port
8080.
So
now,
if
I
issue,
Qura
quests.
B
We
can
see
that
the
pets
ate
an
API
endpoint
returned
successfully,
so
this
is
exposed
through
glues
gateway
proxy
service
because
we've
configured
that
virtual
service.
So
the
first
thing
that
we
can
do
to
create
a
portal
for
this
is
actually
open
up.
The
glue
UI
need
to
set
up
report
forward
here,
so
I'm
going
to
be
exposing
the
admin
UI
on
port
8081.
B
The
description
and
now
I
was
like
one
of
the
things
that
you'd
be
doing
as
part
of
configuring.
A
portal
is
branding
and
and
styling
so
I'm,
adding
a
hero
image,
which
is
like
a
long
horizontal
image
that
sits
in
the
background
and
then
also
adding
a
logo
and
an
icon.
We
haven't
defined
any
API,
so
we'll
skip
those
sections.
B
One
more
port
forward,
because
now
we're
kind
of
set
to
access
the
actual
developer,
UI
I'll,
be
logging
into
or
I'll
be
connecting
over
into
the
dev
portal
container
or
service,
and
some
port
forwarding
that
as
well
and
and
that's
going
to
be
poor
forwarded
on
one
two,
three
four.
So
that's
kind
of
why
we
defined
that
localhost
1
2
3
4
as
our
domain
for
the
portal,
let's
see
how
that
works
great,
so
now
we're
we're
kind
of
actually
at
we
actually
have
a
portal.
B
This
is
kind
of
a
developer
facing
UI
looks
like
I
still
have
a
session
from
before.
So
let
me
just
clear
the
state.
So
now
we
can
login,
we
can
see
I,
don't
actually
have
API
use
to
view
and
if
I
did,
I
would
need
to
login
anyway,
there's
no
other
static
contents.
This
is
a
very
simple
portal.
First
thing
that
we
can
show
is
adding
some
basic
content.
So
let's
put
a
page
on
here,
just
create
we'll
just
call
it
test.
B
B
And
publish
that-
and
it
should
immediately
take
effect.
So
if
I
go
over
to
the
portal,
we
can
see
that
we
now
see
this
new
tests
tab
in
our
navigation.
The
tests
page
has
the
content
that
we
we
produced,
including
the
markdown
content
rendered
as
you'd
expect
and
because
we
included
it
on
the
main
page.
We
see
this
tile
here.
B
Again,
we'll
can't
we
have
the
opportunity
to
provide
some
kind
of
basic
branding
so
I'm,
going
to
just
use
the
glue
logo
again
and
I'm
going
to
select
the
pet
store
portal.
So
I
want
to
publish
this
API
into
that
portal
and
I
still
don't
have
any
users
or
groups.
So
we
can
leave
it
at
that
and
we
can
now
see
that
this
is
associated
in
the
portal
as
we
expect.
B
B
Don't
yet
have
a
user?
That's,
okay!
The
developers
group
is
going
to
cheat
a
nax
s
to
our
API
in
our
portal
and
I'll
create
a
user
now.
For
me,
the
email
address
here
is
optional,
so
I'm
just
going
to
add
myself
to
that
group
great
so
now,
I'm
a
user
in
the
developers
group
and
the
developers
group
has
access
to
the
API
in
our
portal.
So
if
I
log
in
as
this
user,
it
should
be
able
to
kind
of
see
that
API.
B
That
worked,
but
I
need
to
provide
my
own
passwords,
and
let
me
do
that
and
now
I'm
logged
in
I
can
see
I'm
logged
in
up
here
on
the
top
right
and
if
I
view
the
API
is
now
I
can
see
that
there
is
an
API,
that's
been
published
into
this
portal
and
if
we
click
on
it,
we
can
actually
start
to
explore
what
that
API
looks
like
so.
I
can
see
here
that
there
are
four
endpoints.
B
Here's
an
example
of
a
get
endpoint
I
can
even
try
this
out
and
we
can
see
the
endpoints
returning
the
JSON
response
that
we'd
expect.
So
this
looks
like
everything's
working
as
we
expect,
which
is
great,
and
this
is
standard
swagger
tooling.
So
we
can
see
the
shapes
of
the
models,
as
well
as
all
the
endpoints
and
the
documentation
and
as
an
administrator
if
I
wanted
to
go
and
customize
what
the
API
definition
looked
like
I
could
do
that
and
there's
an
API
editor
that
lets
me
kind
of
change
and
preview.
B
B
So
the
first
concept
that
we
need
to
kind
of
utilize
in
order
to
make
this
possible
is
an
API
key
scope.
A
scope
basically
is
a
way
for
administrators
to
allow
users
to
create
their
own
API
keys,
and
it
defines
the
boundaries
for
those
keys.
So
I'm
going
to
call
this
a
pet
key
scope,
I'm
going
to
assign
it
to
the
pet
store
portal
and
I'm
going
to
say
that
the
swagger
pet
store
that
API
that
we
added
to
the
portal
is
in
scope,
which
means
that
a
user
should
be
able
to
now
login.
B
B
The
other
thing
I
need
to
do
to
actually
lock
down.
The
API
is
associate
with
this
external
off
configuration,
which
basically
enforces
that
Envoy
will
check
the
API
key
before
forwarding
the
request
on
to
this
endpoint
and
so,
and
the
the
auth
config
that
it
was
referenced
is
one
that
we
provide.
That
says.
Basically,
there
needs
to
be
a
key
that
has
this
pet
store,
key
scope
that
we
expect
all
right
pet
Cusco.
B
And
then
I
will
virtual
service
change
to
actually
update
that
now.
This
will
take
a
second
to
actually
propagate
glue,
needs
to
validate
the
config
and
actually
propagate
it,
to
external
loss
and
to
envoy.
We
can
see
the
we
can
see
when
that
takes
effect
by
checking
our
proxy
representation,
which
is
glues,
representation
of
the
kind
of
object
that's
going
to
be
translated
into
envoy
config,
so
I
applied
our
virtual
service
change,
I'm
waiting
for
it
to
take
effect
in
this
proxy
object.
B
The
the
reason
for
this
slowdown
is
we're
kind
of
doing
some
validation.
So
when
these
resources
were
created,
the
we're
first
kind
of
validating
that
the
AWS
config
exists
and
it
makes
sense-
and
it
works
before
we
produce
this
proxy
objects
and
then
glue
is
actually
translating
that
into
envoy
config
and
pushing
it
along.
B
B
B
B
B
B
And
it
looks
like
now:
it
has
been
accepted,
and
so
we
can
continue
at
this
point.
The
virtual
service
should
be
blocking
requests.
It
should
be
configured
to
the
requests
that
don't
include
the
API
key
header
should
be
blocked
as
forbidden.
Let's
try
that
if
we
look
at
the
actual
kind
of
response
we're
seeing
it's
forbidden,
so
that's
exactly
as
we
expect
now
we
can
go
over
to
the
UI
and
actually
try
out
the
endpoint
with
the
key
that
we
just
generated.
So
let
me
grab
that
API
key
go
back
to
the
endpoint.
B
B
A
B
B
I
can
I
can
get
a
200
response
from
this
API
once
I
provide
that
key
as
we
expect.
So
that's
the
basic
demo,
as
you
can
see,
there's
a
few
different
kind
of
pieces
here
that
you
have
to
independently
kind
of
manage
together.
So
the
linking
in
this
version
of
the
API
keys
to
the
portals
and
to
back
to
the
kind
of
actual
routing
configuration
is
a
little
bit
separated.
B
The
great
thing
about
this
is
it's
all
kind
of
declarative
API.
So
all
the
things
that
we
were
doing
through
the
UI
is
are
things
that
we
could
be
doing
just
with
CRTs
and
and
linking
it
together
back
to
the
other
resources
and
kubernetes,
and
in
that
way
this
is
a
fully
declarative
developer
portal
that
could
be
in
production
setting
could
be
managed
entirely
through
standard
get-ups
infrastructure
management.
B
So
I'm
very
much
looking
forward
to
some
improvements
about
you
know,
making
it
easier
to
configure
in
the
next
version
and
the
other
change
that
we're
kind
of
looking
at
is
enabling
kind
of
integration
with
a
customer's
identity
provider.
So
rather
than
having
to
allocate
and
assign
users
in
the
glue
UI,
we
should
just
be
able
to.
You
know,
pull
those
in
from
some
third-party
identity
provider
and
use
the
standard
single
sign-on
mechanism
inside
of
an
enterprise.
B
A
B
So
in
Glu
there
there's
a
couple
ways
of
thinking
about
it.
The
first
is
and
I'm
gonna
focus
on
Glu
enterprise
with
glue
open
source.
You
can
hook
in
your
own
custom,
authentication,
back-end
and
support
whatever
you
want
envoy
has
kind
of
a
specific
API
that
you
can
define
that
you
can
implement
as
part
of
exposing
a
particular
auth
implementation
built
into
enterprise
glue.
We've
got
a
number
of
options
out
of
the
box,
so
and
I'll
show
the
kind
of
list
here.
B
So
we
have
so
there's
basic
auth,
which
is
more
mostly
just
a
dictionary.
This
isn't
really
like
necessarily
a
common
production
use
case.
A
very
common
auth
mechanism
for
user-facing
api's
is
more
of
an
OAuth
Oh
IDC
kind
of
workflow,
where
you
can
kind
of
hook
up
a
consent
screen
in
front
of
your
application
and
the
user
has
to
log
in
and
then
get
redirected
back
to
your
application.
B
We
also
allow
for,
as
part
of
kind
of
acquiring
and
authenticating
you
can
define
an
API
key.
You
could
define
some
custom
logic
in
an
open
policy
agent,
cuff
authorization
step.
We've
got
an
integration
with
LDAP
and
finally,
we've
got
what's
called
plug-in
auth.
So
if
these
aren't
the
right
ways
to
perform
authentication-
or
if
you
need
to
do
additional
checks,
you
can
define
your
own
go
plugin
that
gets
built
and
packaged
into
the
external
lot
server
and
we've
had
people
do
plug-ins
for
things
like
very
customized,
HVAC
validation,
for
instance.
B
Now
a
nice
thing
about
glue
and
our
external
auth
implementation
is
that
we
can
chain
these
things
together.
So
what
I
see
are
two
common
patterns
for
for
kind
of
authentication,
depending
on
whether
the
the
client
is
a
user
or
is
more
of
like
machine
to
machine
so
for
user
facing
a
loss,
one,
a
pretty
common
pattern?
B
Is
you
log
in
with
an
OID
C
flow
with
OAuth,
and
then
you
might
perform
additional
authorization
checks
based
on
the
token
or
the
jot
they
came
back
from
is
from
that
handshake,
and
so
you
could
have
an
OAuth
flow
and
then
a
second
step
in
your
auth
config.
That
does
some
authorization
on
the
jot.
That
was
returned,
for
instance,
with
open
policy
agent.
So
that's
a
really
common
kind
of
integration
that
we
see
if
it's
a
user
facing
API
and
for
machine-to-machine,
usually
it's
starting
from
a
token.
B
Maybe
it's
a
it's
often
a
jot
like
you
know,
they're,
typically
it
kind
of
you.
You
have
a
jot
or
you
acquire
jawed,
and
then
we
can
kind
of
verify
that
job
and
maybe
do
additional
authorizations
similar
to
our
doing
additional
authorizations
when
it's
on
they
on
what
the
on
the
job
for
it
after
a
user
gets
logged
in.
So
those
are
the
two
sides
of
it.
We
often
see
kind
of
with
machine
to
machine.
B
A
So
there
was
just
a
there's,
a
number
of
very
specific
questions
about
if
we
supported
specific
off
systems,
and
so
this
overview
is
great
and
then
going
in
so
on
the
glue
side
and
then
on
the
portal
side.
You
know
you
showed
kind
of
you
showed
the
API
key
and
if
you
want
to
talk
a
little
bit
about
yeah.
B
So
the
the
very
basic
thing
that
we
have
right
now
is
just
API
keys,
where
and
actually
stepping
back,
it's
based
on
users
that
I'm
defining
kind
of
in
as
a
glue
admin
in
the
UI.
So
right
now,
in
this
version,
these
are
backed
by
secrets
and
kubernetes,
really
just
designed
our
initial
customers
had.
Essentially
you
know
under
a
hundred
users
that
are
logging
in
from
as
developer
users
to
the
portal,
and
so
it
was
kind
of
safe
and
like
fine
to
back
those
with
kubernetes
secrets,
but
not
necessarily
like
a
real
long-term
answer.
B
A
Coming
soon,
so,
if
you
all
are
interested
in
this,
you
know
give
this
a
try,
give
the
current
version
to
try
today
and
then
hop
into
the
community
slack.
So
we
can
discuss.
You
know
the
work
and
one
for
for
this
and
if
there's
any
specific
areas
related
to
aught
that
you're
interested
in
for
the
deaf
portal
next
question
here
there
is
a
question
where,
specifically
around
you
know
the
the
routing
and
such
you
know,
there's
a
question
on:
is
this
scenario
possible
glue
to
client
to
glue
with
HTTP
server
web
socket
and
then
client?
B
B
There's
different
types
of
up
streams
designed
really
to
kind
of
handle.
These
kind
of
like
different
scenarios.
I
would
have
to
look
into
the
specifics
of
the
use
case
with
respect
to
sockets,
but
I
suspect,
I,
said
I,
I
think
it's
doable
and
I
suspect
we
already
should
be
able
to
support
it,
because
we've
done
some
work
to
make
to
make
these
kind
of
sockets
dial-up
streams,
work,
yeah.
A
B
It
possible
to
make
it
listen
on
on
non
non
default:
ports.
Basically
yeah
yeah.
That's
that's
all
configurable,
it's
actually
quite
nice
at
thinking
glue,
so
I
can
show
you
some
resource.
Basically,
we
have
this
proxy
object
and
it
will
show
you
essentially
which
bind
ports
we're
using.
So
the
standard
ones,
443
and
80
are
the
two.
You
know
star
the
standard,
the
standard
waves
we
bind
route.
So
if
there
is
an
SSL
configuration.
B
Figura
Belize
are
just
defaults,
so
the
way
in
which
you
can
customize,
that
is
by
looking
at
and
editing
or
adding
new
gateway,
CRTs
big
gateway.
Crt
is
it's
kind
of
the
thing
that
controls
the
Envoy
listener
itself.
So
there
should
be
one
gateway,
CRD
per
port
and
that
port.
You
know
we
don't
need
to
use
the
default
ports,
we
don't.
We
can
customize
these
to
be
different
ports.
B
What
is
somewhat
limited,
I
will
admit,
is
kind
of
our
helm,
chart
values
that
are
that
we
can
customize.
So
we
should,
you
know,
happy
to
you
know.
I
would
if
you
have
trouble
kind
of
figuring
out
how
to
expose
that
port
either
in
the
kubernetes
service
for
the
proxy
or
you
know
now
on
the
container
I
would
just
ping
the
team
we're
happy
to
help,
but
I
think
using
kind
of
non-standard
or
multiple
gateways
on
different
ports
is
a
very
common
use
case.
A
B
Question
so
we
have
been
working
through
kind
of
GRP
see
as
the
next
protocol.
It's
kind
of
definitely
in
something
that
we're
looking
at
now
exactly
what
that
means,
like
I,
think,
a
lot
of
the
swagger
slash,
open,
API,
tooling,
is
geared
towards
rest,
but
I
think
trying
to
provide
something
similar
and
for
our
gr,
PC
customers,
yeah.
A
B
So
the
so
glue
will
work
seamlessly
with
Sto.
We
view
the
api
gateway
and
the
service
mesh
in
general
as
complementary
technologies,
so
with
the
api
gateway,
you're,
really
thinking
about
how
you
secure
and
manage
at
your
application
at
the
edge.
So
this
is
kind
of
managing
the
proxy
that
sits
between
your
clients
or
downstream
clients
and
your
upstream
services
with
the
service
mesh
you're,
now
you're
kind
of
controlling
the
data
plane.
B
That's
all
the
side,
cars
that
sit
between
your
services
and
it's
really
geared
towards
managing
how
services
communicate
with
other
services,
also
known
as
your
east-west
traffic.
So
in
general
we
view
those
two
things
as
complementary
and
really
often
have
separate
concerns.
So
what
you
care
about
at
the
edge
are
probably
a
lot
of
things
related
to
security
rate,
limiting
laugh,
potentially
a
fair
amount
of
like
advanced
routing
features,
but
but
mainly
for
those
kind
of
services
that
are
directly
accessed
by
your
users
and
directly
exposed
through
your
gateway.