►
Description
We live in a connected world, and our digital experiences are formed by thousands of services acting as building blocks. As the world becomes more decentralized and services take over, cloud connectivity becomes the key differentiating factor of digital experiences for any organization.
Join Kong Field CTO Melissa van der Hecht 😎 as she discusses how you can achieve end-to-end cloud connectivity for your organization with Kong Konnect. Konnect lets you achieve a cloud native service lifecycle at scale, ensuring consistent security, governance and discoverability of every service through automation.
In this meetup, we’ll walk you through the benefits of adopting a unified cloud connectivity fabric for your organization. You’ll get an overview of:
- Konnect’s benefits, architecture and deployment options
- Creation, testing and publishing of services to the Developer Portal
- Managing across platforms with Runtime Manager
- Publishing and discovering services with ServiceHub
- Monitoring and operating using Vitals
Then, we will jump into Konnect with a live demo from Kong Solutions Engineer, Ross McDonald 👨💻
A
In
hi
everybody,
I
think
it's
really
great,
actually
that
we've
got
such
a
like
intimate
setting,
because
that
means
you
can
interrupt
us
at
will.
I
wish
that
we
were
in
a
room
together,
but
the
with
a
small
group
it
makes
it
closer
to
being.
I
was
saying
this
earlier
to
tara
and
it's
a
little
bit
more
like
being
in
the
pub
I'll.
A
I've
been
running
the
same
poll
for
many
events
now
over
the
past
several
months.
I've
got
a
few
hundred
responses
in
and
there
is
a
very
consistent
theme
that
80
percent
of
people
are
struggling
to
deliver
with
both
speed
and
quality,
and
this
is
a
subject
that
both
ross
and
I
are
incredibly
passionate
about
we're,
not
necessarily
going
to
go
into
detail
on
that
today.
But
this
is
a
particularly
interesting
topic
when
it
comes
to
how
we're
innovating
in
the
roadmap,
some
of
the
other
events
that
we're
hosting.
A
B
A
Thanks
ross,
as
I
said,
please
feel
free
to
unmute
yourselves
at
any
point
type
away
in
the
chat
overall,
I'm
just
going
to
spend
a
few
minutes
kicking
off
by
talking
about
why
we're
seeing
connectivity
become
such
a
difficult
problem
across
all
of
the
users
that
we
speak
with
then
we're
going
to
introduce
you
to
con
connect,
you
might
be
familiar
with
com
gateway.
Con
connect
is
the
same
but
different.
So
we're
going
to
introduce
you
to
what
con
connect
is.
A
A
Taryn
said
a
couple
of
minutes
ago,
don't
be
afraid
to
use
the
zoom
reactions
now
here,
I'm
going
to
explicitly
ask
you
to
use
your
zoom
reactions
if
we
were
in
person
thanks
taran
or
you
can
turn
your
videos
on
and
give
us
some
hands
up
in
real
life,
because
if
we
were
doing
this
in
person,
I'd
be
asking
you
to
put
your
hands
up
in
the
room.
So
instead
pick
your
favorite
zoom
reaction
get
ready
to
click
it.
A
A
There
are
so
many
buzzwords
floating
around
I
for
one
am
really
sick
of
hearing
these
buzzwords
they've
become
completely
meaningless,
but
what
is
interesting
is
they
all
come
from
the
same
place?
We
are
hearing
these
buzzwords
all
the
time,
because
every
single
organization
is
under
pressure
to
innovate,
somehow
through
technology,
according
to
our
latest
digital
innovation
benchmark.
A
Different
organizations
are
at
different
points,
buzzword
time
along
their
journey,
but
the
key
approaches
are
the
same.
This
is
I'm
on
the
left
here,
integrating
into
the
monolithic
applications
that
you
just
cannot
change.
I
know
so
many
organizations
that
are
operating
a
mainframe
still,
for
example,
one
insurer
that
I
speak
with,
has
a
system
called
l70
70
because
they
built
it
in
1970.,
so
we
use
connectivity.
We
use
apis
to
connect
into
these
legacy,
monolithic
applications
that
are
just
impossible
for
us
to
decompose
or
to
remove
at
this
time.
A
A
A
This
is
all
in
response
to
the
way
that
our
landscapes
are
evolving,
not
that
long
ago,
with
the
left-hand
side
of
this
graph
diagram.
Here,
we
all
relied
on
the
monolith
right.
We
had
not
that
many
apps
everything
was
on
premise.
Loads
of
it
was
jvm
based
there
wasn't
a
pre.
There
was
a
pretty
slow
pace
of
change.
A
Our
environments
were
really
quite
homogenous.
They
were
very
much
the
same,
and
the
majority
of
organizations
that
we
work
with
are
on
this
modernization
of
the
monolith
journey,
because
moving
away
from
this
static
environment
is
difficult
because
change
was
never
really
factored
in
as
a
constant
back
back
then,
but
I
am
teaching
everybody
to
suck
eggs
here.
I'm
sure
we're
no
longer
in
that
environment
right
things
are
now
so
much
more
complex.
A
We've
seen
cloud
in
cloud
environments
emerge
docker,
kubernetes,
automation,
microservices,
serverless,
platforms
that
we
need
to
build
on
new
types
of
programming
languages,
new
types
of
application
development
patterns.
There
are
different
teams
now
and
team
structures
in
organizations.
Technology
is
something
that
is
significantly
more
accessible
to
end
users
and
end
developers
than
it
used
to
be.
A
This
means
that
the
world
that
we're
in
is
so
is
now
so
much
more
complex
than
it
used
to
be.
We
don't
just
have
a
couple
of
a
couple
of
systems.
Anymore,
we've
got
hundreds,
we've
got
thousands
and
therefore
connecting
these
systems
together.
There's
obviously,
a
growing
number
of
services,
but
making
this
harder.
A
A
Everything
is
becoming
more
complex
and
more
distributed
than
before,
and
this
means
that
the
ways
that
we're
used
to
actually
managing
reducing
complexity-
just
don't
match
anymore
with
this
landscape,
it
doesn't
just
stop
there.
There
are
new
types
of
connectivity
that
we
also
need
to
manage.
Now
that
we
didn't
used
to
have
to
there's
connectivity
within
applications.
A
This
is
breaking
our
monolith
down
into
microservices.
We
have
a
group
of
microservices
acting
together
as
one
applications.
Those
microservices
need
a
reliable
way
to
communicate
with
each
other.
They
need
a
way
to
discover
where
each
other
is.
We
need
load
balancing
between
the
microservices.
We
need
security
applied,
particularly
if
we're
going
across
network
boundaries.
A
A
This
is
connecting
up
our
monolith
that
we
can't
change
to
our
microservices-based
application
to
our
cloud-native
apps
that
we're
building
today
in
kubernetes,
and
then
we've
also
got
connectivity
needed
at
the
edge
exposing
our
apis
to
partners
to
consumers
to
the
general
internet.
This
is
thinking
about
exposing
our
api
or
our
service
as
a
product.
A
A
A
So,
in
order
to
do
connectivity
properly
follow
best
practice
now
the
requirements
that
we
have
from
our
behaviors
from
our
technology
are
much
more
varied.
We
need
to
provide
end-to-end
connectivity,
that's
what
we
just
looked
at
the
connectivity
within
applications
between
applications
and
at
the
edge
across
different
network
boundaries.
A
We
need
to
support
not
just
an
on-premise
environment
or
a
specific
cloud
provider.
We
need
to
support
anything
and
everything
and
all
of
the
various
things
that
exist
in
the
middle
between
that,
because
innovation
right
is
getting
a
new
technology
sticking
in
really
quickly
playing
around
developing
a
prototype.
If
you
don't
have
or
provide
engineers
with
the
freedom
to
do
that,
you're,
preventing
innovation,
hybrid
and
multi-cloud,
I
think
we
are
all
very
familiar
with
these
terms.
A
Obviously
it's
a
requirement
that
every
single
part
of
your
stack
needs
to
support
things
need
to
be
kubernetes
native
as
well.
I
remember
not
even
that
many
years
ago,
talking
about
kubernetes
as
an
emerging
trend.
Kubernetes
is
just
a
common
requirement.
Now
right,
it's
not
an
emerging
trend.
It
is
part
of
every
single
organization's
landscape.
I
think
it
was
cncf.
Did
a
survey
recently
and
it
was
in
the
in
the
high
70s
of
respondents,
said
that
kubernetes
was
part
of
their
production
environment
or
would
be
within
the
next
12
months.
A
Your
connectivity
needs
to
be
fast.
It
needs
to
scale
it
needs
to
be
secure.
If
we
think
about
what
the
outcome
of
digital
transformation
is
meant
to
be,
it's
providing
innovative
digital
experiences
right.
It's
providing
personalized
customer
and
employee
journeys
throughout
their
life
cycles
with
you,
the
only
way
that
you
can
do
this
is
by
making
data
available
in
the
right
place
from
all
of
these
different
systems,
making
it
available
in
the
right
way
to
the
right
audiences.
A
Innovation
depends
on
something
being
extensible.
Innovation
is
creating
something
new
that
doesn't
already
exist.
How
can
you
do
that?
If
you
can't
build
your
own
add-ons,
if
you
can't
get
stuck
into
the
code
and
extend
it
to
cover
niche
use
cases,
you
might
have?
Maybe
that's
like
specific
legacy
requirements?
Maybe
it's
like
ultra
cool,
innovative
things
that
are
sandbox
projects
and
then
supporting
all
of
this
obviously
has
to
be
a
layer
of
automation,
because
there
is
no
chance
of
doing
this
manually
and
being
efficient.
A
A
It
needs
to
be
in
the
ecosystem
and
by
this,
if
you're
familiar
with
in
in
mathematics,
if
you're
familiar
with
how
you
can
think
of
graphs,
multi-dimensional
graphs
with
edges
and
nodes,
or
if
you
come
from
a
networking
background
and
we
think
about
networking
with
lots
of
different
nodes
and
edges
really.
What
we're
thinking
of
with
a
fabric
is
connectivity
that
exists
in
multiple
dimensions,
in
multiple
directions,
with
multiple
protocols
and
use
cases,
and
essentially
this
like
multi-dimensional
living
breathing
fabric
that
plugs
in
and
easily
kind
of
rips
out.
A
So
the
first
is
that
all
of
the
services-
the
connectivity
services,
the
apis,
the
microservices,
the
graphql
services,
etcetera,
etcetera,
etcetera.
They
all
need
to
be
well
designed.
They
all
need
to
be
secured
and
managed.
They
all
need
to
be
discoverable
right.
Otherwise
they
might
as
well
not
exist,
so
essentially,
all
of
the
ways
that
we
support
the
full
api
life
cycle
for
restful
apis.
A
You
still
need
to
support
the
relevant
parts
of
that
and
apply
that
to
all
the
other
types
of
services
you
have.
You
need
to
be
able
to
make
sure
that
not
just
restful
apis,
but
any
type
of
service
you
have
can
be
plugged
in
to
your
fabric.
So
this
is
apis
microservices
with
a
service
mesh
and
all
the
other
protocols.
A
A
Each
one
of
our
services
is
a
bit
like
each
one
of
the
avengers
right.
They
come
from
a
different
world.
They
fulfill
a
different
use
case.
They've
got
a
different
superpower,
but
they
know
shield
knows
how
to
contact
each
one
of
these
services
and
say
right.
This
is
the
problem
that
we've
got.
These
are
the
baddies
that
we're
currently
trying
to
fight,
and
you
iron
man
and
captain
america
are
the
individuals
with
your
superpowers
that
we
need
to
gather
together
and
achieve
this
outcome.
A
The
way
I
think
about
it
is
deploy
what
matters
where
it
matters,
and
this
is
whether
or
not
you're
running
as
a
sas,
which
is
one
of
the
key
new
features
in
connect
or
if
you're,
self-hosting
or,
if
you're
doing
both
the
way.
I
think
about
this
one
is
this
needs
to
exist
across
the
entire
enterprise
right.
We
are
building
this
fabric
that
can
stretch
in
real
time
in
any
direction.
A
And
finally,
like
we
said
this
is
impossible
to
do
without
automation,
managing
connectivity,
managing
complexity
in
any
tool
in
any
environment
has
to
be
supported
by
end-to-end
automation,
and
by
this
I
mean
declarative
configuration
the
ability
to
say,
hey
run
time.
This
is
what
you
need
to
look
like
after
a
deployment
you
take
care
of
figuring
out
how
that's
achieved.
A
A
B
I
can't
even
see
my
screen
here
all
right,
excellent,
great,
okay,
and
so
here
this
is
the
the
connect
interface
and
so
here
it
lives
at
connect.comhq.com,
and
before
I
go
in
here
real
quick.
I
did
just
want
to
highlight
the
architecture
that
we've
set
up
here
and
the
with
the
idea
being
much
like
melissa
was
just
talking
about.
B
B
You
get
access
to
the
user
interface,
you
have
access
to
the
dev
portal,
a
very
easy
means
of
of
interacting
with
the
service,
applying
your
configuration.
Having
a
single
place,
where
every
member
of
your
team
can
go
to
quickly
both
see
what
else
is
out
there
create
new
runtimes
manage
the
runtimes
manage
the
dev
portal,
but
it
also
allows
you
to
very
quickly
and
easily
sprinkle
these
proxies
throughout
your
environment,
and
one
of
the
main
benefits
of
kong
in
this
case
is
that
we
do
have
pretty
much.
B
The
beauty
of
service
hub
is
that
I
can
link
these
two
developer
portal
instances.
So,
as
consumers
of
my
my
apis
come
in,
they
want
to
know
what
services
exist
where
they
live,
how
to
access
them.
I
can
link
them
here.
This
can
also
be
the
case
for
services
that
are
not
even
managed
by
cong.
I
can
create
service
entity
stubs
or
services
that
I
may
want
to
just
expose
his
documentation,
but
I
don't
actually
own
or
manage
here
directly
within
the
kong
interface
and
before
I
go
too
deeply
into
any
of
these
services.
B
I
do
want
to
highlight
as
well
the
runtime
manager
and
so
getting
back
here
to
this
this
diagram.
What
we're
seeing
here
in
the
the
connect.comhq.com
interface
is
the
control
plane
when
we
say
runtime
we're
really
referring
to
these
api
proxy
gateways,
and
this
is
the
core
foundational,
prong
gateway,
that
everyone
knows
and
love
loves,
as
well
with
the
the
enterprise
variant,
as
well
as
the
open
source
variant,
and
these
again
can
be
sprinkled
in
any
location
across
anywhere
and
within
your
infrastructure
across
any
cloud.
B
Any
linux
operating
system
dedicated
instances
vms.
What
have
you
and
then
again
managed
here
centrally,
and
if
I
look
at
the
runtime
manager,
you
can
see
all
the
different
proxies
that
I
have
deployed
out
within
my
environment,
their
ips
when
they
were
last
seen
also
the
runtime
version
in
this
case
I'm
running
kong
2.3.2
all
my
environments
as
well
as
their
status.
B
Now
I
can
even
quickly
create
new
runtimes
with
a
few
different
means
and
again
you
know
we
support
pretty
much
any
kind
of
deployment
model.
Here
we
have
a
quick
start
for
docker,
because
that
seems
to
be
easy
to
get
started
with.
We
also
have
a
helm
chart
for
kubernetes
and
as
well
as
an
installation
patch
for
linux,
regardless
whether
that's
debian
or
centos,
red
hat
amazon
linux.
B
B
All
right,
and
so
I
started
a
new
container
you're
running
locally
on
my
my
laptop
I've
got
port
8000
exposed,
and
now,
if
I
hit
localhost
8000,
I
get
this
no
route
matched
which
is
actually
what
I'm
expecting,
and
so
it's
that
that
easy.
As
far
as
how
I
can
actually
sprinkle
these
runtimes,
the
beauty
of
kong
as
well
is
that
I
can
use
this
as
part
of
my
development
process
as
part
of
my
testing
process.
B
So
it's
not
some.
You
know
monolithic
huge
long
run
time
sitting
out
there
that
devs
need
to
go
through
special
permissions
to
to
get
access
to.
They
can
very
quickly
easily
spin
up
instances
locally
on
their
laptop
work
locally
and
then
use
the
exact
same
configuration
when
moving
to
pre-production
acceptance,
and
then
production
facing
environments.
B
And
now
that
I
have
my
instance
set
up
here,
you
can
see
so
here's
the
the
new
container-
and
so
it's
I
mean
frankly
just
that
easy
as
far
as
getting
the
the
proxy
stood
up
and
so
now
I
have
an
entry
into
my
service
ecosystem
from
here.
The
the
request
will
be
initiated
from
the
proxy
that
lives
on
my
laptop,
and
so
I
have
access
to
all
my
local
services
running
here
on
my
laptop
anything
within
my
environment,
and
so
again
you
can
sprinkle
these
proxies
at
every
edge
of
your
environment.
B
So
as
an
example,
here
I'm
going
to
click
on
my
accounts
service
and
within
connect,
we've
changed
a
little
bit
of
the
paradigm
for
how
we
made
it.
We
think
of
services
where
we're
now
focused
more
around
the
service
package
itself
and
accounts
service.
Here
is
the
service
package,
and
then
I
have
versions
of
this
service.
Some
devs
some
tests,
some
production
facing
that
are
then
the
actual
underlying
implementation.
B
So
these
are
you
know
the
upstream
urls
that
the
proxies
are
going
to
be
relaying
traffic
to
and
from
here
you
can
also
see
high-level
information
about
this
service,
so
the
vitals
data
coming
through.
So
I
can
see
you
know
over
the
past
hour
here
and
as
an
example,
the
service
makeup
of
the
requests
going
through
the
gateways-
and
this
is
in
aggregate,
so
not
just
an
individual
gateway.
I
can
see,
of
course,
you
know
v08.2,
which
is
my
latest
version
being
the
most
popular,
which
is
probably
a
good
thing.
B
B
I
can
also
link
what
we
refer
to
as
a
service
document
which
will
be
used
for
the
developer
portal
piece
which
I'll
get
to
in
here
in
just
a
second,
but
it
really,
you
know,
provides
more
context
more
documentation.
The
service
document
is,
is
more
of
free
form
documentation.
So
you
know
a
markdown
file
that
I
can
sprinkle
that
put
into
the
the
dev
portal
that
will
allow
consumers
to
see
high
level
information
about
how
they
can
use
it.
It
can
include
how
to
connect
how
to
authenticate
tutorials
guides.
B
So
if
I
click
into
a
service
package
here
or
sorry,
a
service
version,
my
v08.2
version,
for
example,
I
get
a
little
bit
more
detailed
traffic
stats
coming
from
that
vitals
data.
This
data
is
being
pushed
from
the
gateways
to
the
config
plane
here.
The
control
plane
here
that
lives
within
the
sas
environment,
and
so
no
matter
where
these
are
I'm
getting
the
data
pulled
from
back
from
them.
B
B
And
then
within
the
service
version,
so
when
we
actually
get
to
the
little
more
nitty
gritty
details
here,
this
is
more
of
the
bread
and
butter
of
what
kong
as
a
gateway
does.
So
I've
got
the
routes
for
this
service.
So
this
is,
you
know
how
to
map
incoming
requests
going
to
the
gateway
to
the
upstream
service.
B
B
B
B
B
That
I
can
then
aggregate-
and
you
know
alert
on-
have
this
feed
into
kind
of
a
larger,
alerting
picture
that
I
have
for
any
operators
within
my
infrastructure
so
that
they
can
know.
You
know
what
services
are
being
used,
what
the
status
codes
are
being
emitted
from
that
service
and
just
more
on
the
operational
front
as
far
as
kind
of
maintaining
services
over
time.
B
And
so
as
an
example
here
I
can
see
all
the
different
plugins
that
I
have
available
by
putting
this
here
at
the
gateway.
I
also
free
the
back
end
teams
from
having
to
worry
about
this
kind
of
functionality,
so
things
like
caching
rate,
limiting
authentication,
even
as
well
as
more
of
these
kind
of
more
pieces
of
functionality
that
are
more
suited
for
a
gateway,
as
opposed
to
actually
being
built
into
every
single
service,
especially
as
the
number
of
services
in
your
environment
grows.
B
The
more
opportunity
there
is
for
different
implementations
of
different
pieces
of
policy
here
to
slip
in
some
that
may
not
have
been
updated
in
quite
a
while
some
using
different
languages,
different
frameworks,
different
versions
of
the
same
framework
and
so
by
centralizing
all
this
policy
here
at
the
gateway.
I
can
ensure
that
caching,
for
example,
is
done
within
a
consistent
way
across
all
the
services
in
my
environment,
and
then
I
have
high
level
view
and
access
to
understanding
what
services
are
implementing
this.
B
B
B
And
this
is
what
the
consumers
or
developers
integrating
against
or
building
upon
my
services
will
see
and
just
like,
we
saw
within
the
service
hub
view.
Here
we
have
all
the
different
services
that
are
available.
It's
not
a
requirement.
They
get
published
the
dev
portal.
So
it's
not
always
the
case
that
I
may
want
to
have
services
that
are
not
present
in
the
dev
portal,
but
this
is
an
easy
way
to
just
surface
both
the
discoverability
for
these
services,
so
that
devs
know
what
services
are
out
there.
What
endpoints
are
out
there?
B
In
this
case,
it's
all
self-service
here
managed
in
a
self-service
manner,
so
the
developers
can
access
themselves.
They
can
serve
their
own
credentials,
see
utilization
what
credentials
they
have
out
there
as
well
as
consume
the
documentation.
Both
freeform
is
one
more
structured.
That's
linked
to
those
service
definitions
here
in
service
hub.
B
B
If
I
look
here
within
the
ui
for
my
account
here,
I
have
my
apps
and
in
this
case
you
know
I
can
create
a
let's
just
use,
one
of
those
I
already
have
where
I
can
create
an
application
that
defines
you
know
this
is
the
application
that
I'm
building
upon
that
will
be
integrating
with
the
services
that
are
available
that
are
exposed
through
service
hub
and
then
from
here.
I
can
manage
my
credentials
so
in
the
case
of
the
octo
team,
app
application,
it
has
access
to
the
accounts
service.
B
I
can
quickly
generate
a
new
credential,
go
to
my
instance
here,
specify
my
api
key
and
the
request,
and
now
I
can
have
access
to
the
service.
In
this
case
it's
just
a
an
echo
service.
So
it's
not
going
to
return
with
anything
very,
very
useful
in
this
case,
but
just
to
demonstrate
how
all
this
works
from
the
consumer's
perspective.
B
If
I
look
I
can
in
the
headers
I
can
see
both
this
is
coming
from
kong,
but
as
well.
I
can
see
this
is
also
being
rate
limited,
and
so
you
know
again
kind
of
the
more
bread
and
butter
type
of
functionality
that
we
typically
see
in
kind
of
gateway,
use
cases
things
like
rate
limiting
caching
authentication
can
all
be
handled
here.
The
backend
service
has
no
understanding
of
you
know
what
what
is
going
on
in
front
of
it.
B
It
doesn't
need
to,
and
so
that
back-end
teams
are
freed
from
this
technical
debt
that
they
eventually
have
to
repay
over
time,
and
they
can
focus
on
building
their
service
and
integrating
with
the
other
pieces
and
and
again
consuming
that
connectivity,
whether
that's
north-south
and
the
kind
of
the
gateway
use
case
coming
from
outside
the
environment,
into
the
environment
or
more
east-west
traffic.
You
know
going
more
of
a
service
mesh
communication.
B
Within
the
dev
portal
settings
here
I
can
also
customize
the
appearance
of
the
developer
portal,
so
I
can
very
quickly
change
how
it
looks
brand
it
a
little
bit
if
I
refresh
here,
you'll
notice,
that
the
changes
are
immediate
and
so
again
providing
a
self-service
avenue
for
developers
and
consumers
of
my
api
to
come
in,
and
you
know
see
what
the
documentation
is
out.
There
manage
their
credentials
and
just
overall
manage
their
access.
B
Here
again,
where
I
can
from
the
interface
manage
these
requests,
approve,
deny
manage
the
dev
portal,
manage
the
services,
manage
the
runtimes
and
all
this
with
role-based
access
controls
as
well.
So
you
can
see
other
members
of
the
organization
and
they're
given
privileges
within
the
org,
so
I
can
control
and
scope
access
to
given
services,
or
you
know,
depending
on
on
their
role
within
the
within
the
team.
C
C
A
A
So
service
mesh
is
typically
used
as
a
slightly
overlapping
technology,
but
that
solves
a
different
problem
from
api
gateway.
Api
gateway
acts
at
layer
7
in
the
osi
model.
If
that's
something
that
people
are
aware
of,
it
basically
means
that
this
is
the
the
presentation
layer
of
our
data.
This
tends
to
be
more
human
discovery
of
an
endpoint
in
a
portal
to
then
get
some
kind
of
access
key
and
build
an
application
against
you
consume
it.
Maybe
that's
a
different
type
of
service,
maybe
that's
a
mobile,
app
or
a
website.
A
A
A
microservice
based
application
tends
to
have
a
whole
group
of
services
that
act
together
as
one
unit
that
unit
is
exposed
through
an
api
and
therefore
has
an
api
gateway
to
manage
the
connectivity
into
that
unit.
But
within
that
unit,
all
these
different
services
need
to
communicate
with
each
other.
That
communication
needs
to
be
secured.
It
needs
to
be
made
reliable.
A
A
So
if
we
take
a
step
back
and
think
about
the
overall
fabric
that
we're
building
to
support
connectivity
across
an
ecosystem,
it
has
to
support
not
just
api
gateway
but
service
mesh
as
well,
and
this
is
how
it
goes
from
being
a
one-dimensional
thing
to
a
multi-dimensional
thing.
So
kind
of
you
can
step
back.
Have
that
complete,
bird's
eye
view
and
say
I
need
to
make
a
call
to
this
api,
I'm
going
to
go
through
the
gateway
you
get
into
that
gateway,
that's
that
north-south
traffic
boundary
and
then
hey.
A
Actually,
what
we're
doing
this
api
response
is
going
to
be
fulfilled
by
calling
these
10
microservices.
So
then,
as
your
request,
you
get
kind
of
rooted
between
all
of
these
services.
That's
the
service
mesh
coming
into
play,
the
responses
assembles
and
then
the
api
gateway
handle
sending
that
back
to
the
end
client.
A
A
You
don't
want
to
lose
the
context
if
you're
kind,
of
starting
off
making
a
call
to
an
api
going
back
in
and
doing
all
these
things
with
the
microservices.
You
want
to
keep
that
context
and
understand.
How
is
that
one
request
being
routed
across
all
of
these
different
services
that
are
actually
playing
a
role
so
bringing
kong
mesh
into
connect
is
one
of
the
top
level
items
in
our
road
map.
B
No,
I
think
that
that
was
a
that
was
great.
No
and
again,
the
idea
is
that
you
know
just
like
we
manage
the
gateway,
those
those
gateway
runtimes
within
the
connect
interface
it'd,
be
almost
identical
in
the
sense
that
you'll
be
managing
those
mesh
data
planes.
You
know
we
call
them
data
planes,
but
you
know
it's
kind
of
the
same
same
naming
here
and
then
you
manage
you
have
a
single
interface.
We
can
manage
those
and
so
as
you're
managing
those
services
from
that
north-south
traffic.