►
From YouTube: Gloo API Gateway Federation Overview and Demo
Description
Get multi-cluster API gateway management with Gloo Federation, a unified control plane for multi-cluster federation and management of multiple API gateways. Gloo Federation streamlines global resource configuration and failover routing across clusters, clouds, and regions.
This session will cover the following aspects of Gloo Federation:
* Technical Architecture
* Global Configuration, Discovery, and Visibility
* Cross Cluster Failover Routing
* Role Based Access Control
* Demos and Q&A
Learn more about Gloo https://www.solo.io/products/gloo/
Download the presentation https://speakerdeck.com/soloio/gloo-federation-overview-aug-2020
Read the launch article on Gloo Federation https://www.solo.io/blog/introducing-gloo-federation-for-multi-cluster-management/
Questions? Join the community https://slack.solo.io
A
Today
we
have
christian
posta
global
field,
cto
at
solo
and
joe
kelly
tech
lead
here
at
in
engineering
here
at
solo,
io
who'll
be
driving
the
webinar
we
are
gonna,
do
live
q
a
so,
but
we'll
handle
those
all
at
the
end.
So
please
enter
them
into
the
chat
or
q
a
window
as
we
go
as
you
think
of
your
questions
and
then
we'll
handle
all
of
those
at
the
end,
and
with
that
I'd
like
to
hand
it
over
to
christian.
B
C
B
So
we'll
go
into
those
details
again,
I'm
christian
posta
I've
been
at
solo
for
almost
two
years
now,
and
I
came
here
because
I
and
I've
been
involved
in
the
open
source
community
for
a
while
in
service
mesh
land
and
previous
generations
of
technology,
kubernetes
and
so
forth.
But
I
came
to
solo
because
I
really
believed
that
just
like
kubernetes
and
docker
changed
the
way
we
deploy
applications
and
manage
them
at
scale
and
in
cloud-like
environments.
B
I
I
believe
that
there
was
a
lot
of
opportunity
for
solving
the
application
communication
challenges
in
a
very
similar
way,
just
like
docker
kind
of
revolutionized,
how
you
package
your
applications
and
kubernetes.
You
know
with
kubernetes
you
can
start
and
stop
and
check
on
the
health
of
your
application
and
so
forth.
B
And
how
do
you
automate?
How
do
you?
How
do
you
build
put
the
infrastructure
in
place
so
that
you
can
automate
on
top
of
it?
And
so
it's
at
solo?
What
we're
doing
so?
That's
why
I
was
excited
to
come,
come
to
solos,
because
that
is
exactly
what
we
build.
We
build
tools
and
products
to
allow
organizations
to
tie
their
applications
together
to
get
them
to
interact
and
communicate
reliably
securely
and
observably
from
the
you
know,
the
entry
point
of
your
application
architecture.
B
B
Networking
infrastructure
and
that's
where
we
built
glue
glue,
is
our
edge
gateway
or
api
gateway
for
getting
traffic
into
a
microservices
style
environment,
whether
that's
running
in
kubernetes,
which
blue
runs
very
natively
in
kubernetes
or
outside
of
kubernetes,
to
be
able
to
route
to
existing
services
in
kubernetes
or
those
defined
in
other
registries
like
console,
or
you
know
this
lambdas
and
so
forth.
Right.
B
So
that's
kind
of
the
first
step,
you're
going
down
the
path
of
a
microservices
environment
and
you
need
you
need
to
start
solving
these
challenges
around
getting
traffic
in
controlling
it,
routing
it
doing
canary
releases
starting
to
get
rich
telemetry
about
the
traffic
coming
in
to
your
to
your
architecture
and
to
secure
it
most
importantly,
and
how
we
secure
things
at
the
edge
is
slightly
different
than
you
know.
As
we
start
to
go
down
this
path,
the
service
is
talking
to
each
other.
B
You
know
directly
and
that's
where
at
solo
we're
we're
big
believers
in
the
service,
mesh
pattern
or
service
mesh
approach,
and
so
we're
building
solutions
around
that,
including
things
like
service
mesh
production,
support
or
developer
portals
for
service
mesh.
You
know
sort
of
fill
the
gaps
where
our
pr,
our
customers,
you
know,
start
to
try
to
operationalize
this
type
of
infrastructure.
B
You
know
we
come
in
and
help
and
bring
expertise,
as
well
as
the
reality
of
running
these
types
of
frameworks
like
a
service
mesh
across
multiple
clusters,
and
so
we
built
a
product
called
service
mesh
hub
that
allows
you
to
simplify
those
operations
and
then,
lastly,
getting
this
type
of
technology
into
a
brownfield
environment
which
our
customers
are.
Typically,
you
know,
leaders
in
in
banking
and
retail
and
insurance
and
and
so
forth,
there's
a
lot
of
need
for
fitting
backward
compatibility.
B
Let's
say
whether
that's
some
some
things
the
applications
have
been
built
to
do
and
they
need
to
stay
backward
compatible
with
each
other.
Even
though
you
introduce
new
services
and
new
applications,
things
like
security,
you
know
there
might
be
non-standard
security
protocols
that
get
used
so
the
that
last
mile
customization
at
solo,
what
we've
been
very
excited
about
and
contributing
to
and
leading
in
the
communities
is
the
emergence
of
webassembly
and
specifically
webassembly
coming
to
this
type
of
api
infrastructure,
namely
onboard
proxy.
B
You
know
we
see
envoy
is
a
sort
of
foundational
piece
that
enables
a
lot
of
the
application
networking
functionality
that
we
need
with
the
extensibility
of
envoy
and
then
or
of
wasm
webassembly,
and
then
the
ability
to
manage
this
across
a
hybrid
footprint,
whether
that's
in
kubernetes,
outside
of
kubernetes,
between
clouds
on-premises,
and
you
know,
kind
of
helping.
You
treat
these
as
one
set
of
federated
networking
resources
that
you
can
build
automation
on
top
of
and
so
forth,
so
in
this
particular
webinar.
So
that's
what
we're
doing
at
so!
B
That's
why
I
was
excited
and
still
very
excited
about
being
here.
The
part
that
we're
going
to
talk
about
in
this
webinar
is
the
edge
and
getting
traffic
into
your
clusters
and
managing
the
the
security
around
it.
And
then
what
happens
when
you
start
to
deploy
these
into
multiple
clusters
or
multiple
clouds
right,
one
of
the
challenges
of
managing
apis
and
things
like
rate
limiting
and
things
like
service
discovery
and
so
forth.
B
As
in
the
past
right,
this
isn't
exactly
a
new
problem,
but
in
the
past
we
solved
it
in
environments
that
we're
much
more
static
right.
We
we
solved
this
in
in
large
enterprises
by
doing
things
like
introducing
message,
brokers,
right
and,
let's
force
everything
through
the
message,
brokers
and
we'll
try
to
apply
policies
at
the
at
the
message
broker
level
that
evolved
into
well.
Let's
connect
other
things
because,
besides
just
messaging
applications,
let's
connect
services,
and
so
we
came
up
with
this
enterprise
service
bus
right.
B
It
forced
everything
through
these
through
this
bus
and
we
can
apply
security
and
observability
and
and
location
transparency.
This
type
of
stuff
right,
we
can
do
transformations
and
that
evolved
later
then
into
api
management,
which
we
ended
up
doing
the
same
thing
just
you
know,
centered
around
http
protocols.
We
have
we'll
jam
this
this
thing
right
in
the
middle
and
force
all
the
traffic
through
that
and
put
all
our
security
policies
on
that
and
so
forth.
B
What
we're
seeing
is
in
in
these
non-static
or
more
dynamic
environments,
let's
say
kubernetes,
for
example,
that
these
large
centralized
bottleneck,
pieces
of
infrastructure
don't
fit
that
model.
As
well,
services
can
be
can
be
scaled,
elastically
services
can
have
their
ip
addresses
coming
and
going
and
services
can
be
up,
but
but
they're
actually
unhealthy,
right
and
so
dealing
with
the
uncertainty
of
the
application.
Topology
that
exacerbated
by
the
uncertainty
of
the
network
in
general
you
know
makes
it
makes
it
much
more
difficult
to
to
do
this
in
a
highly
centralized
environment.
B
So
with
our
modernization
efforts
and
with
the
technology
that
we
need
to
solve
some
of
these
similar
problems
around
you
know
managing
apis.
We
look
toward
decentralizing
that
model
and
that's
where
something
like
glue
api
gateway
comes
into
the
into
the
picture.
So
glue
is
built
on
envoy.
It
is
built
to
be
a
decentralized
enforcement
point
at
the
edge
and
has
its
api
built
to
reflect
that
right.
B
So
there's
a
lot
of
opportunities
for
delegation
in
this
in
the
glue
api
for
describing
you
know
various
security
and
rate
limiting
and
transformation
properties,
routing
and
so
forth
around
your
apis
and
delegation
and
decentralization
of
the
api,
so
that
individual
service
teams
can
own
the
pieces
that
they
care
about
right.
You
don't
have
to
funnel
and
force
everything
through
a
centralized
team
to
make
a
change
to
your
routing
in
your
api,
for
example,
and
so
so
envoy
envoy,
forms
the
core
on
top
of
glue
or
or
envoy
forms
the
core.
B
We
have
a
control
plane
provided
by
glue
that
you
know
obviously
configures
envoy
and
enables
additional
security
properties
like
oidc
or
oauth2
flows.
Things
like
web
application,
firewalling
rate
limiting
and
and
things
like,
extending
the
model
extending
with
either
security
plug-ins
or
web
assembly
once
that
becomes.
You
know
better,
better
supported
upstream,
although
we
do
have
that
available
in
our
alpha
and
beta
releases
of
glue
and
and
run
natively
in
kubernetes,
so
run
on.
You
know:
custom
resources,
there's
no
extra
databases
that
you
have
to
run
it's
it's.
B
Basically,
a
control
loop
that
provides
api
gateway
like
functionality
inside
of
kubernetes.
So
it
keeps
it
super
lightweight
easy
to
deploy.
You
can
deploy
as
the
ingress
to
kubernetes.
You
can
deploy
it
as
a
gateway
within
tenancy
that
you
might
see
in
kubernetes.
So
that
means
in
different
name
spaces.
B
You
can
run
it
outside
of
kubernetes
and
attach
it
to
the
hashicorp
stack
and
so
forth.
So
a
lot
of
flexibility
very
powerful
and
built
on
a
core
that
was
first
of
all
made
for
this
type
of
dynamic
environment
as
well
as
for
all
the
innovation
in
this
space
is
happening.
So
envoy
is
that
foundational
piece?
B
B
You
don't
want
a
one
one
particular
component
in
a
distributed
architecture
to
go
down
and
cause
a
ripple
effect
right
and
a
cascading
effect,
and-
and
you
know,
there's
there's
all
of
these
other
reasons-
that
data
locality
and
costs,
especially
when
you
start
moving
to
public
clouds.
You
know
moving
data
in
and
out
of
different
zones
costs
a
lot
of
money
and
so
forth.
B
So
you
know
this
decentralized
model,
which
forces
forces
our
organization
forces
architecture
to
be
a
certain
way
that
the
api,
the
ability
to
manage
these
apis
you
know-
has
to
fit
this
model,
and
at
solo
we
that
is,
that
is
core
to
the
way
we
look
at
this
at
this
problem
is
decentralization
for
the
enforcement
points,
but
you
can't
get
away
completely
right
from
from
some
level
of
centralization,
and
so
the
model
that
we
prefer
is
that
of
loose
federation
all
right.
So
you
have
these.
B
B
B
What
is
what
what
these
different
api
gateways
are
doing
and
in
what
environments?
You
know,
what
do
those
environments
look
like
what
services
are?
Are
there
glue
has
a
very
powerful
capability
around
things
like
service
discovery,
so
we
can,
we
can
discover
the
services
are
running
in
those
different
environments,
all
the
way
down
to
the
level
of
the
api
endpoint
all
right.
B
So
we,
if
we
find
the
service
running
in
kubernetes,
we
can
also
do
another
level
and
say:
oh,
this
is
a
grpc
service,
and
this
grpc
service
exposes
these
different
functions,
or
this
is
an
open
api
spec
service
right.
So
we
can
get
very
deep
introspection
about
the
capabilities
of
the
services
in
a
particular
environment.
B
Now,
at
the
management
plane
level,
that's
really
interesting
stuff
to
know,
and
so,
if
you
know
that
service
a
is
deployed
in
cluster
one
and
five,
you
can
do
interesting.
Things
like
if
traffic
comes
into
cluster
one-
and
it's
intended
to
be
to
be
routed
to
to
that
service
and
that
service
actually
goes
down
or
is
misbehaving
momentarily
whatever
it
is,
then
the
gateway
and
cluster
one
can
automatically
reroute
the
traffic
to
the
other
known
location
where
that
service
exists.
Cluster
five
in
this
example
right,
so
getting
a
the
lay
of
the
landscape
understanding.
B
What
what?
What
services
are
running
where
what
are
their
health?
What
are
the
gateway?
Health?
You
know.
Health
properties
and
making
intelligent
decisions
about
routing
in
those
types
of
environments
is
incredibly
powerful
and
it
allows
you
to
simplify
your
architectures
right
in
the
past.
You
might
use
f5s
or
other
expensive
multi-layer
ingress
technology
to
solve
this.
But
now,
if
you
make
the
gateways
smart
enough
and
the
management
plane,
you
know
enables
that.
B
Then
then
you
can
simplify
your
ingress
architecture
and
there's
other
examples
of
this
right:
routing
based
on
locality,
routing
based
on
data
preferences,
routing
based
on
you
know,
shifting
the
traffic
between
multiple
clusters,
multiple
zones
or
multiple
regions
and
so
forth.
So
this
management
plane
gives
a
lot
of
powerful
capabilities
that
layer
on
top
of
this,
this
distributed
architecture,
so
in
in
glue
federation.
B
What
that
looks
like
is,
as
I
just
described,
a
management
plan
that
runs
separately
from
where
the
actual
api
gateways
are
running
and
those
api
gateways
can
be
running
across
multiple
clusters:
multiple
different
zones
independently
right.
So
it's
another
part
of
this
decentralization
that
if
a
particular
api
gateway
goes
down,
that
you
have
some
level
of
failover
and
high
availability,
but
it
doesn't
take
everything
down
and
the
opposite
is
true
right.
So
if
that
management
plays
plane
goes
down,
of
course
you
do
want
to
deploy
4ha
with
active,
passive
type
deployments
and
so
forth.
B
So
it's
a
highly
resilient
architecture,
the
clients
they're
talking
directly
to
the
gateway
in
their
individual
zones
and
that
can
be
specified
by
geo
routing
at
a
higher
level
at
the
l3
level
and
and
the.
But
then
the
gateways
become
smart
enough
and
enabled
by
the
by
the
management
plan
here
and
then.
So
that's
what
we'll
show
you
in
and
some
of
the
demos
that
we
got
so
here's
an
example
of
making
those
edge
gateways
smart
enough
to
do
things
like
priority
routing
or
failover.
B
So
traffic
comes
in
to
a
particular
gateway,
and
it's
intended
for
a
service
food
in
this
case
and
turns
out,
you
know
the
traffic
landed
there
and
food's
not
available.
Maybe
food's,
not
not
healthy
is
returning,
you
know
misconfigured
or
whatever
it
is,
and
so
so
that
the
gateway
then
is
able
to
be
smart
enough
and
say:
okay.
B
Well,
I
know
that
foo
lives
over
here
in
cluster,
whatever
right
in
this
diagram's
cluster
too,
but
I
know
that
it
exists
somewhere
else
and
I
can
just
route
the
traffic
directly
to
where
I
know,
there's
another
food
service
and
the
the
glue
api
gateways.
Here,
like
I
said
that
routing
config
and
that
smarts
about
okay,
you
all,
I
know
where
this
service
is
and
that
service
is,
is
it
because
the
gateways
are
talking
to
each
other
right?
C
C
C
C
Here
I'm
going
to
register
the
local
cluster
as
well
as
the
remote
cluster,
the
blue
and
the
green
clusters.
If
you
will,
and
what
this
process
does
is
create
a
surface
account.
Cluster
role
and
cluster
role,
binding
on
the
remote
or
registered
cluster
that
contains
the
minimum
required
permissions
for
the
glue
fed
controller
to
observe
and
manage
blue
configuration
on
that
cluster.
C
Let's
take
a
look
at
the
glue
instance.
That's
running
on
the
kind
local
cluster
here
here,
you'll
see
that
we've
observed
quite
a
lot
of
information
about
the
glue
instance,
some
simple
things
which
is
used
for
some
implementation
details
of
failover,
such
as
the
ingress
endpoint
that
we
can
divert
traffic
to
in
the
case
of
failover,
as
well
as
some
robust
check
information
which
you
might
be
familiar
with.
If
you've
used
the
gluctl
check
command
to
debug
your
glue
instance.
C
As
observed
by
the
glue
fed
control
plan,
we
also
get
some
additional
information
like
the
number
of
available
replicas
on
the
of
the
envoy
proxy,
as
well
as
like
the
version
of
glue
that
is
running
there
great.
So,
let's
get
started
with
the
failover
portion
of
this
demo.
Let's
take
a
look
at
the
virtual
service
that
I'm
running
on
my
cluster
here.
You'll
see
it's
a
very
simple
virtual
service
that
diverts
all
traffic
to
that
blue
echo
service.
I
referred
to
earlier.
C
C
We
have
delivered
the
glue,
fed,
read-only
console.
This
console
is
capable
of
showing
you
the
status
of
all
of
your
glue
deployments,
as
well
as
keeping
you
up
to
date
on
the
clusters
that
are
registered
to
your
system,
the
virtual
services
that
are
available
there
and
the
upstreams
across
your
whole
environment.
C
Here
we
can
get
some
additional
detailed
information,
a
visualization
of
that
glue,
instant
crd.
We
took
a
look
at
earlier
and
we
can
dive
a
bit
deeper
to
see
the
virtual
service
that
we
had
configured
as
well
as
in
the
event
of
an
upstream
of
failover,
the
entirety
of
that
failover
scheme
and
the
order
in
which
we
will
fail
over
to
remote
upstreams
should
something
go
wrong.
C
And
that
concludes
my
demo.
For
now,
if
you're
interested
in
digging
deeper,
I
welcome
you
to
check
out
the
glue
docs,
particularly
the
guide
section
under
glue
federation,
to
learn
more
about
the
failover
feature,
as
well
as
our
federated
configuration,
multi-cluster,
rbac
and
other
features
as
they're
added
to
glue
fat.
B
Very
nice,
thank
you
joe
for
that
demo.
Let's
go
back
here
and
wrap
up.
You
should
be
able
to
see
my
screen
and
right.
So
the
glue
federation
capability
fits
very
neatly
and
nicely
with
the
the
capabilities
of
glue
and
so
glue
is
a
open
source
project.
First
of
all,
the
with
with
enterprise
capabilities
that
are
open
core
right.
So
what
we
showed
you,
the
the
federation
capabilities,
are
part
of
the
enterprise
product,
but
the
glue
open
source
project
you
can
see
here
in
this
in
this
table.
B
We
have
the
developer
portal
and
glue
fed
and
the
uis
and,
of
course,
all
of
the
security
things
that
we
typically
see
in
our
enterprise
customers,
of
which
some
of
these
are
the
public
facing
ones,
and
we've
done
case
studies
for
so.
If
you
go
to
our
website
or
go
to
our
blog
you'll,
see
some
of
the
specific
use
cases
that
that
we
that
we've
solved
and
some
of
the
problems
that
we've
solved
with
our
customers
here.
B
So
just
as
as
joe
mentioned,
and
we
encourage
you
to
check
out
the
the
documentation
for
glue
check
out
the
open
source
project
join
our
slack
at
slack.solo.io.
That
gives
you
access
to.
Basically
this
this
community
and
wealth
of
information
around
building
these
types
of
application.
Networking
architectures
from
both
the
edge
perspective,
as
well
as
the
service
mesh
perspective
and
web
assembly,
as
I
mentioned
earlier
in
in
in
the
webinar
just
a
shameless
plug.
B
I
guess
I
will
be
doing
a
a
talk
that
covers
some
of
this
same
material,
but
from
a
different
perspective,
which
is
the
you
know.
The
service
mesh
has
been
traditionally
talked
about
as
east-west
managing
right,
we're
trying
to
manage
the
traffic
for
east-west
and
the
apa
gateway
or
the
edge
has
always
been.
You
know
this
is
the
north-south
traffic.
B
What
is
the
difference
between
a
service
mesh
and
an
api
gateway,
and
how
do
they
fit
and
and
we're
going
to
be
doing
more
of
this
type
of
topic.
So
definitely
stay
tuned.
Definitely
come
check
us
out
on
slack
and
visit
our
open
source
communities,
and
with
that,
let's
open
it
up
to
questions
and
yeah,
I
don't
know
I
I've
been
clicking
on
q
a
I
can't
see
the
q
and
a
betty.
So
maybe
you
see
them.
A
B
Yeah
and
so
so,
compliance
covers
a
whole
whole
bunch
of
stuff.
A
specific
question
that
you
asked
about
blacklisting
or
whitelisting
certain
clients
and
areas
from
where
they
originate
so
glue
does
have
the
web
application
firewalling
capabilities
that
are
built
on
top
of
mod
security,
or
it
is
mod
security
right
we've
taken
basically
taking
mod
security
and
put
it
into
envoy
so
that
you
can
enable
those
waff
and
you
know,
tried
and
true
trusted,
waft
capabilities
in
the
gateway
itself,
so
that
that
that's
the
answer
that
specific
question.
B
But
you
know
in
terms
of
compliance,
you
know,
and
data
sharing
or
data
restriction,
and
you
know
network
segmentation
and
so
forth.
Those
will
those
will
also
be
drivers
for
how
you
end
up
architecting
your
your
system-
and
you
know
that
will
that
will
require
this
decentralization
and
glue.
Theory
fits
very
well
in
that
model.
B
And
you
know
we
need
to
figure
out
the
identity
of
that
of
that
user
and
determine
their
trust
level
and
decide
whether
or
not
we're
going
to
allow
that
in,
but
there's
other
things
at
the
edge
like
the
part.
A
big
part
of
api
gateway
is
to
shield
how
you
implement
a
particular
service
from
how
you
expose
it
to
your
clients,
and
you
know
when
you
do
expose
it
to
your
clients.
B
You
want
it
to
be
very
easy
to
find
easy
to
start
to
consume,
and
hopefully
a
self-service
manner
and
document
and
so
forth,
and
so
the
api
gateway
helps
to
facilitate
those
use
cases
which
are
slightly
different
than
you
know.
The
the
use
cases
in
in
the
service
mesh
which
are
more
about,
I
need
to
service
a
needs
to
talk
to
service
b.
B
I
need
to
observe
it.
I
need
to
make
sure
that
it's
resilient
in
the
face
of
failures
and
so
forth
and
client-side
load,
balancing
and
circuit
breaking
in
and
that
kind
of
thing-
and
you
know
you
might
use
envoy
to
solve
both
of
those
problems
or
at
least
to
build
on
top
of
to
solve
both
both
of
those
problems.
So
they
are
very
complementary.
A
And
then
that
kind
of
segues
well
into
you
know
we
made
this
glue
federation
announcement
a
few
weeks
ago,
but
a
few
months
ago
we
also
had
a
refresh
to
something
called
surface
mesh
hub
and
both
work
on
managing
multiple
clusters,
one
in
api
gateways
and
one
for
multiple
clusters
of
service
mesh.
How
would
these
two
work
together?
If
at
all.
B
Yeah
they
they
work
well
together.
In
terms
of
you
know,
at
least
right
now,
glue
federation
would
solve
the
edge
api
gateway
problem.
Like
you
mentioned,
service
mesh
hub,
does
the
exact
same
thing,
but
for
service
meshes
all
right.
Now,
as
I've
been
hinting
at
the
more
you
decentralize,
the
more
you
have
these
deployment
patterns,
the
the
notion
of
north
south
and
east
west
kind
of
starts
to
dilute
quite
a
bit
and
converge,
and
we
I
predict.
We
will
see
that
with
with
our
product.
B
You
know
glue,
fed
and
service
mesh
hub
as
well
that
you
know
that
we're
gonna
be
solving
some
of
the
problems
and
the
you
know.
The
problems
at
the
edge
deployed
out
a
bunch
across
a
bunch
of
different
clusters
is
going
to
look
like
a
surface
mesh,
and
you
know
so
service
mesh
hub,
which
already
manages
the
service
mesh.
B
Should
you
know
fit
nicely
in
that
with
that
model,
as
well
so
they're
they're,
very
complementary,
just
like
a
gateway
and
a
and
a
mesh
are
our
complementary
and
in
general
we
are
going
to
see
a
convergence
of
that
both
in
our
product
stack,
but
as
well
as
the
the
ecosystem
and
the
community
as
well.
I
think
that's
that's
well
on
its
way
and
we're
kind
of
leading.
A
A
This
always
happens
the
minute
I
say
like
that's
all
the
questions
we
have.
We
get
another
one,
but
this
question
here
in
a
multi-tenant
environment
where
you
have
a
service
being
shared
across
many,
can
glue,
be
configured
to
allow
access
of
this
shared
service,
with
only
with
only
the
allowed
applications
that
are
that
can
access
it.
B
A
If
you
all
have
questions
after
this
session,
you
can
always
join
slack.solo
io
we've
got
a
channel
for
glue
as
well
as
glue
enterprise
and
our
engineers
christian
myself,
we're
all
in
there
every
day,
and
we
can
help
answer
questions
as
well
as
you
can
get
input
from
others
in
the
community
who
have
been
setting
up
various.
You
know
configurations
of
glue
for
their
applications.