►
From YouTube: Building an API vision to transform your business: Kong CTO, Co-Founder Marco Palladino, Kong Summit
Description
Kong began as concept in 2009. Today, Kong has nearly 10 Trillion API calls per month. APIs allow us to break down the silos, opening the doors across what every team is doing.
Join Kong CTO and Co-founder Marco Palladino in his Kong Summit 2022 Keynote, as he covers the new frontier of API management technology. Hear customer stories and see a product demo to learn how an API vision can transform a business.
https://www.linkedin.com/in/marcopalladino/
https://twitter.com/subnetmarco
A
Kong
began
as
a
concept
in
2009
when
a
couple
of
friends
were
in
a
garage
and
started
building,
but
today
over
10
trillion,
API
calls
per
month
the
most
popular
API
Gateway
on
GitHub,
with
more
than
67
000
Stars,
300
million
Kong,
Gateway
downloads
and
Counting.
We
couldn't
have
achieved
this
without
you.
You
contributed
thousands
of
lines
of
code
each
year,
you've
championed
Kong
across
the
world
and
you've
connected
with
each
other
across
more
than
80
meetup
groups
on
every
major
continent.
B
Last
month
my
wife
and
I
had
to
buy
a
new
car,
the
old
one
broke
down,
and
we
have
a
family
two
beautiful
kids,
two
boys
and
if
you
ever
purchase
the
car,
you
know
how
hard
it
can
be.
There
are
so
many
options
out
there.
Some
cars
are
faster,
some
are
bigger,
some
are
smaller
and
hey
I'm
Italian
I,
like
fast
cars,
my
wife
she's
from
Kentucky,
she's,
more
practical,
and
so
in
order
to
be
able
to
navigate
and
make
the
you
know
all
these
options
and
make
the
right
choice.
B
We
decided
to
sit
down,
we
decided
about
what
we
were
going
to
do
with
a
car
who
would
use
the
car
where
we
were
going
with
a
car,
and
you
know
we
needed
a
family
car
a
daily
driver,
something
that
we
could
use
to
buy.
Groceries
brings
the
kids
to
school.
You
know
the
regular
stuff,
and
so
we
decided
to
buy
an
SUV.
B
B
This
is
a
tough
process
that
each
one
of
us
makes
whenever
we
have
to
make
an
important
decision.
We
always
think
about
what
we're
going
to
be
doing
with
the
car
with
a
house.
You
know
what
is
the
vision
that
we
have
and
then
we
work
backwards
from
there
to
make
sure
we
make
the
right
choice,
but
the
Dilemma
is
that
more
often
than
not,
people
make
short-term
decisions
when
it
comes
to
apis,
whereas
we
should
think
of
an
API
strategy
and
then
work
backwards
from
there
to
implement
it.
B
Apis
are
running
our
business.
Everything
that
we
create
every
product,
anything
that
anybody
is
building
in
the
organization
is
powered
by
apis.
Apis
are
some
of
the
most
important
Assets
in
our
applications,
and
so,
if
we
do
have
a
vision
for
our
business
and
how
our
business
will
evolve
in
the
next
three
four
five
years,
we
must
have
a
vision
for
apis
to
be
able
to
support
our
business
execution
in
the
next
three
for
five
years.
B
B
It's
not
a
surprise
that
breaking
down
the
silos
is
a
cross-steam
effort,
it's
something
that
affects
the
whole
organization,
every
line
of
business
and,
as
a
matter
of
fact,
it's
not
a
surprise
that
one
of
the
biggest
API
Visions
we've
seen
in
our
industry
Amazon,
a
great
API
first
organization,
was
actually
driven
by
the
CEO
himself
Jeff
Bezos,
with
the
famous
Jeff
Bezos
mandate.
B
What
Jeff
Bezos
said
was
the
following.
His
vision
was
about
making
sure
that
every
team
built
an
API
first
and
foremost,
and
that
every
API
would
be
able
to
be
exposed
immediately
potentially
to
a
third
party
and
thanks
to
this
API
vision,
Amazon
grew.
Sixteen
thousand
percent
and
AWS
was
made
possible
AWS,
which,
by
the
way,
many
of
you
in
this
room
are
relying
upon
to
build
your
business
and
run
your
business.
B
B
B
And
so
what
is
your
API
Vision?
How
are
we
going
to
be
supporting
the
business,
how
we're
going
to
be
supporting
The
Innovation?
It's
not
a
surprise
that
organizations
with
a
strong,
API
Vision
are
the
ones
that
can
ship
faster.
They
can
execute
with
more
agility.
Those
are
the
ones
that
can
turn
products
into
platforms
into
ecosystems.
They
can
fast
their
innovation
in
creativity.
B
B
We
want
to
support
new
use
cases
mobile
and
we
go
ahead
and
build
an
API
to
make
that
happen,
but
this
was
still
done
in
a
very
opportunistic
way,
whereas
API,
it
is
true
that
they
started
from
the
applications
themselves,
but
they
ended
up
being
a
very
important
part
of
the
entire
organization,
every
major
transformation
to
the
cloud
digital
Transformations,
creating
ecosystems,
onboarding
customers.
All
of
these
Transformations
are
driven
by
apis
apis.
They
move
the
organization
forward.
They
help
us
achieve
our
business
outcomes
in
a
much
better
way
without
a
coherent,
API
vision.
B
We're
not
going
to
be
strategic
like
this
we're
going
to
be
tactical
opportunistic,
but
that's
not
what
the
business
needs.
The
business
needs.
A
strategy
that
we
can
execute
upon
technology
is
very
important.
Whatever
we
put
in
place
whatever
platform
we
use
to
build
and
execute
on,
our
vision
needs
to
be
able
to
support
all
the
teams
throughout
their
Journey.
B
That's
why
we
wanted
to
provide
a
platform
to
the
teams,
a
platform
that
allows
them
to
self-serve
their
policies,
so
they
can
do
all
the
experimentation
that
they
need
to
do
without
sacrificing
the
business
outcomes
that
we
want
to
drive,
and
this
is
why
most
of
these
people
here
in
this
room,
most
of
you-
are
actually
partnering
with
Kong
to
build
this
API
platform,
one
that
can
help
us
drive
both
the
teams
and
the
business
outcomes
together.
B
Some
of
you
may
think
that
the
time
is
not
right
to
build
an
API
platform
for
the
organization,
but
I
challenge
you
to
think
about
understanding
that
the
time
is
always
right.
Apis
are
not
going
anywhere.
Apis
are
only
going
to
be
increasing,
moving
forward,
the
more
applications
and
the
more
things
in
customer
experiences
that
we
build
and
the
more
apis
we're
going
to
be
having,
and
so
we
need
a
strategy
today
to
be
able
to
support
that
growth
in
a
organized
way.
B
So
let's
go
build
an
API
platform
Envision
today
here
in
this
room
and
let's
start
with
what
the
teams
are
doing.
Our
teams
are
transitioning
from
monolithic
to
microservices
with
a
monolithic
application.
We
have
external
traffic
mobile
applications,
ecosystem
of
developers
that
we
want
to
enable
to
consume
our
apis,
but
as
we
transition
to
microservices
and
by
the
way,
this
is
a
transition
that
I've
done
myself
as
an
API
developer.
B
As
we
transition
from
analytics
to
microservices,
we
focus
on
the
workloads,
but
there
is
lots
of
API
connectivity
in
between
all
the
services
that
we
also
need
to
deal
with,
and
the
application
teams
are
unprepared
to
deal
with
that
because
that's
not
part
of
their
job.
It
is
the
underlying
infrastructure
that
should
make
that
connectivity,
reliable
and
secure,
and
so
we
can
adopt
an
API
Gateway
to
expose
some
of
these
Services
externally
outside
of
the
organization
or
internally
to
other
teams,
and
yet
we
still
want
to
have
something
in
place.
B
That
makes
all
of
that
API
connectivity
among
our
services,
reliable,
secure
and
observable,
and
for
that
we
can
adopt
a
service.
Mesh
service
mesh
turns
our
API
connectivity
into
electricity
when
we're
home
and
we
want
to
plug
in
an
appliance.
It
just
works.
It's
there
ready
to
go,
and
this
is
exactly
how
we're
turning
our
API
connectivity
for
our
team,
so
we're
turning
that
unreliable
connectivity
into
electricity
always
up
and
running,
always
ready
to
go.
Now.
We
can
support
our
teams
faster.
B
But
then,
finally,
we
could
have
the
best
API
infrastructure
in
the
world,
and
yet,
if
there
is
no
consumption,
all
of
this
is
useless.
The
value
of
any
API
platform.
It
is
being
driven
by
the
consumption
in
the
usage
that
our
apis
have,
and
so
we
need
to
make
sure
that
our
teams
are
productive.
They
can
design
apis
the
right
way.
They
can
discover
and
consume
apis
the
right
way
they
can
be
successful
in
their
transformation.
B
B
B
All
right,
fantastic
Ralph,
thanks
so
much
for
being
here.
Okay,
so
let's
get
going,
let's
understand
what
type
of
Transformations
is
TransUnion
doing
today,.
C
Transunion
is
on
a
multi-year
cloud
Journey
as
part
of
this
effort.
We
are
modernizing
the
way
we
do
technology
at
TransUnion.
That's.
C
So
Kong
is
a
strategic
partner
in
that
cloud.
Computation
we
use
Kong,
API,
Gateway
and
service
mesh
Solutions
I
lead
the
service
mesh
effort,
so
I'll
talk
specifically
about
service
mesh
as
part
of
our
Cloud
transformation
Journey.
We
are
not
just
lifting
tifting
apps
to
the
cloud.
We
are
making
our
monolithic
applications.
We
are
breaking
the
monolith
and
making
them
more
Cloud
native
and
microservices
oriented
as
the
sheer
number
of
these
microservices
grow.
C
So
does
the
complexity
of
our
system,
and
we
believe
that
Kong
mesh
can
help
alleviate
some
of
those
cross-cutting
concerns
and
complexity,
especially
when
we
execute
or
run
those
microservices
in
a
distributed
environment
such
as
kubernetes.
C
So
we
use
we
plan
to
use
and
we
use
service
mesh
for
some
of
the
technology
features,
namely
mtls
for
zero
trust.
We
are
using.
C
We
are
achieving
the
canary
deployment
with
you
know:
Flagger
integration
from
service
mesh,
The,
Observer
observability,
feature
of
you
know
like
the
the
Matrix
that
the
data
plane
emits
out
of
the
box
helps
us
make
the
you
know,
make
sense
of
our
system.
It
helps
us
to
observe
our
system,
for
you
know
performance
as
well
as
the
overall
health
of
the
system.
So
that's
the
technology
piece
of
it
now
as
part
of
our
Cloud
transformation.
Journey.
C
Now
Kong
mesh
is
one
of
those
tools,
because
it
helps
the
product
Engineers
to
focus
on
building
meaningful
apps
and
reduces
the
burden
on
the
shoulder
of
our
product
Engineers,
so
that
the
Kong
mesh
software
can,
you
know,
take
all
of
the
complexity
in
in
its
own
hand,
and
makes
our
application
lightweight.
So
by
adopting
a
solution
like
service
mesh
and
Kong
mesh,
it
helps
us
to
move
faster.
C
It
makes
our
Engineers
more
agile
and
more
focus
on
building
application.
It
makes
some
applications
lightweight
and
it
de-risks
our
transformation.
It
makes
our
transformation
smoother.
So
these
are
all
the
business
outcomes
and
less
burden
on
engineer.
Shoulder
translates
to
money,
saved,
I
would
say.
B
B
I
told
you
before
I
was
an
API
developer
myself
and
so
throughout
the
journey
to
microservices.
There
are
many
things
that
developers
have
to
think
about
that
are
really
slowing
them
down
if
it's
not
being
given
by
the
underlying
infrastructure
as
we
transition
to
microservices.
Some
of
these
requirements
is
about
making
sure
the
network
is
secure,
making
sure
that
we
can
observe
and
Trace
and
change
all
of
our
infrastructure
in
a
meaningful
way,
so
that
when
there
is
a
problem,
we
can
track
it
so
that
when
there
is
a
bug
we
can
identify
it.
B
We
need
to
make
sure
that
all
of
these
cross-cutting
concerns
are
there
for
us
to
make
sure
that
these
services
are
going
to
be
successful,
and
it's
very
frightening
and
it's
very
chaotic-
and
this
is
all
extra
work-
that
as
an
API
developer,
I
don't
want
to
do
it's
not
my
job,
and
so
what?
If
we
could
take
all
of
these
cross-cutting
concerns,
and
we
could
make
it
soothing,
we
could
bring
them
inside
the
underlying
infrastructure.
We
could
leave
them
away
from
the
our
teams
and
bring
them
inside
the
service
mesh.
B
By
providing
a
service
mesh,
we
heard
it
from
gurav.
We
can
build
faster.
Our
teams
don't
have
to
worry
about
these
things.
They
can
be
more
agile
because
they
are
self-service.
We
can
support
in
more
reliable
connections.
If
our
connections
are
down,
the
applications
are
down.
So
how
do
we
make
sure
that
the
app
time
is
always
going
that
these
experiences
are
reliable?
And
this
is
exactly
what
the
service
mesh
helps
us
doing?
I
find
it
very
hard
to
be
able
to
transition
to
microservices
and
yet
not
taking
care
of
these
underlying
API
connectivity.
B
Now
when
it
comes
to
service
mesh,
one
of
the
biggest
questions
I
hear
from
customers.
As
a
matter
of
fact,
these
actually
happened.
Yesterday
we
were
having
a
customer
Advisory
board
with
some
of
you,
and
one
of
the
questions
was:
how
do
we
differentiate
a
service
mesh
versus
API
management?
What's
the
difference?
B
So,
let's
take
a
look
at
that:
every
service
that
our
teams
create
are
Services.
Anything
that
can
make
or
receive
a
request
over
the
network
is
a
service,
so
the
services
we
build
are
services
and
the
services
we
adopt
like
databases
like
Kafka,
those
are
also
Services.
Therefore,
an
API
management
solution
is
also
a
service
because
it
receives
a
request.
Does
some
operation
and
proxy
does
requires
elsewhere?
B
Service,
mesh
and
APA
management
are
fundamentally
operating
on
different
levels
of
our
infrastructure.
Service.
Mesh
makes
sure
that
our
connections
are
reliable,
like
electricity
they're,
always
working
they're,
always
secure
they're,
always
observable,
but
then
on
top
of
that,
our
services,
like
an
API
management
solution,
can
bring
added
capabilities
for
choosing
which
one
of
these
Services
we
want
to
expose
and
then
being
able
to
provide
a
curated
experience
for
an
internal
team
or
an
external
customer
to
be
able
to
get
access
to
this
API
and
start
making
requests.
So
we
can
manage
tiers
of
consumers.
B
We
can
manage
how
we
want
them
to
secure
the
API
or
login
into
the
API.
We
can
build
all
sorts
of
capabilities
that
are
higher
in
the
stack
than
the
service
mesh.
The
service
mesh
makes
sure
that,
at
the
end
of
the
day,
everything
that's
running
underneath
is
going
to
be
working
and
so
with
Kong
mesh.
B
B
B
It
allows
us
to
improve
control
with
the
new
generation
of
policy
selectors
that
are
easier
to
use
that
everybody
in
the
team
in
the
organization
can
adopt
and
also
allows
us
to
set
up
top
governance
capabilities
that
we
want
to
mandate
like,
for
example,
every
application
should
be
zero
trust
and
still
give
the
ability
to
the
teams
to
be
able
to
change
their
own
things,
the
ones
that
we
want
them
to
have
the
freedom
to
change
like
circuit,
breakers
or
routing,
for
example,
and
then,
finally,
we
are
shipping
a
new
capability
for
our
back
auditing
logs,
and
this
is
quite
important
for
always
knowing
what's
happening
in
our
infrastructure,
as
we
support
teams
across
every
line
of
business.
B
B
All
right
as
John
sets
himself
up
in
the
demonstration
up.
You
know
we're
going
to
be
seeing
something.
That's
quite
unique
and
quite
complex.
John
is
going
to
be
demonstrating
a
service
mesh
that
truly
can
support
every
team
in
the
organization.
This
is
a
multi-cloud,
hybrid,
VMS
and
containers
demonstration.
We're
going
to
be
seeing
how
our
teams
can
be
productive
with
something
like
this
without
having
to
build
it
from
scratch.
So
all
of
these
underlying
API
connectivity
is
ready
to
use.
They
become
the
users
of
this
functionality,
not
the
Builders
of
this
functionality.
D
C
C
D
So,
thank
you,
Marco
I'm,
going
to
spend
the
next
five
or
so
minutes
just
talking
through
some
of
the
great
capabilities
of
Kong
mesh
and
how
those
features
can
enable
business
outcomes
for
your
organizations
at
lower
cost.
So
before
I
used
to
be
a
PM
before
I
visit
pm
on
on
Kong
mesh
I
used
to
be
in
the
field,
helping
customers
and
one
of
the
things
I
always
used
to
hear,
was
when
I'm
building
a
robust
platform.
D
One
of
the
most
important
things
I
need,
like
Marco
said,
is
a
mesh
which
can
span
running
any
application
across
any
Cloud
across
any
environment,
and
that's
why
one
of
the
key
decisions
we
made
when
designing
Kong
mesh
was
to
make
it
completely
platform
agnostic.
We
can
support
your
workloads
on
Virtual
machines,
on-prem
or
in
the
cloud
we
can
support,
containerized
workloads
on
things
like
eks
and
gke,
and
also
newer
Innovative
Technologies
like
AWS,
ECS
and
fargate,
for
example.
D
B
D
Yep,
it's
running
across
all
three
clouds,
so
I
have
my
control
plane
in
AWS.
I
have
zones
in
AWS
zones
in
Google
zones
all
over
the
place.
So
when
you
go
to
my
zone
control
planes
here-
and
we
can
actually
see
that
right,
we
can
see
I
have
an
eks
Zone,
a
gke
Zone,
a
couple
of
other
offline
kubernetes
zones
and
then
that
Universal,
Zone
and
virtual
machines.
D
So
by
supporting
all
of
these
Platforms
in
a
seamless
way,
like
Marco
said
we
can
take
away
all
of
those
cross-cutting
concerns
and
let
your
development
teams
do
what
they
love
to
do,
which
is
develop
right.
This
in
turn
accelerates
the
agility
within
your
organization
and
they
can
just
focus
on
doing
Innovation
and
enabling
business
outcomes,
and
they
don't
need
to
worry
about
those
kind
of
operational
pieces
right
developers,
never
care
about
doing
stuff
with
infrastructure
and
in
fact
those
great
demos
by
Augie
and
Gabriella
reminded
me.
This
morning
we
use
Kong
Mash
in
Connect.
D
We
use
kongmash
to
enable
mtls
end-to-end
security
for
all
of
our
internal
services.
In
Connect,
we
issue
certificates
automatically
rotate
them
on
a
configurable
interval
and
that
massively
reduces
exposure
in
the
case
of
leaks
and
things
like
that.
It
means
that
we
have
that
end-to-end
security,
our
developers,
don't
have
to
worry
about
that.
They
can
just
focus
on
delivering
all
those
great
connect
services
that
we
saw
earlier,
and
we
can
actually
see
that
in
the
UI.
D
If
we
head
over
here
to
our
TLS
report,
looking
at
my
mesh,
a
we
can
see,
I
have
an
enabled
back
end,
which
is
a
built-in
certificate
Authority,
which
comes
with
Kong
bash.
Now
we
know
that
organizations
also
have
their
own
certificate
authorities
or
want
to
integrate
with
other
third
parties
and
have
different
regulatory
requirements.
So
we
also
natively
integrate
with
a
number
of
other
third-party
providers,
hashicor
Vault,
AWS
certificate
manager
and
more.
We.
D
So
security
is
great
and
obviously
usually
top
of
mind
right.
One
of
Aggie's
three
pillars,
but
another
huge
benefit
to
deploying
Kong
mesh
is
the
unparalleled
observability
you
get
by.
Like
I
said
sitting
next
to
each
application.
Taking
away
those
cross-cutting
concerns,
we
can
give
logging
monitoring
tracing.
We
can
capture
everything
coming
out
of
every
application.
This
allows
you
to
anticipate
issues
in
your
environment
and
mitigate
them
early
right,
making
sure
that
you're
always
giving
your
customers
the
best
experience
when
they're
running
their
apps
in
your
environments.
D
B
All
of
these
work
and
all
of
this
cross-cutting
concerns
would
be
quite
complicated
to
build.
This
is
the
right
infrastructure
that
supports
our
teams
in
the
type
of
Journey
that
they're
doing
with
microservices.
Microservices
are
not
successful.
If
this
type
of
capabilities
are
not
being
given
to
them,
we
don't
want
them
to
build
them.
We
want
them
to
use
them.
D
All
right
there
we
go
so
in
my
grafana
dashboard,
we
ship
a
number
of
different
pre-built-in
configurations
so
that
you
can
see
all
the
kind
of
things
that
you
might
care
about.
So
let's
go
and
take
a
look
at
my
service
to
service
View.
Here
I
can
take
a
look
at.
Let's
just
take
a
look
at
the
last
few
hours
here
there
we
go.
Let's
do
six
hours
I'm
going
to
choose
which
applications
I
want
to
view
metrics
for
right.
So
we
have
very
granular
observability
here.
D
D
You
take
a
look
and
see
my
Reddit
service.
I
can
see
the
number
of
incoming
and
outgoing
requests
the
traffic
going
to
this
and
I
can
drill
down
to
any
of
those
Services
across
any
of
those
clouds
through
a
single
dashboard.
Now
we
also
ship
a
custom
plugin
for
grafana,
which
gives
you
a
visual
mapping
of
all
these
services
in
your
environment.
So
go
and
take
a
look
at
my
mesh
dashboard
and
we
can
actually
see
we've
got
different
applications
running
here
and
this
live
updates
right.
D
This
is
dynamic,
so
as
this
traffic,
if
I
start
getting
500
or
I,
start
getting
400s,
these
quadrants
will
update
and
show
me
maybe
the
red,
quadrant
or
show
me
how
many
requests
are
failing
and
then
I
can
dig
into
that.
Obviously,
I
already
have
a
couple
of
services
in
this
environment,
but
you
can
imagine
once
this
is
a
sprawling
environment
across
multiple
clouds,
this
kind
of
view
and
being
able
to
dig
into
exactly
where
the
issues
are
is
super
useful,
John.
B
That's
Kong
mesh
support,
multi-tenancy,
so
I
can
provision
meshes
for
multiple
teams,
absolutely.
D
And
that's
one
of
the
way
main
ways
that
customers,
actually
you
know,
sometimes
will
have
an
app
for
our
namespace,
an
app
per
cluster.
But
a
lot
of
folks
want
to
use
multi-tenancy
within
a
cluster
and
we
can
provision
a
mesh
per
team
and,
like
we
talked
about
earlier,
because
that
certificate,
Authority
root
of
trust
is
mesh
specific.
We
can
ensure
that
if
you
have
a
tenant
in
a
single
mesh,
they
can't
talk
to
anyone
in
another
mesh
without
explicit
permission
to
do
so.
That's
fantastic
Okay!
D
So
we've
seen
some
of
the
high
level
operational
and
kind
of
business
value
you
get
with
Kong
mesh,
but
developers
are
a
big
part
of
the
organization.
So
let's
dive
a
layer
deeper
and
take
a
look
at
some
of
the
features
we
can
enable
for
our
teams
to
be
more
comfortable
and
efficient
with
their
service
technology.
D
So
as
Opera
I
love
that
security
is
baked
in.
For
me,
like
I
said
our
connect
team
came
to
me
and
said
we
just
switched
mtls
on
it
literally
took
five
seconds.
We
budgeted
like
three
weeks.
We
don't
know
what
to
do
now
right,
but
these
kind
of
platforms
can
often
lock
me
down
as
well
right.
So
if
I
have
a
platform
comes
in
usually
it's
kind
of
heavyweight
now
developers
don't
have
a
lot
of
autonomy
to
do
what
they
want.
They
always
have
to
submit
tickets
with
Kong
mesh.
D
So
let's
go
back
to
our
Kong
mesh
UI
here
and
I'm,
going
to
jump
down
to
access
control,
we'll
see
for
my
Dev
a
mesh
right
of
two
matches
in
this
environment.
I
have
an
access
role,
saying
the
dev.
A
developer
can
create
delete
and
update
traffic
permissions
and
rate
limits,
which
are
two
of
the
policies
that
we
offer
for
Kong.
Mash
I
also
have
another
role,
another
rule,
sorry
which
is
down
here
again.
D
So,
let's
actually
see
that
in
action,
I'm
going
to
jump
over
to
my
Global
control
plane
and
my
my
terminal
here
and
I'm
going
to
log
in
as
let's
say,
I
want
to
apply
a
rate
limit
to
mesh
B
but
I'm
going
to
log
in
as
a
developer
on
the
mesh,
a
team.
Now,
let's
see
what
happens
when
I
hit
enter
nope,
it's
going
to
tell
me.
B
Well,
so
with
this
we
can
set
up
guard
rails
and
decide.
What
is
the
degree
of
self-service
that
we
want
to
enable
to
our
teams
and
each
team
may
be
different,
absolutely.
D
D
I'm,
not
authenticated,
but
let's
say
now,
I'm
going
to
log
in
as
a
developer
for
mesh
B
and
hit
enter
we're
going
to
see
that
Kong
mesh
is
going
to
evaluate
all
of
those
rules
and
we'll
say
rate
limit
applied
right,
so
I
can
be
very
granular
not
only
between
meshes
right.
So
we
might
want
to
use
that
as
the
agent
of
tenancy,
but
I
can
also
be
very
granular
within
a
mesh
if
I
just
have
a
service,
multiple
services
with
a
mesh
one
service
team
can
have
granule
permissions
on
one
service
and
not
another.
D
D
So,
let's
take
a
look
at
our
Commerce
UI,
again
I'm
going
to
head
down
to
traffic
permissions,
so
traffic
permissions
is
a
policy
that
a
lot
of
folks
tend
to
use
and
I
have
a
traffic
permission
in
here
which
says
that
let's
go
to
my
yaml
have
a
traffic
permission
which
says
all
services
can
talk
to
all
other
services.
So
when
I
go
back
to
My
Demo,
we
can
see
if
I
hit
my
demo
again
Auto
increment
this
we're
hitting
all
of
those
different
backends
right.
D
We're
balancing
between
AKs
gke
and
VMS
I'm
going
to
go
ahead
and
delete
that
traffic
permission.
So,
let's
go
delete.
Traffic
commission
allow
all
in
Dev
a
so
once
that
goes
through,
and
Kong
mesh
pushes
that
out
to
all
of
our
data
planes,
we
can
see
oh
we're
starting
to
get
errors
on
our
front
end
right.
We've
now
taken
away
the
permission
for
our
node.js
front
end
to
talk
to
our
redis
backend
across
the
entire
mesh.
This
kind
of
capability
is
extremely
powerful.
D
Now,
let's
set
this
back
up
again
because
we
want
to
put
that
traffic
back
and
again
once
this
is
applied
and
pushed
out
to
all
of
our
data
planes,
we'll
start
seeing
that
our
application
instantly
starts
connecting
and
is
rebalancing
traffic.
So
the
Simplicity
and
flexibility
that
comesh
allows
you
to
control
traffic
at
layer,
4
and
layer.
7
means
your
development
teams
again
can
spend
minimal
time
setting
this
stuff
up
right
and
it
enables
them
to
deliver
a
much
better,
faster
experience
to
their
partners
and
customers.
D
Now
we
also
may
want
to
be
a
little
bit
more
efficient
with
this
app.
This
front
end
is
running
in
eks,
but
I'm,
balancing
all
of
my
traffic
between
all
of
these
clouds-
probably
incurring
you
know,
egress
costs
right
or
latency
within
Kong
mesh.
We
have
very
granular
routing
capabilities.
I
can
choose
that
all
the
traffic
in
my
eks
zone
should
stay
within
May
cast
on
I
already
have
a
redis
in
that
at
back
end.
D
D
Aware
load,
balancing
true
make
sure
I
spell
that
right,
save
that
now
I'm
going
to
go
and
apply
those
settings
back
up
to
my
mesh
again
as
soon
as
that
takes
effect
goes
into
my
Global
control.
Planes
pushed
down
to
all
of
my
data
planes
we'll
see
my
eks
front
end
is
now
only
hitting
my
eks
back
end.
Getting
rid
of
all
that
egos
traffic
costs
getting
rid
of
all
that
latency.
D
So
as
a
developer,
I
want
to
be
able
to
get
up
and
running
quickly
with
as
little
complexity
as
possible,
but
while
also
having
the
freedom
to
experiment
and
change,
routing
and
change
security
like
this
tongmash
is
the
only
cross-cloud
cross-environment
application
service
mesh
that
doesn't
trade
Simplicity
for
flexibility
and
is
going
to
help.
You
deliver
faster,
more
efficient
software.
B
B
We
could
have
the
best
multi-cloud,
the
best
Gateway
the
best
match.
We
could
have
the
best
infrastructure
in
the
world
and,
like
I,
told
you
before,
if
nobody
consumes
it.
All
of
this
is
useless.
The
value
is
being
driven
by
the
usage
that
we
can
generate
on
our
apis
and
how
do
we
incentivize
our
teams
to
discover
and
consume
apis?
Well,
we
need
to
talk
about
API
productivity.
I
was
an
API
developer
myself.
B
Sometimes
you
know
a
manager
would
say:
hey,
go
ahead
and
build
this
application
and
just
use
this
API
well,
but
just
using
another
API,
it's
actually
many
steps.
It's
getting
familiarized
with
an
API
start
testing
the
API,
and
then
you
know
eventually
integrating
this
API.
There
is
a
lot
that
goes
into
it
and
that's
why
API
productivity?
B
If
we
had
to
unpack
it,
it's
about
API
debugging,
it's
about
API,
marking
testing,
it's
about
making
sure
that
we
can
design
apis
the
proper
way
and
then
once
we
have
everything
configured,
making
sure
that
we
can
use
practices
like
API
Ops
to
push
all
of
our
configuration
into
our
infrastructure
and,
of
course,
because
we're
not
working
in
a
silo,
API
productivity.
It's
also
about
API
collaboration.
B
We
want
to
make
sure
that
we
can
work
with
our
team
members
as
we
build
and
design
and
consume
apis
failure
to
do
so,
and
failure
to
provide
an
API
productivity
strategy
to
our
teams.
It's
like
giving
a
dull
knife
to
a
surgeon.
They're
not
going
to
be
able
to
operate.
It
doesn't
cut
right.
It
needs
to
be
there
so
that
our
teams
can
be
productive.
B
Failure
to
do
so
means
that
there
is
lots
of
coordination
that
now
it's
required.
The
apis
are
incompatible.
The
apis
are
not
reliable.
The
apis
are
not
tested,
the
apis
are
breaking,
whereas
with
the
right
API
productivity
tool,
we
can
fix
all
of
these
use
cases
again.
It's
a
very
suiting
place
to
be
versus
a
chaotic
place
to
be.
B
The
API
productivity
product
at
Kong,
it's
called
insomnia.
Many
of
you
have
actually
told
me
in
our
customer
conversations
that
perhaps
you
already
have
an
API
productivity
tool,
but
the
teams
are
complaining.
It's
bloated,
it's
not
extensible,
it's
too
expensive,
and
so
with
insomnia.
B
Kong
is
providing
an
opportunity
to
have
the
same
flexibility
as
every
other
product,
the
Gateway
in
the
mesh,
but
in
the
API
productivity
world,
and
this
is
why
today
I'm
very
excited
to
announce
a
new
major
release
of
insomnia,
this
one
ships
with
amazing
new
capabilities
that
I'm
going
to
cover
in
just
a
second.
By
the
way
for
those
of
you
who
wonder
what
does
insomnia
mean?
Well,
it
means
that
our
apis
should
never
sleep
because
they're
always
being
requested
always
being
consumed,
but
we
should
sleep
foreign
all
right.
B
B
We
all
know
that
nobody
wants
to
document
the
apis
as
a
matter
of
fact,
yesterday,
at
the
customer
Advisory
board
apis
that
are
not
documented,
have
been
identified
as
one
of
the
most
critical
problem
that
prevents
the
ReUse
of
apis
in
our
organizations.
If
they're
not
documented,
nobody
wants
to
use
them,
and
so
with
insomnia
in
early
2023,
we're
going
to
be
able
to
provide
automatically
generated
suggestions
for
documentations
for
each
endpoint
in
each
API.
B
But
again,
I
would
like
you
to
see
a
live
demonstration
of
this
product,
and
so
please
welcome
on
stage
Kat
Morgan
senior
developer
Advocate
at
Kong.
Who
will
give
you
a
live
demonstration
of
what
insomnia
can
do?
Welcome
cat.
E
E
The
future
okay,
so
as
Marco
said
I'm
Kat
Morgan,
but
today
I,
would
invite
you
to
imagine
with
me
that
I
am
a
developer
crucial
to
your
success.
So
I
am
in
your
business
on
your
developer
team
and
we've
just
undertaken
a
new
initiative
together.
I
want
to
get
started
and
show
how
insomnia
can
power
that
development.
E
All
right
so
on
this
first
screen
of
insomnia,
this
is
my
local
development
dashboard
and,
from
here
I
can
create
things
that
belong
to
me,
whether
I'm
discovering
new,
apis
or
creating
new
ones.
But
if
I'm
working
with
a
collaborative
UV
with
a
team
I
need
to
jump
into
something
that
we
can
all
share
together.
E
So
right
here,
I
have
a
really
basic
grp.
Actually
we're
going
to
go
jump
into
coinbase
everyone's
Hot
Topic
right
now
and
I'm
going
to
connect
to
this
websocket,
but
at
first
it's
going
to
error
out,
and
why
is
that?
That's
because,
with
this
websocket
setup,
I
can
specify
what
environment
I
want
to
Target
and
now
that
I
have
chosen
one.
The
address
environment,
variable
populates
and
now
I
can
connect.
E
E
I
hope
this
isn't
going
to
hurt
you
personally
today,
but
now
we're
receiving
these
the
the
live
messages
from
this
websocket
and
and
down
below.
You
can
actually
start
exploring
the
body
of
the
messages
that
you're
receiving
as
well
as
jumping
into
different
headers
and
the
the
actual
logs
produced
by
the
client.
While
it's
retrieving
these
messages,
so
all
of
that
was
just
Discovery
and
exploring
an
API
that
you
have
access
to.
E
But
what,
if
it
is
time
for
me
to
go
ahead
and
start
creating
and
that's
where
insomnia
gives
me
other
opportunities
to
design
and
develop
my
own
spec?
So
this
is
what
this
document
shows
now
on
the
left.
You'll
see
that
I
have
navigation
opportunity,
actually
I'm
going
to
jump
to
this
design,
tab
up
here
and
expand
the
design
organization.
So
this
is
where
I
can
Define
what
servers
and
endpoint
paths
that
I
can
hit
and
shows
me
the
schemas
that
I'm
designing
for
those
endpoints
on
the
top
in
the
right.
E
You
can
see
that
I
have
access
to
my
open,
API
spec
to
design
that
and
write
it
live
here,
and
every
change
that
I
make
is
going
to
immediately
render
as
different
as
the
actual
documentation
that
other
developers
will
use
to
consume
my
API,
which
sees
what
you
get
exactly
so
it's
not
just
for
reading
either.
So
you
can
hit
the
try
it
out
and
have
an
executable
and
interactive
documentation.
E
You
can
trade
that,
with
other
people
you
haven't
converted
to
insomnia
yet
with
basic
curl
commands
that
explain
what
you're
doing
see
the
body
of
your
request-
and
this
just
is
the
beginning
of
unlocking
now
I'm,
going
to
jump
to
that
testing.
Automation
really
quick
before
we
close
out,
and
hopefully,
if
I've
done
all
of
my
development
work
and
designed
my
tests
correctly.
All
of
these
tests
will
pass
with
flying.
Colors
and
I
won't
have
insomnia
tonight,
Marco,
okay,
well,.
D
E
B
Okay,
fantastic
today
we
walk
through
the
importance
of
needing
an
API
vision
and
transform
our
business
with
an
API
platform,
one
that
can
drive
a
API
outcome
on
top
of
our
business
execution.
That's
very
important,
then:
we've
seen
how
bottom
up
we
can
support
our
teams,
accelerate
them
by
leveraging
conch
mesh
with
a
modern
service
mesh
and,
finally,
how
we
can
make
our
teams
more
productive
with
insomnia
all
right,
so
without
any
further
Ado.
We
have
a
day
full
of
sessions.
Let's
go
build
the
nervous
system
for
apis.
Thank
you.
So
much
foreign.