►
From YouTube: Gloo - Envoy Proxy and Modern API Gateway Architecture
Description
Today's modernization projects including serverless, Kubernetes and microservices involve more than just how applications are written and deployed - but require new components in the technology stack to properly deploy and operate them. As application services become smaller, loosely coupled together and distributed, how you manage and secure the traffic to them and amongst them becomes critical to a properly behaving application. To enable this, technologies like edge or API gateways and ingress controllers are considered.
Gloo is a next generation API gateway and ingress controller built with Envoy Proxy and designed to support your entire portfolio of applications from legacy monoliths, microservices to serverless. Gloo is designed to connect, secure and control all incoming application traffic and provide a stepping stone to service mesh.
This webinar will cover the following topics:
* What is Envoy Proxy
* Data plane and Control plane interaction
* Gloo Technical Architecture, Features and Benefits
A
A
A
My
goal
for
here
is
to
start
high
level,
but
really
go
pretty
deep
into
the
architecture
of
glue
and
how
we
interact
with
envoy
I
would
love
for
everyone
to
be
able
to
take
away
a
sense
of
not
just
kind
of
the
big
picture,
but
also
what
components
do
we
ship
with
glue?
What
configuration
do
we
manage
and
generally
kind
of
why
we've
architected
it
around
envoy
the
way
that
we
have
and
then
for
and
and
that's
for
kind
of
open
source?
A
So
to
start
things
off.
You
know
we
often
are
talking
to
customers,
organizations
and
they're.
Ultimately,
thinking
about
a
few
different
transformations
so
often
and
organizations
will
have
monolithic
software.
Maybe
this
is
deployed
on
prem
somewhere
on
VMs
could
be
migrated
to
a
cloud
provider.
At
this
point.
Often
organizations
are
kind
of
in
the
process
of
moving
away
from
that
as
a
development
pattern
towards
micro
services,
but
that
also
introduces
complexities
around
where
they
run
or
the
services
running
in
containers.
A
So
the
idea
of
an
API
gateway
kind
of
evolved
out
of
some
challenges
related
to
as
you're
moving
in
this
direction.
How
do
you
manage
your
api's?
How
do
you
actually
expose
this
application
to
your
outside
users
in
a
coherent
way,
and
while
doing
that,
you
need
to
think
about
security.
So
externally
you
need
to
protect
yourself
against
malicious
traffic
coming
in.
A
So
the
glue
gateway-
this
is
a
kind
of
another
way
of
looking
at
that
picture.
You've
got
a
bunch
of
services.
Now
we
can
draw
a
box
around
our
application
and
the
API
gateway
kind
of
paradigm
is:
let's
stick
a
proxy
that
sits
between
end-users
and
the
actual
application,
and
we
call
that
that
kind
of
traffic
path,
the
north-south
traffic,
so
traffic
from
the
users
into
your
application
and
in
our
API
gateway.
The
foundation
for
this
is
envoy
so
with
an
API
gateway.
You
need
some
proxy
that
is
sitting
on
that
request.
A
Path
and
glue
is
based
on
envoy
and
open
source
proxy,
which
I'll
talk
about
a
bit
more
in
a
few
slides.
So
people
often
ask
well
what
that
is
glue,
if
you're
just
using
envoy,
why
do
we
need
something
else
like
what
is
glue
and
what
glue
is
is
ultimately
a
control
plane
for
envoy?
So
we
might
refer
to
envoy
as
a
data
plane,
it's
a
proxy,
but
it
needs
configuration.
A
But
before
we
get
into
the
glue
components,
we
should
start
with
just
why
envoy.
So
when
we
are
starting
glue
or
kind
of
looking
around,
there
are
other
products
that
fit
the
same
kind
of
need
with
respect
to
kind
of
proxying
traffic,
but
envoys
we
saw
envoys
on
emerging
kind
of
proxy
implantation
coming
out
of
lift,
but
now
it's
kind
of
owned
by
a
neutral
foundation
where
there's
a
huge,
vibrant
and
growing
open-source
community.
A
It
was
built
to
be
cloud
native
so,
as
we
are
kind
of
migrating
towards
kubernetes
towards
service
Mash
towards
adopting
some
of
the
cutting-edge
infrastructure
envoy
was
designed
with
that
in
mind.
It's
highly
performant,
it's
been
stable
in
mature
for
a
while,
and
it
works
for
that
use
case
at
lift.
A
The
other
key
selling
point
for
us
is
just
the
ability
to
extend
the
proxy.
So
we
are
we're
excited
by
the
community
and
the
kind
of
changes
in
evolution
of
of
envoy
over
time
that
we've
been
able
to
just
watch,
but
we've
also
needed
to
make
changes
ourselves.
We've
added
features
to
our
open
source
product,
like
you
know,
being
able
to
connect
directly
to
AWS
lambdas.
A
We've
added
features
like
more
robust
transformations
and
when
it
comes
to
Enterprise,
we've
added
features
in
the
realm
of
security,
like
a
Web,
Application
Firewall-
and
this
is
logic
that
runs
inside
the
proxy.
We
were
able
to
build
these
custom
filters
ourselves,
but
still
distribute
envoy.
You
know,
based
on
the
upstream
open
source
envoy,
one
last
thing
to
touch
on
here.
A
So
if
you
can
run
a
web
assembly
runtime
in
the
proxy,
then
you
could
potentially
compile
web
assembly
modules
from
JavaScript
or
go
or
other
languages
which
would
lower
the
barrier
to
entry
for
kind
of
building
and
sharing
and
distributing
customizations
to
the
proxy
even
further.
So
we're
really
all
in
on
envoy
and
the
Envoy
informs
how
we've
built
glue
so
now,
I'm
going
to
talk
about
kind
of
the
open-source
components
of
glue,
there's
four
key
components
overall
and
glue
and
we're
gonna
I'm
gonna
try
and
be
precise.
A
A
So
that's
the
data
plane
and
then,
as
we
were
talking
about
before,
we
need
something
to
actually
serve
configuration.
So
the
next
component
in
glue,
the
first
component
of
our
control
plane,
is
actually
called
glue.
But
what
this
is
is
our
the
actual
kind
of
server
that
is
on
the
other
end,
it's
the
key
responsibility
is
to
send
the
configuration
john-boy
now
envoy,
publishes
in
XDS
a
discovery,
kind
of
API
or
protocol
for
actually
publishing
the
configuration.
A
So
it
was
really
designed
for
this
pattern
and
that
we
we
are
kind
of
sitting
on
the
server
side
of
it
in
order
to
a
to
compute.
The
configuration
for
Envoy
glue
has
a
translation
engine
built
inside
of
it.
So
basically,
what
we
need
to
be
doing
is
translating
some
representation
of
what
the
configuration
is
going
to
be
so
some
kind
of
config
that
contains
all
of
your
listeners.
All
of
your
reports
that
you're
listening
on
and
the
domains
and
routes
for
those
listeners
and
the
features
that
you
want
on
those
routes.
A
So
we
need
some
representation
of
that
kind
of
config
and
glue
has
a
proxy
object.
That
does
just
that
now.
I'm
going
to
look
at
some
of
these
and
kind
of
talk
about
them
as
CRTs
as
if
they
were
stored
in
custom
resources
and
kubernetes,
though
it's
it's
worth
mentioning
and
I'll
talk
about
a
little
more
in
a
few
slides
that
that's
just
a
canonical
representation.
You
could
store
this
config
anywhere.
It's
just
kind
of
the
way
that
we
we
talked
about
it.
So
this
is
our
proxy
object.
A
It's
essentially
an
intermediate
representation
of
all
of
the
routes
for
all
the
listeners,
and
this
is
the
thing
that
is
directly
translated
into
envoys
config.
So
I've
got
one
of
these
I've
installed
glue.
I've
got
one
of
these
locally
called
gateway
proxy
in
my
kind
of
control,
plane,
namespace
and
here's.
A
If
I
go
further
down
in
the
configures,
you
can
see
on
the
listener,
there's
a
set
of
virtual
hosts,
which
have
associated
with
them
some
domains
and
some
routes,
and,
as
we
can
see
at
the
bottom
of
the
bolded
section
here,
the
route
configures
both
on
a
route.
You
have
both
kind
of
matching
criteria
as
well
as
in
action,
and
in
this
case
the
action
is
to
route
to
a
particular
destination,
which
is
an
upstream
called
the
pet
clinic
vet
service.
A
So
up
streams
are
glues,
intermediate
sorry
up,
streams
are
glues,
abstraction
for
a
destination,
so
the
glue
component
of
the
control
plane
is
ultimately
kind
of
looking
at
all
of
your
up
streams,
which
are
your
destinations
for
traffic
and
then
this
proxy
object,
which
is
kind
of
the
definition
of
all
of
the
routes
to
those
destinations
and
then
is
translating
all
you
know,
is
looking
at
that
snapshot
and
translating
that
into
on
void.
Config.
A
Because
of
you
know,
one
of
the
reasons
we
built
this
abstraction
is
so
that
we
could
kind
of
potentially
enrich
the
routing
information
with
additional
information
about
the
destination.
So
you
know
here's
an
example
where
I've
got
a
route
to
an
AWS
upstream,
which
has
my
credentials
in
it.
So
it
can
log
in
and
see
my
the
lambdas
that
are
available
to
me
and
then
I'm
actually,
in
this
case,
routing
to
a
specific
lambda
and
transforming
the
response
in
a
specific
way.
A
A
So
we
have
our
routes
to
destinations
the
destinations.
Are
these
references
to
these
upstream
objects?
So
the
question
often
is
the
next
questions.
Often
where
do
these
up
streams
come
from
and
we
want
to
make
that
as
easy
as
possible
and
as
automated
as
possible
for
simple
use
cases.
So
we've
got
a
discovery
component
and
glue,
which
has
two
different
upstream
two
different
discovery
mechanisms
inside
of
it.
So
the
first
is
called
upstream
discovery
upstream.
A
Discovery
is
basically
looking
at
your
service
discovery
back
ends
and
determining
what
are
all
the
services
that
are
available
and
just
writing
out
in
upstream
our
representation
of
that
destination
to
our
config
store.
So
if
I
immediately
after
installing
glue
and
deploying
a
pet
clinic
demo
application,
if
I
list
kind
of
my
up
streams
in
the
name,
space
I
can
see
all
these,
and
these
were
the
kind
of
ones
that
were
automatically
generated.
A
Now,
as
I
mentioned
before,
you
might
manually
author
up
streams
and
discoveries
an
optional
component,
but
we
we
wanted
it
there
by
default
so
that
we
get
a
nice
getting
started
experience
where
you
don't
have
to
think
about
the
destinations.
If
you
already
have
a
service
discovery
backend
and
we
can
see
which
ones
have
been
discovered
through
a
label
on
the
resource
config
now
the
second
part
of
discovery
is
called
function
discovery.
A
So
the
purpose
of
function
discovery
is
to
take
an
upstream
take
up
streams
that
have
been
defined,
whether
they've
been
kind
of
automatically
discovered
or
manually
created
and
then
enrich
those
up
streams
with
additional
information
about
specific
functions
that
are
available
at
that
destination.
So
as
an
example,
here,
we've
got
an
upstream,
that's
an
AWS
upstream.
It
contains
below
the
fold
here,
a
secret
that
is
my
AWS
credentials.
But
then
the
function
discovery
has
gone
and
looked
asked.
A
A
It's
also
something
that
many
customers
have
wanted
to
use
at
scale
and
in
real
production
settings.
So
integration
with
service
discovery,
backends
is,
is
really
important
to
us.
I
should
mention
that,
on
the
left
hand,
side
of
this
picture
we've
got
secrets,
config
and
discovery
listed.
These
are
kind
of
our
abstract.
A
This
is
kind
of
just
meant
to
indicate
the
underlying
dependencies
in
terms
of
storage
that
we
rely
on.
So
we
rely
on
a
place
to
stay
just
our
secrets.
If
we're
deployed
on
kubernetes,
this
could
just
be
kubernetes
secrets.
If
we're
not
deployed
on
kubernetes,
however,
you
might
use
vault
or
some
other
secret
manager.
A
Similarly,
for
the
config,
obviously
kubernetes
comes
with
at
CD
a
key
value
store,
but
if
you're
not
in
kubernetes,
you
need
to
figure
out
other
sources
for
storing
that
config
and
again,
if
you're,
not
on
kubernetes,
you
might
be
using
other
service
discovery
back-end.
So
you
might
use
something
like
console
as
an
alternative.
Here
we
actually
have
glue
users.
A
A
We
can
put
you,
we
can
kind
of
pull
apart
things
that
and
separate
concerns
for
different
domains
or
for
different
listeners
and
make
it
easier
to
reason
about
and
change
the
configuration
without
introducing
any
kind
of
risk,
so
the
key
abstraction
for
the
user
facing
API
of
glue.
So
the
kind
of
objects
that
users
are
writing
to
define
routes
is
called
a
virtual
service
and
it
looks
you
know.
A
simple
virtual
service
can
look
like
this.
Here.
We've
got
a
virtual
service
called
pet
clinic
and
it
has
a
single.
A
The
the
virtual
service
has
a
single
domain
associated
with
it,
which
is
star.
So
this
is
a
wildcard
matches
on
anything.
So
really
any
request
with
any
host
any
host
on
a
request
would
match
here
and
then
the
the
route
itself
there's
one
route
and
has
a
matcher
for
the
prefix
slash
so
so
again
like
any
any
request
that
comes
in
will
have
that
as
a
as
the
start
of
its
path
or
URI.
So
this
would
match
on
any
request
coming
in
and
then
in
this
example,
I've
routed.
A
A
On
a
virtual
service
is
where
we
can
start
to
introduce
configuration
options
with
respect
to
routing.
So
let's
say
you
know
in
this
in
this
case
of
in
augmented,
the
virtual
service
from
before
and
I've
added
a
few
things
so
first
about
an
option
at
the
virtual
host
level.
So
if
I
were
to
you
know,
so,
if
there
were
many
routes
here,
the
option
at
the
top
says
for
any
route
to
this
virtual
service
have
a
timeout
of
10
seconds.
So
it's
kind
of
a
global
config.
A
You
know
you
can
you
can
kind
of
configure
make
configuration
globally
for
all
the
routes
associated
with
that
set
of
domains
or
you
can
associate?
You
know
you
can
also
configure
options
on
a
route
by
route
basis,
so
in
this
particular
case,
I've
kind
of
gone
ahead
and
on
this
route,
I've
added
some
additional
features,
so
I've
asked
to
rewrite
the
actual
prefix
before
sending
it
forwards.
I,
you
know,
potentially
we're
doing
transformations,
manipulating
headers,
enabling
tracing
there's
a
laundry
list
of
features
that
envoy
and
butt
and
glue
expose
as
options
on
writing.
A
A
A
The
other
thing
that
you
might
do
on
a
gateway
is
enable
global
configuration
for
any
requests
coming
in
to
a
particular
port.
I.
Don't
have
that
in
an
example
here,
but
if
this
was
an
HTTP
listener,
then
we
could
potentially
utilize
any
of
the
features
that
we
support
on
HTTP
routes,
but
at
the
listener
level,
so
that
it
applies
everywhere
globally.
A
So
so,
with
with
the
ability
to
define
new
virtual
services
to
kind
of
add
new
canoe
parts
to
your
application
and
to
enable
new
routes
and
customize
the
behavior
of
those
routes
and
then
with
gateway
objects,
where
you
can
actually
customize
the
what
listeners
exists
on
what
ports
and
what
protocols
and
and
which
virtual
services
are
associated
with
which
listeners
that's.
That
gets
us
a
lot
of
the
way
towards
satisfying
our
customers
use
cases.
A
But
we
have
encountered
still
some
difficulty
with
that,
and
so,
if
you're
a
if
you're
a
customer
where
every
route
is
associated
with
the
same
domain
name,
then
there's
a
potential
for
your
virtual
service
object
to
become
very
large,
because
that
single
object
with
the
single
domain
has
to
have
every
route
defined
on
it.
So
what
we
wanted,
and-
and
just
like,
we
were
kind
of
concerned
about
a
single
proxy
object
being
edited
being
managed
by
users.
A
It's
similarly
difficult
for
a
single
virtual
service
to
be
managed
by
if
it
contains
every
route
across
every
service.
In
your
application,
so
we've
introduced
one
other
abstraction
called
a
route
table
which
basically
allows
you
to.
Instead
of
defining
all
of
your
routes
on
a
virtual
service,
you
can
kind
of
define
a
delegate
object
which
off
of
a
particular
path,
so
maybe
example.com,
slash
marketing
should
be
delegated
to
the
marketing
teams
route
table
and
then
the
marketing
team
might
own.
You
know
slash
marketing
/foo,
like
you
know
all
the
services
associated
with
that
prefix.
A
So
this
is
another
option
in
terms
of
kind
of
distributing
the
ownership
and
the
management
decentralizing.
The
management
of
all
these
configuration
objects
and
that's
critical
for
ultimately
kind
of
making
this
work
at
scale
with
large
applications
and
hybrid
kind
of
complex
environments
and
making
it
work
as
you're
onboarding
new
services
and
bringing
up
new
development
teams
over
time.
A
So,
just
to
summarize
that
picture
what
we've
talked
about
now
is
the
gateway
pod
is
basically
what's
the
gateway
component
of
the
open
source.
Glue
is
basically
watching
those
user-contributed
objects,
they're
watching
virtual
services
and
your
routes
and
any
other
objects
that
might
exist
and
the
gateway
components
responsible
for
writing.
That
proxy
object.
So
rather
than
have
users
edit
it
directly,
as
we
said
before,
we
didn't
want
that.
So
instead,
we'll
have
the
gateway
object.
The
gateway
component
write
that
and
then,
as
when
glue
watches
the
proxy,
and
it
sees
the
proxy,
has
been
updated.
A
They
can
push
a
new
snapshot.
The
nice
separation
of
concerns.
Here
you
know
we
can,
if
the
proxies,
if
the
Gateway
component
goes
down,
you
know
glue,
is
continuing
to
serve
configuration
over
XDS
if
any
other
component
goes
down
and
the
others
aren't
affected.
So
we've
got
a
kind
of
a
clean
separation
in
terms
of
how
we
translate
the
configuration.
A
So
yeah
this
is
kind
of
the
picture.
You
know
just
to
summarize
everything
that
we've
looked
at
before
we're
moving
on
to
enterprise
features
and
I'm
gonna
come
back
to
this
exact
picture,
so
I'm
gonna
move
ahead.
Now,
let's
talk
about
how
Enterprise
glue
has
extended
this
picture
with
some
additional
components.
So
the
first
thing
that
usually
comes
up
with
with
potential
customers
is
audits,
so
at
that
ingress
point
as
you're
kind
of
thinking
about
your
north-south
traffic
flow,
you're,
you're.
Certainly
thinking
about
how
do
I
authenticate
users
of
the
requests
that
are
coming
in?
A
A
So
glue
comes
with
a
bunch
of
Soviet,
so
envoy
has
a
hook.
Web
hook
end
point
for
reaching
out
to
an
implementation
of
an
auth
I,
and
if
that,
if
that's
hooked
up
to
a
route
or
to
a
listener,
then
the
request
comes
in
envoy
on
the
day
on
the
request
path
will
send
that
request
to
the
external
server
ask
to
check
the
request
and
only
continue
down
the
filter
chain
and
to
route
the
the
request.
A
If
the
check
is
okay,
Enterprise
glue
comes
with
an
implementation
of
that
server
called
external
lots
and
the
external
a
server
has
built
into
it.
A
bunch
of
integrations,
I
think
on
the
next
slides.
You
know
you
can
see
some
of
the
ones
that
we've
worked
with
here.
You
know
glue,
it
will
work
with
any
open.
Id
connects
os
provider
and
we've
we've
done
specific,
integrations
or
extensions
to
support,
use
cases
around
jots,
around
authorization
with
OPA
or
open
policy,
agent,
LDAP,
Dex
and
other
tools.
A
We've
also
been
working
to
kind
of
expel,
apropos
and
supporting
API
keys
as
a
mechanism
to
authenticate
and
authorize,
but
the
built
in
into
implementations
aren't
often
sometimes
aren't
enough.
I'd
say
so.
Sometimes
customers
have
some
legacy
authentication
protocol.
That
is
truly
bespoke.
You
know
totally
custom
to
their
use
case,
and
so
enterprise
glue
also
has
a
plug-in
framework,
or
you
can
write
a
little
bit
of
go
code,
and
then
we
provide
the
kind
of
build
container
to
build
that
into
a
dynamic
library.
A
We
provide
kind
of
all
the
installation
hooks
so
that
you
can
automatically
load
that
into
your
installation
when
you
deploy
glue.
So
we
kind
of
try
to
make
it
easy
to
customize
that,
even
if
what
you
need
to
do
is
is
fully
kind
of
implement
of
a
spoke
auth
integration,
and
it's
worth
noting
we
we
support
this
oops.
Sorry,
we
support
this
communication
flow.
So
if
we're,
if
we're
looking
at
open
source
glue,
it
still
has
the
ability
to
configure
in
auth
kind
of
check
on
particular
route.
A
A
A
It
doesn't
exist
an
upstream
envoy
nor
an
any
other
products
that
wrap
envoy,
but
we
implemented
it
with
the
mod
security
library,
and
so
this
is
a
component
that
can
easily
be
turned
on
and
customized
in
order
to
kind
of
protect
from
malicious
traffic,
and
it's
something
that
has
come
up
a
few
times
as
customers
are
kind
of
looking
to
move
away
from
their
legacy.
Api
gateway
toward
something
like
glue.
A
Next
is
rate
limiting
so
with
the
glute,
with
enterprise
glue,
we
ship
a
rate
limiting
server
as
well
and
envoy
kind
of
treats
this
much
like.
So
it's
it's
a
similar
kind
of
request
out
to
another
service.
It's
a
basically
it's
a
check
request
and
then
that
service
kind
of
responds,
yes
or
no.
The
logic
is
a
bit
different.
There's
there's
a
lot
of
rules
around
how
you
define
counters
so
like
how
you
determine
essentially
the
rates
and
where
on
which
criteria
or
on
which
kind
of
descriptors,
you
want
to
apply
those
rates.
A
So
there's
there's
a
fair
amount
of
configuration
that
goes
into
the
rate-limiting
server,
but
envoy
has
the
hook
to
kind
of
plug
right
into
that,
and
I
should
note
the
main
difference.
The
main
reason
this
is
two
separate
calls
and
the
main
difference
between
the
auth
kind
of
web
hook
and
the
rate-limiting
web
hook
is
just
the
behavior
in
the
in
the
failure
case.
A
This
introduces
a
concern
with
some
people
that
hey
we're,
adding
extra
latency
extra
network,
hops
and
I
think
this
is.
This
is
both
like
an
explicit
decision
about
that
trade
off,
so
the
Envoy
community
kind
of
decided,
this
was
the
right
way
to
pull
out
off
and
rate-limiting
from
the
proxy
itself
due
to
the
amount
of
logic
capping
you
potentially
don't
want
all
of
that
happening
in
the
same
process
in
a
case
that
something
were
to
go
wrong.
You
might
need
this
scale
Envoy
itself
differently
than
how
you
need
to
scale
the
off
server.
A
There's
a
variety
of
reasons
you
might
do
this
or
you
might
want
this
trade-off
and
to
mitigate
the
the
negatives
we've
there's
different
ways
that
we
can
deploy
our
external
loss
and
our
rate
limiting
server.
For
instance,
on
the
same,
you
know
as
a
sidecar
to
envoy
itself
on
the
same
machine
so
that
to
just
to
minimize
that
latency
as
much
as
possible.
A
And
then
the
last
key
component
of
glues
is
observability,
so
the
observability
pods
basically
is
responsible
for
watching
the
up
streams
that
you
have
across
your
glue
configuration
and
then
it
dynamically
creates
dashboards
for
each
of
those
up
streams
showing
things
like
error
rate
through
you
know:
Total,
Request,
throughput
and
and
latency.
So
the
latency
through
the
proxy
on
that
particular
latency
to
that
particular
service.
A
And
then
glue
integrates
nicely
with
things
like
Prometheus
Ankur
fauna,
so
so
we
can
tie
into
your
existing
kind
of
metrics
and
dashboard
in
solution
or
glucan.
You
can
kind
of
deploy
it
with
glue
and
we've
had
customers
look
at
integrating
with
other
metrics
backends
like
data
dog,
so
you
know
trying
to
expand
those
integrations
over
time
as
well.
A
Obviously,
I
I
kind
of
didn't
really
mention
this
before,
but
envelope
it
natively
comes
with
a
bunch
of
observability
features,
so
it
ships
it
publishes
a
bunch
of
metrics.
It
there's
easy
hooks
to
enable
tracing
and
and
access
logging.
So
these
all
come.
You
know.
A
lot
of
this
stuff
is
just
packed
into
open
source
glue.
A
And
then
the
other
part
of
our
enterprise,
offering
is
our
UI.
So
this
is
a
picture
of
the
landing
page
of
our
dashboards
and
we
kind
of
view
the
value
of
the
UI
in
a
few
ways.
So,
first
of
all
just
to
kind
of
wrap
your
head
around
the
the
product
and
how
the
translation,
from
virtual
services
to
to
our
proxy
representation
to
the
actual
on
Boyd
config,
just
to
kind
of
be
able
to
see
all
the
configuration
in
your
system
and
how
that
translation
is
happening.
A
When
there
is
a
problem,
we
can
kind
of
highlight
it
here.
So
it's
it's
an
easy,
easy
way
to
kind
of
immediately
get
a
setting.
You
know
check
the
pulse
of
glue
and
then
finally,
we
you
can
kind
of
do
anything
that
you
can
do
from
the
command
line
you
you
can
edit,
either
in
kind
of
a
nice
user
friendly
wizard
or
at
least
in
a
llamo
editor
that
the
UI
comes
with
as
well.
A
We
do
have
a
version
of
this
that's
available
for
open
source.
It's
just
read-only,
so
the
the
observability
features
are
still
useful
even
for
open
source,
it's
just
the
the
right
capabilities,
the
ability
to
edit
the
ml
or
edit.
These
objects.
Isn't
there
and
I
personally
kind
of
view
this
as
really
a
modeling
tool.
So,
as
you
kind
of
move
towards
you
know
in
your
dev
environment,
it's
your
learning
glue,
learning
how
to
write
virtual
services
to
find
routes
bring
online
new
services,
maybe
learn
how
to
upgrade
glue.
A
Maybe
flux,
if
you're
on
kubernetes
to
automatically
kind
of
push
configuration
to
the
cluster
so
glue,
because
all
of
our
objects
are
backed
by
CR
DS
at
that
and
like
the
user
facing
configuration,
is
all
all
can
be
expressed
directly
in
yamo.
We
can.
We
can
kind
of
support
both
a
nice
user
friendly
experience
with
our
tools
like
the
the
UI
and
the
CLI,
but
we
can
also
support,
attribute
ops,
workflow
for
production,
environments,
cool
and
then
the
last
thing
I
wanted
to
cover
we're
getting
to
the
40
minute.
A
A
All
right.
So
that's
what
I
want.
That's
the
what
I
wanted
to
cover
here.
Hopefully
this
gave
a
sense
of
the
different
components
of
glue
the
different
configure
objects--
that
we
expose
and
kind
of
how
how
those
different
components
work
with
those
config
objects
and
then
importantly,
we
wanted
to
kind
of
touch
on
all
the
Enterprise
editions
like.
Why
do
we
have
an
enterprise
product
on
top
of
on
top
of
the
open
source,
repo
and
the
open
source
product?
And
then
how
does
that?
All
you
know
what
this
is
all
based
on
on
voice.
B
So
here
are
some
links
from
that
product
page.
You
can
do
things
like
request
a
demo
or,
if
you'd
like
to
you,
know
download
the
open
source
or
get
started
with
enterprise
and
then
also,
if
we've
got
a
pretty
active
community
in
the
slack
channel
there.
So
there's
always
also
other
users
in
there
and
which
you
can
ask
questions.
B
A
Yeah
great
question
and-
and
my
answer
is
going
to
be
complex
because
there's
a
lot
of
flexibility,
there's
a
lot
of
options,
so
some
people
will
start
to
decentralize
the
configuration
by
using
subdomains.
So,
for
instance,
let's
say
example.com
is
my
main
application
domain
and
I
could
do
marketing
dot.
I
could
have
a
a
virtual
service
with
the
domain
marketing
dot
example.com
that
has
specific
routes
for
the
the
marketing
part
of
the
application,
and
so
you
could.
A
You
could
then
have
the
team
own
that
virtual
service
and
own
all
the
configuration
for
all
of
the
routes
on
that
virtual
service
directly.
But
if
the,
if
you're,
instead
an
organization
where
you
kind
of
want
everything
to
come
in
to
example.com,
and
then
you
want
to
use,
let's
say
a
path
prefix
to
determine
kind
of
the
team
that
that
requests.
You
know
the
team
that
owns
the
service
for
that
request.
In
that
case,
you
might
want
to
utilize
our
delegation
feature
and
a
route
table
so
that
team
can
own
a
route
table.
A
That
says,
you
know
any
requests
coming
in
to
example.com
slash
marketing
here
are
some
additional
routes
off
of
slash
marketing,
some
kind
of
sub
paths
and
that
then
route
to
our
specific
services
that
our
team
owns
glue
makes
it
pretty
easy
to
determine
options,
whether
you're
on
a
route
level
or
kind
of
these
container
objects.
So
you
could,
you
could
have
a
virtual
service
that
define
some
default
off
settings.
A
Some
default
rail,
among
other
other
configuration
that
you
want
to
apply
to
every
route,
and
then
you
can
delegate
you
could
still
delegate
specific
routes
to
off
to
a
route
table
and
that
route
table
would
with
us
inherit.
You
know
with
a
configuration
on
the
container
object,
so
all
of
this
the
route
table
in
that
sense
is
really
just
something
that
the
gateway
component.
It's
only
looks
at
so,
and
it's
just
a
way
to
kind
of
further
breakdown
and
decentralized
the
ownership
of
like
which
teams
get
access
to
which
objects.
A
The
last
thing,
I'll
say,
is
I'm
kind
of
this
I'm
kind
of
implicitly,
assuming
that
there
is
some
are
back
some
of
some
access
control
rules
in
place.
So
this
could
be
broken
down
by
namespace
and
a
kubernetes
cluster
may
be.
The
marketing
team
has
access
to
the
marketing
namespace.
They
can
only
write
configuration
to
that
namespace
and
void.
You
know
it
says
things.
You
know
a
way
that
we
could
make
this
work.
A
Is
the
marketing
team
could
own
a
route
table
inside
of
that
namespace
and
they
could
they're
able
to
write
that,
but
maybe
they
have
no
authority
to
write
a
virtual
service,
no
ability
to
edit
the
virtual
services
to
find
in
other
namespaces.
So
that
way
you
can
provide.
You
know
you
can
kind
of
delegate
the
ability
to
create
routes
and
customize
those
routes
without
kind
of
handing
over
ownership
of
the
parent
and
configuration,
or
you
know
possibly
allowing
one
team
to
disrupt
another
team's
work.
B
A
So
I
think
there's
a
few
parts
of
that
like
it
could
be
that
the
I
couldn't
tell
if
the
question
was
the
up
streams
are
coming
and
going
in
that
sense,
they're,
ephemeral
or
that
the
routes
might
be
added
and
removed
when
those
things
come
and
go
yeah,
maybe
maybe
both
so
glue
like
the
the
technology
that
we
we
use,
that
what
provides
our
extraction
of
the
storage
and
all
the
things
I
was
talking
about.
You
know,
service,
discovery
and
storage
is
extracted
away.
A
That's
a
technology
we've
built
called
solo
kit
and
what
silica
does
is,
let
you
create
watches
on
our
custom
resources
and
so
and
then
we
compute
snapshots
of
the
config
and
then
we
can
kind
of
run
an
event
loop
and
we
can
throttle
that
event
loop.
So
you
know
you
may
be
really
slamming
the
kubernetes
api
server
and
like
constantly
changing
this
object,
but
you
know
we
can
try
and
throttle
that,
so
we
only
can
propagate
config,
maybe
once
a
second.
A
So
that's
our
that's
kind
of
our
approach
is
if
a
bunch
of
events
come
in
for
a
particular
object,
will
kind
of
batch
them
up
on
a
particular
cadence
and
then
push
can
figure
out
configuration
out
on
that
cadence,
so
we're
quite
quite
flexible
I.
Imagine
there
will
be
you
know,
performance
issues,
things
that
need
to
be
debugged
if
you're,
if
it's
like,
if
you're,
really
stretching
the
limits
of
scale
but
our
edits,
but
those
that
could
be
also
at
the
API
server
level.
You
know
we
could.
B
Great
and
there's
a
question
here
on
you
know:
where
is
envoy
hosted,
is
it
inside
kubernetes
and
the
same
question
for
close,
so
the
question
is:
does
the
customer
need
to
and
user
need
to
host
glue,
or
is
it
something
that
we
provide
a
service?
This
is
actually
a
pretty
common
question.
We
get
all
the
time
yeah.
A
So
there's
there's:
we
haven't
really
gone
the
SAS
route,
so
we
don't.
We
don't
really
have
a
managed
offering
there
either
we've
explored
it.
It's
a
little
bit
problematic
in
the
sense
that
how
do
you
control
the
latency?
At
that
point,
you
know
from
the
proxy
to
the
actual
application
or
from
the
users
to
the
proxy.
It
becomes
a
lot
more
challenging.
You
can
really
want
to
kind
of
localize
to
some
degree.
At
least
you
know,
maybe
regionally
or
in
a
data
center
or
in
a
cluster
the
the
proxy
with
your
application.
A
A
To
finish,
the
thought:
I
was
good,
the
localization
on
the
config
path.
So
how
Glu
Glu
sentence
configuration
envoy
over
XDS?
That's
a
little
less
important,
because
that's
not
on
the
request
path
that
doesn't
affect
end-user
experience.
So
we
have
had
customers
that
have
deployed
a
lot
of
components
of
glue.
B
A
We've
designed
it
to
be
flexible
so,
like
we
can
add
a
new
storage
back
in
very
quickly.
We've
we've
done
it
for
like
files
and
for
other
kind
of
more
hacky
things,
I'd
say,
but
that
are
useful
for
the
purpose
of
testing
or
demoing,
but
yeah.
If
there's
new
production
use
cases,
we've
built
glue
to
be
highly
flexible
and
we
can
quickly
make
changes
to
support
that.
A
B
A
Yeah,
so
the
let's
talk
about
that
integration
for
a
second
I
actually
meant
to
have
in
my
slides.
So
if
you
are
using
a
service
match
like
it's,
do
it's
on
going
back?
What
you
really
want
is
you
know
your
gateway
proxy
to
talk
to
the
sidecar
directly,
so
you
know
you
don't
want
any
other
hops.
You
don't
have
to
go
through
stos
gateway.
A
So
so
we've
we've
worked
out
like
a
lot
of
details
regarding
integrating
with
sto
console
connect
and
other
meshes
now
for
the
specific
question
of
tracing
on
voice
supports
a
bunch
of
built-in
support,
as
if
you
can
open
tracing
Jaeger
I
think
is
a
is
the
standard
issue
and
tracing
back
end,
so
we
can.
Basically,
we
can
configure
the
the
proxies
to
be
to
its
compatibly
so
that
we
can
kind
of
trace
through
both,
and
you
know
so
to
some
degree.
A
B
A
A
We
sew
glue
once
it
knows
about
the
upstream
once
that
upstream
is
written,
which
the
discovery,
the
upstream
discovery
mechanism
might
actually
write
itself,
and
then
it
does
the
enrichment
to
detect
the
swagger,
the
open,
API
spec
and
then
add
the
specific
endpoints,
and
then
you
can
route
to
those
endpoints
and
of
canonically
in
glue
config,
rather
than
you
have
to
kind
of
reverse
engineer
that
what's
on
that
spec,
it's
important
to
note
we're
also
building
out
developer
portal
capability.
So
we
want
to
utilize
that
spec.
Take
it
even
further.
A
So
if
your,
if
your
team
is
doing
that-
and
you
also
want
to
as
a
business
trying
to
expose
API
is
to
the
outside
world,
you
should
be
able
to
publish
a
virtual
service
or
routes
of
a
virtual
service
as
an
API,
and
then
users
or
developers
should
be
able
to
login
to
some
kind
of
portal,
see
the
api's
that
are
available
and
actually
kind
of
request
access
to
them
and
do
that.
So
this
is
a
feature
that
we're
actually
kind
of
expanding
on,
as
we
work
out
more
in
the
realm
of
the
developer.
Experience.
B
A
To
be
honest,
it's
a
little
bit
out
of
my
expertise,
but
I
do
know
it's
like
something
that
you
can
do
with
both
TCP
and
HTTP
proxy,
so
I'm
not
sure
exactly
how
you
want
to
architect
it.
But
this
is.
This
is
a
pretty
common
request
for
envoy
users
and
so
yeah
I
think,
there's
kind
of
looking
at
I'm
actually
like
scrolling
through.
A
B
Great
but
cheers
already
in
in
the
community
slack,
so
we
can
follow
up
and
have
a
sidebar
conversation
on
that
specific
scenario,
sometimes
more
curious
on
their
doing
they're
solving
that
with
different
products.
Today,
I
was
curious.
If,
if
this
is
something
could
support,
cool,
so
I
think
actually
there's
some
other
some
additional
questions
in
here,
but
we
can
go
for
one
more
I
think
for
time.
We've
got
a
question
here
on.
Is
there
a
deaf
model
where
they
can
config
and
test
something
without
having
it
without
having
it
done
kind
of
live
in
production?
B
A
An
excellent
question:
this
is
probably
the
single
biggest
pain
point
that
our
users
have
experienced
with
with
glue
and
I'll
provide
a
specific
example.
So
if
you're,
if
you're
authoring
transformations
you
might
be,
we
use
this
thing
called
inja
templates
because
transformations
you
might
want
to
do
some
pretty
complicated
stuff,
manipulating
the
body
or
headers.
You
know
other
things
about
the
request.
A
It's
really
painful
to
have
to
translate
the
constrains
like
glue,
config
and
envoy
config,
send
the
config
envoy
only
for
envoy
to
reject
it.
Now
that
doesn't
take
down
you
know,
your
application.
Glue
will
continue
to
serve
envoy
will
continue
to
serve
the
last
known
good
configuration.
But
but
if
we've
did,
you
know
ideally
we're
kind
of,
as
you
say,
kind
of
supporting
a
better
developer
experience,
so
we've
there's
no
there.
There
are
band-aid
solutions
that
you
could
do
now
with
respect
to
multi-tenant
tendency
and
your
cluster.