►
From YouTube: Gloo Edge Roadmap
Description
SoloCon 2022:
Gloo Edge Roadmap
Speaker:
Chris Gaun
Director of Product Management, Solo.io
Abstract:
In this session, Solo.io's Head of Product, Chris Gaun will lead you through the product roadmap for Gloo Edge.
Track:
Edge and API Gateway
A
Hello,
my
name
is
chris
gohan,
I'm
the
head
of
product
management
here
at
solo.
I
o
thanks
for
joining
us
here
at
solocon.
In
this
session.
I
want
to
talk
about
glue
edge,
what
we
delivered
in
the
1.10,
what
you
could
expect
in
a
1.11
and
give
you
a
taste
of
what
you
could
see
in
the
1.12
and
even
the
1.13.
A
Some
of
the
topics
that
we're
thinking
about.
First,
I
want
to
talk
about
product
management.
Here
at
solo,
I
o
we
have
over
4.7
000
users
in
slack.
This
is
a
very
large
community
here
to
help
you
glue
edge
users,
glue
mesh
users,
istio
users,
I'm
in
there
product
management
team
is
in
there
the
field
engineers,
our
engineers,
you
have
questions.
Please
ask
please
reach
out
directly.
I
love
hearing
feedback.
A
Also,
we've
done
over
100
releases,
actually
hundreds
of
releases
over
the
past
year.
I
know
it
seems
unbelievable,
but
if
you
count
all
the
patch
releases,
ga
releases
and
beta
releases,
it's
a
dizzying
array.
I
can't
even
tell
you
what
the
current
release
of
glue
edge
is
or
glue
mesh.
I
have
to
go
look
up
what
the
latest
patch
version
is.
A
They
do
release
every
hour,
it
seems
like,
and
next
I
want
to
tell
you
how
many
features
we
delivered
it's
over
a
thousand
different
features
and
improvements
that
we
made
in
glue
edge
and
glue
mesh
and
glue
portal.
That's
just
tremendous
effort
and
a
great
job
by
the
engineering
team
by
the
product
team.
Here
at
solo.
A
A
A
We
want
to
hear
from
you
in
github
or
slack
or
from
the
field
engineers
we
triage
hundreds
of
new
issues
every
month
again,
we
want
to
know
they're
your
priority.
We
want
to
know
how
long
it's
going
to
take
engineering,
and
we
want
to
get
that
to
you
as
fast
as
we
can
within
the
timelines
that
you
need
to
be
successful
in
your
projects.
A
Product
management
here
is
not
all
about
delivering
features.
We
want
to
work
with
you,
our
users.
We
often
have
meetings
with
you
every
week
or
every
other
week
or
every
month,
sometimes
quarterly
to
understand
your
projects
and
where
you're
going,
what
requirements?
Do
you
have?
What
requests
for
engineering
do
you
need?
A
A
A
But
the
flip
side
of
that
is
that
sometimes,
no
matter
how
you
build
the
car,
you
could
actually
still
drive
it
into
the
lake
and
what
we've
been
focusing
on
for
the
past
couple
releases
in
glue
wedge
is
just
putting
a
bunch
of
safety
features
and
bumper
lanes
you
could
think
of
it.
If
you're
going
back
to
the
car
analogy,
you
have
to
put
your
foot
on
the
brake
in
order
to
actually
get
it
from
park
into
drive.
We
want
a
lot
more
of
that
within
glue
edge
again.
A
In
our
last
release
of
glue
edge,
1.10,
which
came
out
in
january,
we
had
a
tremendous
amount
of
new
features
again.
Eighty
percent.
Seventy
percent
of
what
we
work
on
is
stuff
that
you,
our
customers
and
end
users,
have
asked
for
we're
triaging
hundreds
of
new
features.
Every
month
we
take
those
we're
putting
into
our
system,
sometimes
we're
getting
new
new
features
every
week,
don't
if
you're
having
pain
points,
don't
keep
them
to
yourself.
I
know
you're
dealing
with
some
legacy,
vendors
and
whatnot
that
you're
just
screaming
into
the
ether
and
nothing's
happening.
A
If
you,
if
you
tell
us,
if
you
put
in
github
issues,
we'll
look
at
it,
I
guarantee
we'll
look
at
it
and
triage
it
and
add
importance
to
it
and
prioritize
it
or
tell
you
hey.
This
is
going
to
take
a
couple
quarters
or
a
little
bit
to
get
to
so
that's
primarily
again
what
we're
working
on
quarter
after
quarter
on
all
of
our
products.
A
This
is
something
that
we
had
in
prior
releases
of
glue
edge,
but
there
were
some
improvements
around
refreshing
tokens
and
user
id
and
cross
aws
account
support
and
a
number
of
bug
fixes
that
we
got
feedback
from
you,
our
users
on,
and
it's
important
to
just
not
just
look
at
the
trees
and
also
think
of
the
forest
here.
What
you,
our
customers
and
users
are
trying
to
do
here,
is
move
from
aws
api
gateway.
You
don't
see
it
as
featureful
as
it's
not
doing
everything
that
you
need
in
an
api
gateway.
A
Sometimes
you
have
50
teams
using
it
today,
and
you
want
to
move
wholesale
from
that
to
glue
edge
to
do
that.
You
need
support
for
kubernetes
services,
which
we
obviously
do
and
are
a
first-class
citizen.
The
second
thing
that
you
need
is
support
for
vms
or
ec2
instances,
and
we
do
that
as
well
or
external
services.
A
A
Some
of
the
other
improvements
that
we
made
in
glue
edge
110
is
to
observability
monitoring
and
alerts.
There's
a
lot
more
that
we
could
do
here,
but
one
of
the
requests
that
we've
gone
in
over
the
course
of
many
different
releases
is
when
you
first
install
glue
wedge.
The
first
thing
that
you
do
is
do
glue
cuddle
check
to
make
sure
that
all
the
components
are
there
that
they're
all
working
as
planned.
A
What
we've
heard
from
you,
our
user,
is
that
you
want
to
be
able
to
have
that
as
a
metric
and
as
an
alert.
So
if
something
does
go
down,
you
will
be
able
to
know
about
it
right
away,
and
so
I'm
glad
that
we
finally
got
to
be
able
to
deliver
that
in
glue
edge.
1.10
and
one
of
the
last
major
initiatives-
and
this
is
going
to
carry
over
to
the
1.11-
is
scale
testing.
Building
a
scaling
framework
and
making
scale
approve
improvements.
A
Now
here
I'm
not
talking
about
the
data
plane
scale,
we
have
users
doing
150
500
million
requests
per
day
on
the
data
plane.
I'm
talking
in
particular
about
the
control
point
things
like
the
number
of
virtual
services.
We
have
users
that
are
going
to
thousands
of
virtual
services
and
we
want
to
be
able
to
improve
that
within
a
reasonable
cpu
and
memory
a
lot
edge,
and
so
here
what
we've
been
doing
is
actually
building
a
test
framework
for
scale.
A
You
can
think
of
it
as
benchmarking
that
we
could
test
every
new
release,
every
ga
release
to
make
sure
that
there's
no
regressions
and
that
we
could
have
a
baseline
benchmark
of
this
is
how
far
you
could
scale
glue
glue
edge
whatever
it
is
say:
3
000
virtual
services,
5
000
virtual
services.
We
just
want
to
give
that
information
to
you,
our
users.
A
A
This
brings
us
to
glue
edge
111.
again,
most
of
the
stuff
that
we're
working
on
are
customer
requests
70
to
80.
That
has
not
changed.
That
will
never
change
other
things
that
we're
going
to
work
on
and
I'll
just
skip
right
to
the
bottom,
because
I've
been
surprised,
we've
been
working
on
this
response.
Caching,
this
is
something
that
you
may
have
heard
about
in
the
roadmap.
This
is
something
that's
a
common
feature
in
api
gateways.
We
have
a
you
know:
we've
had
a
few
requests
for
it
in
the
past.
A
I
think
that's
a
tremendous
feature
that
we're
going
to
deliver
one
of
the
other
improvements
that
we're
going
to
make
in
the
111-
and
you
heard
about
this
when
I
was
talking
about
the
110-
we're
going
to
continue
that
scaling
work,
we're
going
to
combine
a
few
pods
to
really
help
improve
the
cpu
utilization
of
the
control
plane,
we're
going
to
test
it
again,
we're
going
to
get
you
some
benchmark
information.
This
is
something
that
has
been
a
regular
ass
for
from
you.
Our
users
next
is
xds
relay.
A
This
is
a
feature
that
we
delivered
in
1.9.
Now,
let
me
go
back
and
explain
what
xds
relay
is
xds
relay
enables
you
to
have
high
availability
in
xds,
basically,
the
source
of
truth
of
glue
edge.
You
can
think
of
it.
As
you
know,
you
have
the
classical
high
availability
where
we
could
have.
You
know
three
instances
of
glue
edge
control
plane.
Now.
A
So
what
we
did
here
and
what
we,
what
we,
when
we
did
the
investigation
and
post-mortem,
is
that
we
found
that
we
actually
delivered
three
instances
of
xds
and
did
not
accept
bad
configurations
that
this
would
have
prevented
outages.
This
is
a
very
important
feature.
This
is
something
that
we
delivered
in
the
1.9.
A
We
had
some
users
test
it.
We
have
some
feedback
and
things
that
we
need
to
improve,
including
mtls
between
these
three
instances
of
xds
and
some
other
small
things
around
metrics
that
are
mostly
ux
improvements,
so
we'll
be
working
on
that
as
well,
and
so
that's
the
you
know
bulk
of
the
glue
edge,
111
improvements
that
you'll
see,
there's
some
things
around,
making
sure
that
the
helm
charts
are
consistent
so
that
you
could
upgrade.
A
I
would
also
mention
that
in
the
112
113,
the
way
that
we're
thinking
about
glue
edge
is
that
we
can
we're
getting
a
lot
of
users
that
you
know
they're
not
moving
to
istio
right
away,
so
they're
not
going
to
use
glue
mesh
gateway.
What
they're
doing
is
they're
trying
to
replace
apogee
they're,
trying
to
replace
kong
they're
trying
to
replace
aws
api
gateway
or
they
are
using
kubernetes
and
they
need
an
api
gateway
and
they
haven't
used
anything
in
the
past.
A
In
those
cases
we
want
to
be
able
to
do
that
extremely
well
and
to
be
able
to
have
all
those
different
use
cases
fulfilled
so
an
example
of
aws
gateway.
As
I
mentioned,
we
need
to
be
able
to
really
have
first
class
support
for
lambda,
vms
and
ec2,
as
well
as
kubernetes
services,
and
so
that's
something
that
we'll
continue
to
work
on.
The
next
thing
that
we're
seeing
is-
and
we've
heard
from
our
users-
is
that
we
need
to
improve
upon
the
upgrade
experience.
A
A
A
We've
gotten
a
bunch
of
requests
around
that
quite
recently,
so
I
think
you'll
see
that
in
the
112
and
113
road
map
as
well-
and
the
last
thing
here
is
combining
the
ui
with
glue
edge
and
fed
and
portal,
and
the
reason
I
put
this
last
is
because
the
first
part
of
this,
the
first
thing
that
we're
going
to
address,
is
actually
putting
graphql
in
the
glue
edge
ui,
and
I'm
not
going
to
talk
to
you
about
everything
that
we're
doing
in
graphql.
This
is
a
fully
baked
product.
There's
so
featureful.
A
You
should
go
to
keith
babo's
session
who's
on
the
product
management
team.
He's
the
expert
there
he's
going
to
go
through
all
of
graphql
if
you're,
even
more
interested
in
graphql,
you
could
even
go
to
the
workshop
where
you
get
hands-on
experience
with
graphql
and
glue
edge,
but
I
want
to
introduce
that
to
you
because
it
is
a
major
feature
in
the
111
going
and
going
forward.
So
first,
what
should
you
know
about
graphql?
A
Well,
if
you're
familiar
with
the
adoption
stages,
you
have
early
adopters,
you
have
bleeding
edge
users,
and
you
know
very
early
start
of
the
technology
were
somewhere
in
the
early
majority
phase
with
graphql.
There's
a
lot
of
awareness
about
graphql
everybody
knows
about
it,
but
not
all
of
you
are
using
it.
A
Some
of
you
are
in
the
very
early
stages
of
adoption,
some
of
you,
a
lot
of
others,
are
in
the
phase
of
oh
I'm
going
to
adopt
it
next
quarter
or
next
year,
and
so
we
wanted
to
build
this
into
glue
edge
because
we
see
a
lot
of
capability
that
we
could
deliver.
Above
you
know
your
normal
graphql
experience
that
you
currently
have
options
for.
So
what
exactly
do
I
mean
by
you're?
Getting
all
these
new
benefits
by
combining
graphql
with
envoy?
A
A
You
get
a
declarative
architecture
like
you
do
with
all
of
glue
wedge
and
kubernetes.
This
is
what
you
kind
of
expect
when
you're
using
kubernetes,
it
should
be
declarative
and
one
other
big
improvement.
That
you're
going
to
see
is
all
those
api
gateway
features
that
you
have
in
glue
edge
rate.
Limiting
loft
will
be
available
directly
in
graphql
and
then
one
other
thing
is
that
you
can
think
of
you
don't
have
to
write
all
these
new
graphql
services.
A
A
Now
I
want
to
talk
a
little
bit
about
glue
mesh
gateway.
Again,
this
is
a
api
gateway
in
glue
mesh.
Why
am
I
talking
about
in
the
glue
edge
session?
I'm
doing
that,
because
sometimes
we
get
questions
on.
Should
I
use
glue
edge
or
should
I
use
glue
mesh
gateway?
Well,
if
you're
not
using
sdo,
then
you
should
use
glue
etch.
If
you
are
using
sdo,
the
first
choice
would
be
glue,
mesh
gateway,
and
so
where
are
we
in
glue
mesh
gateway?
And
what
do
we
need
to
improve
upon?
A
Well,
we
built
glue
mesh
gateway
because
a
lot
of
users
wanted
to
have
a
single
control,
plane
or
management
plane
instead
of
managing
to
glue
edge,
control,
plane
and
glue,
mesh
gateway,
management,
plane
or
sorry
glue,
mesh
management,
plane
and
so
by
adding
the
api
gateway
features
directly
into
the
glue
mesh
management
plane.
You
get
one
management
plan
to
rule
them
all
all
the
sdo
instances,
as
well
as
all
your
north.
South
api
traffic
and
east-west
api
calls
and
requests.
A
Now,
there's
another
reason,
and
that
is
we
got
a
lot
of
users
or
people
that
are
using
sdo
that
think,
oh,
you
know
there's
I
could
just
use
this
deo.
I
don't
need
an
api,
a
separate
api
gateway
and
it's
true
there's
some
overlap
between
the
features
of
istio
like
mtls
and
things
that
you
would
get
with
an
api
gateway,
but
to
take
those
building
blocks.
Those
fundamental
basic
concepts
that
are
in
istio
and
build
a
full-featured
api
gateway
is
a
giant
mountain
that
you
would
need
to
climb.
A
You
would
need
the
federation,
you
would
need
the
rate
limiting.
You
would
need
the
authentication
and
authorization
we
had
that
in
glue
wedge
and
we
wanted
to
take
those
features
and
put
them
directly
into
the
istio
ingress
and
that's
what
we
did
with
blue
mesh
gateway.
You
get
the
rate
limiting
the
advanced
rate,
limiting
x,
dot
and
everything
that
you
could
expect
from
again.
A
full
featured
api
gateway
directly
in
the
glue
mesh
management
plan.
A
Now,
there's
still
more
to
do.
This
is
an
example
of
the
glue
edge
architecture.
You
can
see
it
on
our
website.
You
can
see
it
in
our
documentation.
So
what
are
we
missing
today
when
you
use
glue
mesh
gateway,
and
what
do
we
need
to
improve
upon?
First
is
the
filters.
We
don't
have
every
single
filter
that
you
have
in
glue
edge
today.
The
data
loss
prevention,
the
web
application
firewall
the
lambda
features.
Those
are
things
that
we
are
building
in
the
2.1
and
the
2.2.
A
The
next
is
services
that
are
not
on
kubernetes
external
services,
those
lambda
services
I
mentioned-
or
services
that
are
on
kubernetes,
but
not
part
of
the
service
mesh.
We
need
to
improve
upon
those
capabilities
within
glue
mesh
and
glue
mesh
gateway
as
well
again,
thanks
for
joining
me
for
this
glue
edge
road
map
session.
A
It's
great
to
have
you
at
solocon,
you've
seen
all
the
excellent
work
that
the
engineering
team
and
product
team
have
done
here
with
the
hundreds
of
releases
and
thousands
of
issues
and
features
and
improvements
that
we've
made
to
in
the
products
over
the
past
year.
All
from
you,
our
users,
the
feedback
that
we
got.