►
From YouTube: [User Call] Improvements and Sneak Peek Kong Gateway 3.0
Description
This month, join Enrique García Cota and Wangchong Zhou (both Senior Engineers at Kong) to discuss the improvements and feature sneak peek of Gateway 3.0.
A
All
right,
let's
get
going
and
people
who
join
when
they
can
thanks
to
everyone
who
is
joining
us
today.
My
name
is
dalia
spaceva,
I'm
part
of
the
developer
marketing
team
here
at
kong,
and
I
would
like
to
welcome
all
of
you
to
our
meikon
getaway
online
user
call.
So
for
today's
presentation
we
have
a
special
talk
for
you
coming
from
wong,
chung
zhou
and
enrique
kota
they're.
Both
senior
engineers
here
at
kong
and
the
topic
for
today
will
be
improvement
and
future
sneak
peek
of
kong
gateway,
3.0,
so
exciting
stuff.
A
At
the
end
of
the
presentation,
we
will
open
it
up
for
q,
a
and
discussion
you'll
be
able
to
unmute
yourself
turn
on
your
video,
but
please
feel
free
to
drop
your
questions
in
the
chat
during
the
presentation
and
we'll
answer
them
at
the
end
yeah.
So,
with
that
I'll
hand
it
over
to
wong
chung
and
enrique
to
start
the
presentation.
B
Cool
hi
everyone,
my
name
is
wanzo,
I'm
working
for
kong
as
a
gateway
engineer.
So,
first
of
all,
let's
talk
about
unified
gateway,
runtime,
so
yeah.
So
after
the
3.0
we're
going
to
introduce
a
new
new
concept,
called
unified
data
plane,
sorry,
unified
gateway,
runtime,
the
runtime.
Here,
it's
all
the
lure
scripting
files,
c
libraries
and
all
the
binaries
into
ronkong.
B
So
before
we
get
to
the
topic
on,
why
do
do
this?
Let's
have
a
look
on
how
we're
doing
it
right
now
so
for
enterprise
version
we
have
it
being
forked
by
the
open
source
version.
We
call
it
the
oss
fork
and
all
the
enterprise
features
and
plugins
or
stuff
being
implemented,
as
we
call
it
intrusive
fork,
which,
at
all
codes
are
spread
over
the
code
space,
and
this
is
causing
several
problems.
The
first
one
is
emerging
compatibilities.
B
For
example,
we
want
to
release
c
and
e
for
the
same
time
and
the
same
real
cycle,
and
we
have
to
resolve
this
merge
conflicts
every
time
we're
doing
the
merge
and
the
second
one
is
about
development
velocity.
So
imagine
you
want
to
develop
something
you
want
to
put
into
as
an
enterprise
open
source
version,
and
you
need
to
open
two,
maybe
two
prs
or
more
to
both
of
the
repository
and
get
the
reviews
and
and
merge,
and
maybe
also
addressing
some
comments
on
both
sides
and
it's
causing
headache.
B
Obviously,
the
last
one,
and
also,
I
would
say
the
most
important
one-
is
the
user
experience.
So
when
people
want
to
switch
from
e
c
to
e
switch
from
the
open
source
front
to
enterprise
version,
you
will
need
to
do
the
manual
menu,
my
menu
migration,
and
you
cannot
just
install
the
enterprise
on
top
of
c
and
make
it
work.
B
B
So
as
the
graph
showing
here,
the
method
could
be
adjust
very
lean,
a
unified
runtime.
You
have
a
balancer,
for
example,
and
the
rotor
also
chaser,
to
implement
the
pre
predefined
works
inside
the
code.
Space
and
either
and
either
the
open
source
version
or
the
enterprise
version,
will
just
become
an
extension
to
the
to
the
metacore
and
all
the
features
like
plugins
and
even
the
core
features
are
being
implemented.
As
extension,
and
those
have
several
advantages.
B
First
of
all
is
having
simpler,
merge
effort
because
you
don't
have
to
come
deal
with
merge
companies
anymore.
The
other
side
is,
you,
can
now
have
a
more
extensive
plugin,
I
would
say
so.
You
can
even,
for
example,
have
plugins
for
router
and
balancer
in
the
future,
and
also
obviously
that
now
you
can
have
a
less
fraction
between
open
source
version
and
to
enter
price.
B
That's
right!
Next,
slides,
please,
okay!
So
the
timeline
we're
talking
about
here
is
a
very
gradually
moved
pattern.
So
we're
not
going
to
be
delivering
this
into
3.0
by
the
first
version,
and
this
will
land
slightly
slightly
later.
So
we
expect
to
expect
it
to
be
arrived
no
earlier
than
to
3.1,
okay.
So,
let's
get
to
the
next
topic,
which
is
at
the
trees
of
pdk.
So,
yes,
as
you
may
already
know,
kong
already
have
a
zebra
king
plugin
and
also
in
the
enterprise
version.
B
B
So,
for
example,
if
you
want
to
follow
the
the
requests
coming
through
into
your
network
during
different
microservices,
a
typical
way
you
can
do
is
to
implement
something
called
distributed
tracing
because
other
other
choices
are
distributed,
multiple
micro
services.
So
with
this
method,
you
can
actually
capture
the
request
from
the
beginning
to
its
end,
expanding
from
multiple
places,
and
there
are,
of
course,
a
lot
of
techniques
to
use
like
open
facing
sky
walking
and
open
telemetry.
B
B
The
ecosystem
is
very,
very
good,
I
would
say-
and
also
it
gives
gives
you
the
good
audio
availability
like
spending
from
logs
tracing
and
also
metrics,
and
you
can
use
it
with
different
api
languages
and
to
implement
the
collector,
also
the
it
will
be
in
golan
or
javascript
for
c
plus
plus
and
it's
a
hot.
It
also
has
a
unified
data
format
and
we
call
it
tree
protocol
and
you
can
implement
it
with
a
different
exporters,
including
jaeger
zipping.
Also,
all
the
code
providers
have
and
let's
go
to
the
next
slide.
B
B
So
maybe
we
also
do
for
jager
and
zipping
also
kafka
yeah.
So
it's
very
exciting
to
see
this
coming
and
the
third
topic
I'm
going
to
discuss
is
the
timer
library,
okay,
so
this
is
about
mostly
about
our
performance
boost.
So
let's
have,
let's
first,
have
a
look
on
what
the
timer
looks
like
and
typically
numerously.
B
Most
of
the
time,
you'll
find
using
timer
is
very
unavoidable,
so
you
want
to
do
jobs
once
in
a
while
or
once
in
a
delay
or
just
look
for
some
like
specific
api.
You
want
to
do
maybe
a
course
socket
in
some
phases,
for
example.
So
let's
take
as
a
plugin
called
http
log,
for
example.
So
it's
the
plugin
when
you
send
the
logs
through
http
protocol
and
what
it
does
is
just
to
flash
access
lock
on
every
request.
B
So
what
we
do
right
now,
it
will
span
a
spawn,
a
timer
every
time
and
it
calls
this
plugin
so
every
time
in
the
request
it
will
spin
up
and
you
plot
a
new
timer.
So
what
we
observe
is
that
using
the
timer
is
not
free.
It's
basically
like
a
fake
request
and
also
a
burst,
restore
some
contacts
when
you
want
to
access
it
and
in
the
timer,
it's
not
going
to
give
you
the
01
compatibility,
it's
going
to
be
complex
as
the
number
of
the
time
it
grows.
B
B
B
You
want
the
timer
system
to
do
and
instead
of
spending
a
timer
in
every
request,
we
just
send
this
job
to
the
timer
library
and
it
will
handle
and
it
will
schedule
the
the
timing
for
you
and
also
execute
the
results
yeah.
We
also
did
a
quick
performance
test
on
the
on
the
timer
itself,
so
it
is
testing
on
on
a
modern
server
without
any
load
on
each
timer.
It
just
slip
for
100
milliseconds
and
just
continue.
B
B
Okay.
So
after
this
topic,
maybe
let's
go
to
something
we
we'll
be
you'll,
be
able
to
download
the
wrong
site.
So
we'll
talk
about
the
images
we'll
have
a
general
availability
in
2.0
the
first.
So
the
two
things
like
flips
and
mdb
I
have
here
is
something
you
might
already
heard
during
the
previous
monthly
call
if
you're
joined,
but
by
this
time
we're
actually
making
the
valuable
carnival
everyone
to
use.
B
B
The
next
stuff
we'll
have,
as
general
ability
is
ndv,
so
I
will
also
quickly
go.
Go
through
the
mdb
story
we
have
so
mdb
stands
for
lightning
memory
database.
It's
basically
something
you
store
the
database
in
sorry
in
the
in
the
memory
and
it
will
also
map
the
the
database
into
a
file
system
file.
So
it
also
kind
of
persisted
positioned
it.
So
we
use
this
mdb
to
replace
the
technique
we
already
have
in
our
sd.
The
shadict.
B
B
Okay,
so
we
test
it
with
the
dbls
deployment
compared
with
with
original
tradict
and
also
mdb
so
and
in
this
performance.
We're
testing
the
the
workload
to
read
it
through
the
config
endpoint
and
to
show
the
memory.
As
you
can
see
here,
the
latency
almost
shrinks
a
half
up
to
switch
mdb,
so
yeah.
So
actually
so.
This
is
very
simple
performance
test
we
have,
but
the
next
topic
will
and
keep
every
key
will
bring
us
and
is
more
about
and
performs
details.
So
I
will
switch
the
microphone
to
enrique.
C
C
It
was
backed
by
a
database
cassandra
and
then
cassandra
and
postgres,
but
some
people
started
complaining
about
having
to
deal
with
the
database
on
their
infrastructure.
So
we
found
that
implementing
a
db,
less
gateway,
which
used
to
use
a
file
for
storing
static
configuration
instead
of
a
database
was
a
good
match
for
these
people,
not
all
of
them,
but
some
of
them
could
use
this
approach
and
a
bit
later
we
released
the
hybrid
mode.
It's
called
hybrid
because
you
have
a
split.
C
A
group
of
comp
nodes
is
in
charge
of
dealing
with
configuration.
They
do
have
a
database
backend,
but
the
com
nodes
that
are
actually
doing
the
boxing.
They
are
using
a
dbls
mode,
so
that's
why
it's
hybrid
some
nodes
have
database,
otherwise
others
don't.
This
mode
is
also
called
control,
plane
and
data
plane
or
cp
and
dp.
C
C
C
C
Okay,
this
is
another
interesting
one.
This
is
related
with
what
one
chunk
showed
before
this
is
the
lmdd
versus
non-lndb
comparison.
In
this
case,
the
good
thing
is
that
the
blue
line
is
on
top
of
the
pink
line
and
that
the
yellow
line
is
on
top
of
the
green
line.
That's
different
versions
of
lmdb
in
community
edition
and
enterprise
edition,
compared
with
each
other
and
on
different
scenarios.
Three
workers,
five
workers,
seven
workers,
so
these
are
the
kinds
of
things
we
have
to
do
in
order
to
make
sure
that
kong
goes
faster.
C
C
This
graph
is
from
yesterday
evening,
so
we
don't
have
all
the
data.
In
particular,
we
don't
have
the
data
of
community
edition
mastery,
so
we
didn't
have
them
last
night.
Probably
we
have
we'll
have
them
today,
but
I
wanted
to
show
several
things.
First,
the
line
goes
up.
That
is
usually
a
good
thing,
and
it
is
in
this
case,
so
we
are
gaining
requests
per.
Second,
as
our
versions
improve.
C
C
C
So
usually
they
work
independently
from
each
other,
and
that
is
good.
That
makes
makes
it
easier
to
grow
horizontally
and
have
more
workers.
If
needed,
there
is
some
an
exception
to
this.
Sometimes
we
want
a
worker
to
communicate
something
that
is
important
for
the
other
workers
to
know.
For
example,
in
the
case
of
a
traditional
gateway,
one
worker
might
have
received
the
order
to
create
a
new
route,
so
the
other
workers
need
to
know
to
update
their
routes.
C
C
C
C
There
is
an
extra
problem
that
this
only
happens
when
you
are
dealing
with
lots
of
workers
like
around
32
workers.
You
start
having
problems
with
the
lock
each
of
these
workers
write
and
read
from
this
shared
dictionary,
which
means
that
when
when
one
of
them
is
writing,
which
is
very
fast,
but
still
it
longs
for
it
for
a
tiny
fraction
of
the
time.
C
C
Every
worker
would
have
a
timer
inside
and
that
time
I
would
periodically
go
over
the
shared
dictionary
list
to
see
if
there
was
anything
new
that
they
would
have
to
to
read,
and
that
is
not
an
ideal
way
to
do
this.
There
is
a
better,
well-known
system
to
do
this
kind
of
thing.
It's
called
pub,
sub
or
publish
subscribe.
C
So
the
first
change
we
are
introducing
is
that
now
one
of
the
workers
is
acting
as
a
broker.
It
is
probably
going
to
be
that
worker
zero
that
I
mentioned
before.
That
does
other
things
besides
proxy,
so
this
will
be
another
thing
to
do
on
that
worker
and
what
pops
up
does
is
basically
a
different
way
of
doing
things.
It
involves
first
publishing,
which
is
the
green
line
at
the
bottom.
When
an
event
occurs,
the
broker
gets
notified
and
then
it's
the
broker's
job
to
notify
everyone
else.
C
Everyone
that
has
subscribed
to
the
event
that
was
published
will
receive
a
notification
or
a
message,
but
the
notification
is
being
done
on
not
on
an
active
wait,
but
on
push
so
the
broker
will
push
the
the
event
to
the
workers.
That
means
that
there
will
be
no
active
waiting
and
everything
will
be
faster.
This
is
how
it's
done.
C
How
pub
sub
is
implemented
almost
everywhere.
One
particular
note
here
is
that
the
threads
that
we
are
using
instead
of
a
timer
are
light
nginx
threads,
which
are
not
the
same
thing
as
a
system,
operative
system
thread.
They
are
much
more
lightweight
and
they
almost
consume
no
resources
while
they
are
waiting
okay.
So
that
is
the
first
thing
I
wanted
to
talk
about.
The
second
one
is
secrets
management.
C
C
C
C
C
C
C
C
C
What
secret
rotation
means
is
that
if
a
secret
changes
on
the
volt
in
your
hashicorp
or
aws
aws
volt,
then
our
control
plane
will
get
notified
and
it
will
update
the
data
planes
automatically
note
about
this.
One.
The
environment
variables
cannot
be
changed,
so
they
can
be
changed,
but
they
cannot
activate
secrets
rotation
only
aws,
hashicorp
and
others
that
we
will
add
in
the
future
will
have
this
support.
C
C
C
C
Plugins
can
now
have
this
ordering
clause
without
before
or
after
sub-clause
inside,
and
this
is
how
you
would
override
the
default
ordering
of
plugins.
So
in
this
case
the
rate
limiting
will
happen
before
authentication,
which
is
completely
against
the
traditional
fixed
order
of
plugins
and
priority,
but
it
can
be
done
now.
C
C
A
C
Access
phase:
the
second
drawback
is
that
there
will
be
some
performance
impact.
As
I
said,
we
are
still
developing
these
features
and
we
haven't
measured
exactly
how
much
performance
is
gets
impacted
here,
but
the
router
will.
The
plugins
iterator
will
have
to
do
more
work
in
order
to
provide
support
for
this
new
feature.
So
when
it
is
active,
it
will
slow
down
a
little
bit.
We
don't
know
still
how
much
but
a
little
bit
the
performance
so
in
critically
fast
routes.
C
C
C
I
can
tell
you
some
things
that
have
not
been
included
on
the
public
changelog
yet,
but
are
coming,
which
are
the
ones
at
the
bottom.
There
will
be
some
changes
in
the
config
file
again,
nothing
huge
fields
that
have
been
marked
as
deprecated
for
a
while
will
stop
working,
and
we
will
have
some
safer
defaults
on
some
fields,
not
a
lot
of
them,
but
some
of
them
distributions
that
have
been
discontinued
by
their
maintainers
will
be
removed
from
our
pipeline.
C
A
C
C
C
C
The
answer
to
that
one
has
to
be
qualified
a
little
bit.
You
can
already
run
a
plugin
twice
in
the
previous
releases.
That
is
something
that
a
lot
of
people
don't
know.
The
trick
is
that
it
has
to
be
run
at
different
places
in
the
routes
which,
by
by
which
I
mean
you
can
run
the
same
authentication
plug-in
twice.
If
you
put
it
on
a
global
scope
and
then
you
are
associated
with
the
customer
as
well,
then
you
will
run
it
twice.
C
B
Yeah,
actually
let
me
let
me
cut
here
and
so
sorry.
Let
me
also
add
one
for
the
time
machine.
So
so
remember
we
talked
about
the
new
ptk
functions.
We
will
have
in
the
tracer
in
3.0,
so
other
action
plugins.
We
are
going
to
support
these
new
pdk
functions
as
well,
so
you'll
be
able
to
get
the
expense
from
the
our
new
code
base
as
well.
B
So
consider
you
you're,
cutting
this
spans
on
your
site,
then
we're
doing
this
on
our
side
in
2.0,
so
you're,
probably
getting
more
granular
expense
for
photochasing
and
probably
but
I'm
not
sure.
What's
the
impression
on
your
side,
so
you'll
likely
get
more
internal
details
about
how
kong
spent
launch
each
phase
is
likely.
So,
but
the
your
existing
work
will
continue
to
work
here,
like
aaron
key
suggested.
C
Okay,
the
last
one
is:
are
there
plans
not
the
last
one
anymore,
other
plans
to
support
secret
management
with
a
azure,
a
key
vault?
I
don't
know
from
the
top
of
my
head.
I
haven't
I.
I
am
not
the
person
implementing
these
features.
I
know
that
there
are
more
votes
in
the
plans
for
the
future,
but
not
for
3.0
for
3.0.
We
are
only
starting
with
two.
The
two
volts
I
mentioned
in
the
presentation.
C
C
C
C
Yes,
okay,
I
understand
the
question
now.
Subscribing
to
events
inside
a
plugin
is
not
something
we
do
at
the
moment
and
I
don't
think
you
will
be
able
to
do
that
in
3.0,
but
I'm
not
100
sure
it
it
might
be
possible.
In
fact,
what
do
you
think?
Can
you
subscribe
to
events?
You
know
plugin
at
the
moment
right
now,.
B
Yeah,
so
I'm
also
not
very
clear
about
the
question.
So
if
I,
if
you
are
you
you're
using
the
like
worker
events
or
class
events
before,
and
then
this
will
continue
to
work,
you
will
probably
need
to
using
the
new
events
library
to
replace
that
to
get
the
similar
effect.
I'm
not
sure
if
you
are
talking
about
this
one
or
you
are
implementing
your
own
events.
Yes,
let's
separate.
C
C
C
So,
as
one
sean
said,
if
you
were
using
the
old
library
of
events,
library
to
register
to
events
and
use
the
events
system,
that
will
not
work
in
the
new
version
of
con,
but
it's
also
not
a
brilliant
change,
because
we
don't
support
that
on
that
level.
On
the
pdk,
however,
changing
that
to
the
new
system
shouldn't
be
super
complicated.
C
In
our
case,
what
is
taking
the
most
time
is
the
test.
A
lot
of
our
tests
are
assuming
that,
when
an
event
happens
in
a
worker,
the
worker
is
immediately
notified
about
the
event
and
the
others
get
a
notification
later,
while
with
the
new
pub
system,
everyone,
including
the
producer
of
the
event,
get
notified
at
the
same
time,
so
that
change
in
our
way
of
handling
the
events
means
that
a
lot
of
our
tests
broke
and
we
have
to
change
those.
But
the
interface
should
be
similar,
maybe
not
exactly
the
same
but
similar.
C
C
C
C
A
No
all
right!
Well,
let's
wrap
it
up,
then.
Thank
you
so
much
enrique
wong
chung,
thanks,
michael
for
helping
apple
with
the
questions
very
much
appreciate
it.
We
hope
to
see
all
of
you
at
our
next
events.
I
wish
you
all
a
very
great
day,
great
rest
of
your
week
and
see
you
soon
see.
You
see
you
soon,
bye.