►
Description
The movement towards cloud native applications has exploded in recent years, as Kubernetes has rapidly grown to be the most widely used container orchestration system available and Envoy has emerged as an innovative edge and service proxy. Cloud native technologies allow organizations to move quickly and scale with modern-day architectures. This Kong Summit 2019 panel of cloud native experts discuss lessons in deploying, using and optimizing cloud native technologies including serverless, service mesh to effectively manage microservices applications at scale.
Joseph Jacks | Michele Degges | Tsvika Rabkin | Kahnan Patel | Derek Argueta
Learn more about Kong: https://konghq.com/
A
Awesome
this
should
be
a
really
fun
panel.
It's
practitioner,
heavy,
so
practical,
real-world
advice,
I'll,
ask
the
panelists
to
come
on
out
kannan,
speaka,
Derek
and
Michelle
and
we'll
have
a
fun
conversation.
Talk
about
opportunities,
challenges
good
to
have
you
Michelle,
speak
and
I've
got
a
couple
more
Hyman
and.
B
So
I'm
Michelle
and
I
work
on
the
DevOps
team
at
Unity
Technologies.
We
have
the
big
game
engine
platform
and
I
work
on
under
the
ads
org.
So
we
help
developers
make
money
and
you
know
by
serving
ads,
so
we
use
a
lot
of
different
cloud
native
technologies,
kubernetes,
helm,
terraform,
which
I'm
really
excited
about
and
yeah
we're,
definitely
growing
we're
hiring
a
lot
of
people.
So
if
you're
interested
come
talk
to
me
afterwards,.
C
I'm
speaking
from
will
yet
what
we
do
is
battery
free,
Bluetooth
tags
which
can
be
used
for
tracking,
secure
tracking
and
then
sensing
such
as
temperature
and
motion
and
pickup.
So
we
we're
startup.
We
do
both
the
hardware
and
the
software.
We
have
cloud
infrastructure
to
handle
all
the
data
and
make
it
available
for
customers.
We
also
use
kubernetes.
C
D
D
E
A
So
you're
all
practitioners
you're
working
at
a
variety
of
really
exciting
technology
companies,
the
gaming
world,
IOT
enterprise,
software
and
consumer.
It's
fascinating
to
have
such
a
rainbow
of
perspectives
in
looking
at
the
same
trend.
So
what
was
the
catalyst
that
caused
your
yourselves,
your
various
organizations,
to
sort
of
look
at
cloud
native
as
a
trend
and
as
a
way
to
modernize
and
get
get
leverage
from
your
from
your
organization's?
Michelle
yeah.
B
So
for
us
it
was
really
just
the
next
step,
and
so
we
actually,
when
I
joined
a
little
over
a
year
ago,
and
we
were
migrating
from
AWS
to
DCP.
So
we
were
already
using
a
lot
of
cloud
native
technologies
and
you
know
at
Google
we're
using
like
gke.
We
created
a
new
like
common
deployment
pipeline
for
developers
to
use
to
quickly
deploy.
You
know
hundreds
of
times
a
day,
so
for
us
at
catalyst
was
really.
It
was
just
like
the
next
step.
B
Something
we
also
work
on
is
making
sure
that
local
testing
environments
are,
you
know
as
modern
as
they
can
be
so
we're
using
docker
compose
for
all
of
our
micro
services
and
yeah,
and
then
also
in
that
transition
from
aid
abuse
to
DCP.
You
know
we
were
able
to
kind
of
have
a
clean
start
and
a
clean
slate,
so
we
were
able
to
terraform
everything
so
really
using
infrastructure
as
code
and
making
sure
that
you
know
everything
can
be
planned.
We
can
see
the
plan.
C
So
for
us
we
didn't
have
actually
another
option.
We
didn't
have
any
legacy
systems.
We
have
to
maintain
the
state
in
some
central
location,
so
it
has
to
be
the
cloud
and
since
we
do
so
many
things,
we
do
hardware
with
this
software
and
the
team
is
really
small.
We
need
to
make
things
efficient,
so
we
go
for
everything
native
use,
what
we
can
and
focus
on
our
core
functionality
and
the
rest.
You
know,
services
like
calling
API
management,
we
take
the
best
components
and
integrate
into
our
systems
seem.
C
D
D
They
are
fast-tracked
over
our
dialogue,
mind
going
to
production
so
forth
right,
but
I
think
there
was
a
clear
distinction
for
us
that
micro-service
Foundation,
which
is
infrastructure
which
is
hosting
this.
This
services
versus
leveraging
some
of
the
cloud
services
as
a
first-class
database
as
a
service
or
application
as
a
services
right
we've
been
very
diligent
about
where
we
make
our
investments
leveraging
clouds.
D
So
it's
always
been
a
kind
of
a
comparison
between
a
cost
and
the
ROI
of
the
investments
that
we
are
getting
so
I.
Think
with
with
all
of
that.
The
great
example
is
Aurora
TB,
so
we've
been
running
MySQL
in
our
data
center
for
many
number
of
years
and
getting
the
best
performance
out
of
it.
But
when
we
move
to
cloud
just
a
drop-in
replacement
off
of
MySQL,
with
Aurora
type
of
underlying
architecture,
which
helps
us
scale
at
the
next
level
of
kind
of
the
needs
that
we
have
I.
E
So
Pinterest
has
been
around
for
about
a
decade
and
has
that
classic
tale
of
starting
off
as
a
Python
monolithic
application,
and
then
we
started
getting
a
lot
of
traffic,
and
now
I
have
to
figure
out
how
to
be
here
with
these
bottlenecks.
How
do
we
isolate
failures?
So
microservices
was
kind
of
a
natural
progression
from
there,
so
we
started
pulling
out
all
these
database
access
layers
into
their
dedicated
services
that
can
be
individually
scaled
or
even
each
identify
of
this
services.
E
What's
breaking
and
in
the
continued
evolution
of
problems
that
well,
as
the
scale
start
to
grow
and
we
get
more
traffic,
we
were
continually
four
ways
to
optimize
and
grow
our
infrastructure
and
example.
One
of
those
is
single
tenant,
ec2
instances.
We
have
all
these
machines
that
are
running
a
single
service
with
extra
CPU
and
RAM
does
not
being
used,
and
so
we
started
looking
for
ways
that
we
can
resources
and
so
containers
and
container
orchestration
kind
of
became
a
natural
progression
from
there.
E
So
never
was
really
that
we
seeked
out
how
to
be
become
cloud
native.
It's
just
that
a
lot
of
the
technology
we
started.
Looking
at
that
could
solve
our
current
infrastructure
problems,
we're
in
the
cloud
native
space.
Another
example
is
the
service
mesh
that
I've
been
working
on
building
with
my
team.
We
have
the
classic
problem
of.
E
We
have
a
service
framework
where
we
have
per
language,
clients,
libraries,
but
it's
a
really
large
burden
to
maintain
all
these
frameworks
and
keep
them
synchronized
and
so
abstract
and
thought
out
that
all
held
into
a
sidecar
proxy
was
a
really
nice
natural
progression
for
us.
So
that's
kind
of
our
journey
to
adopting
cloud
native
technology.
It.
A
Seems
like
a
lot
of
the
conversations
around
cloud
native
are
universally
positive.
Things
are
great,
helps
us
become
more
agile,
save
a
lot
of
money.
Innovation
increases.
What
are
some
of
the
so
in
this
sort
of
varying
stages
of
evolution
and
investment,
around
cloud
native
at
dynamics
and
Pinterest,
and
have
you
seen
anti-patterns
develop?
What
are
things
that
would
not
be
recommended
to
some
of
your
peers,
people
in
the
industry,
some
of
the
some
of
the
gotchas
anyone.
A
B
I
mean
for
us
there's
definitely
a
lot.
I
would
say
the
main
one
is
actually
just
because
of
the
structure
at
unity.
Kind
of
each
engineering
team
owns
their
own
infrastructure
and
they
also
do
Incident
Response
for
their
own
infrastructure
as
well,
so
they
create
the
alerts,
the
dashboards
and
everything.
So
it's
really
kind
of
educating
developers
on
using
new
technologies
and
using
the
tools
and
libraries
that
we
build.
B
So
one
example
that
just
happened
a
few
days
ago
is
we
had
our
data
science
team
had
they
had
a
cloud
sequel
database
and
they
listed
disk
size
as
50
gigabytes
and
then,
of
course,
you
know,
the
database
grew
beyond
that
size
and
when
they
ran
a
terraform
plan
again
the
plan
wanted
to
delete
that
database
and
then
recreate
it
and,
unfortunately,
for
them
in
production.
They
had
Auto
applies
that
to
true,
so
that
database
was
completely
just
deleted
in
production.
So
it's
it's
really
like.
B
C
A
B
I
think
like
it's
great
for
them
professionally
and
also
for
the
company
as
a
whole,
because
you
don't
just
have
one
small
team
of
DevOps
engineers
who
are
like
chugging
away
and
like
fixing
like
little
mistakes.
It's
like
we're,
educating
everyone
on
the
team
to
like
own
their
own
infra
and
like
build
cool
stuff
cool.
C
C
C
So
we
eventually
understood
that
serving
list
is
not
the
right
solution
for
us.
We
talk
to
the
ADA
every
Riskalyze
and
and
apparently
cost
you
about
four
times
on
demand
instances.
So
what
we
understood
that
is,
if
we
go
cloud
okay,
we
can
go
cloud
but
go
the
other
way
not
to
the
server
list,
but
back
to
the
machines
back
to
the
physical
servers
and
even
more
go
to
the
spot
instances
to
reduce
cost
as
much
as
we
can
so
we
reversed
went
Oh
kubernetes
running
on
spot
instances
managed
by.
B
A
C
Regarding
service
it,
no,
it
was
clear
for
us
that
we
gonna
use
cloud
functions
like
Google
cloud
functions
or
Islam
does
something
like
that
and
not
host
infrastructure
ourselves,
and
we
went
that
way.
But
we
understood
that
now
if
we
looking
on
cost.
This
is
not
the
right
solution
for
I,
don't
want
to
say
REI
ot
in
general,
because
if
I
look
on
on
the
IOT
as
a
spectrum,
so
we
are
on
the
far
edge
of
ultra
same
devices,
energy
harvesting
devices
and
it's
very
different
use
case
from
the
traditional
battery-powered
powered
iot
devices.
C
D
Yeah
very
interesting,
I
was
kind
of
like
thinking
about
what
he
just
said
for
our
dynamics.
Obviously,
or
rather
let
me
take
a
step
back
I
think
the
cost
is
the
the
biggest
focus
point,
but
the
cost
comes
in
the
in
the
terms
of
many
shapes
and
forms
like
the
cost
could
be
just
the
development
cost
of
building
two
different
solutions
for
on
premises
and
and
sauce
and
sauce.
Using
some
of
this
cloud
native
services
will
will
make
your
operational
burden,
and
you
know
it
will
get
up
and
running
pretty
quickly.
D
But
then
you
have
a
cost
of
maintaining
two
different
implementations,
so
I,
don't
know
how
how
productive
your
your
engineering
teams
or
developers
are
going
with
that
model,
but
I
think
the
more.
So
importantly,
I
have
seen
this
pattern,
both
in
our
dynamics
and
outside
talking
to
some
of
the
other
peers
and
colleagues,
when
you
choose
this
point
in
time,
solutions
to
solve
a
very
specific
problems
using
the
cloud
services,
just
like
a
databases.
So
it's
right
in
in
future
when
the
use
cases
changes
or
your
platform
evolves.
D
You
end
up
in
an
in
a
state
where
the
this
cloud
native
service
does
not
solve
all
of
your
problems,
and
that
also
kind
of
like
reminds
me.
The
conversation
I
was
just
having
with
Joseph
that
there's
this
big
ecosystem
of
open
source
companies
right,
who
does
a
very
nuanced
innovations
which
not
necessarily
every
single
cloud
service
flagship
solutions
will
solve
for
everyone
right.
So
III
think
you
end
up
duplicating
this
data.
Once
you
do
a
point-in-time
solution,
then
you
find
another
service
which
fits
some
slight
variation
of
that
use
case.
D
A
Interesting
this
this
reminds
me
of
treaties
comment
pretty
of
a
Shi
Corp.
The
world
is
heterogeneous.
You
go
into
an
enterprise
like
Cisco
or
AppDynamics,
and
there's
sort
of
five
of
everything,
so
guess
with
the
conclusion
from
your
like
anti-pattern,
be
too
centralized
on
one
standard
service
or
how
would
you
sort
of
think
through
I.
D
I
think
a
lot
of
this
enterprise,
the
use
cases,
are
our
solutions
that
we
are
building
for
our
customers
right.
It's
a
lot
different
from
a
cookie
cutter
solution
on
the
cloud
narrative
services
out
there
right
so
I
think
also
the
discovery
cycles
of
figuring
out
what
we
are
building
in
terms
of
features.
It's
a
lot
longer
right,
so
I
don't
know
if
it
it
makes
sense
to
you
just
do
this
point
in
time.
D
Solutions-
and
you
know
if
you
are
a
Netflix,
then
you
know
we
can
just
go
through
the
trends
and
it's
all
that
one
problem
and
tomorrow
just
use
some
another
cloud
service
to
kind
of
completely.
You
know
pivot
our
solution
right,
but
that
not
necessarily
happens
in
the
in
that
price
world.
That
much
right
when
you
have
so
much
complexity,
so
I
think
making
the
conscious
decision
of
you
know
what
what's
the
right
solution
for
you
and
whether
you're
hosting
that
solution
or
using
the
cloud
native
solution.
E
So
I
feel
like
the
Pinterest
infrastructure
story,
is
often
one
of
many
migrations
all
the
time.
A
couple
years
ago,
I
was
a
marketing
everything
to
docker
containers.
Now
it's
migrating
everything
to
cuber,
Nettie's
or
magnetics,
into
service
mesh
or
python
2
to
Python,
3
or
plenty
versions.
The
list
goes
on
and
I.
Think
one
thing,
that's
really
important
is
to
understand
that
when
you
change
things,
things
may
break
and
accepting
that
level
of
risk
and
being
prepared
to
handle
these
incidents
is
imperative
to
any
type
of
migration.
I
think
that's.
E
A
E
Yeah,
which
actually
thank
you
your
might
be.
My
second
point
was
thank
you,
which
is
that
when
you
have
a
very
large
Tituba
system,
chances
are
that
your
infrastructure
team
alone
cannot
do
all
the
work
themselves,
so
kind
of,
as
Michelle
was
saying,
it's
imperative
that
you
gave
your
developers
the
tools
to
do
the
work
themselves
for
their
own
services
and
also
provide
those
teams
with
incentives.
Why
should
I
beep
to
kubernetes?
A
Enablement
for
developers,
yeah
very
cool,
so
I
did
have
a
couple
of
questions
related
to
what
we've
been
talking
about.
We've
actually
covered
quite
a
lot
of
ground.
I
mean
we
have
another
12
minutes,
so
maybe
we
can
sort
of
improvise
the
rest
related
to
everything
we've
been
talking
about.
So
I.
Guess
me.
One
question
overall,
quick
question
for
the
whole
panel
are
any
of
you
using
Kong
today.
D
I've
dynamics
is
a
big
user
of
Kong.
We
just
put
as
a
service
as
a
traditional
gateway
and
in
front
of
all
of
our
applications
and
sauce
yeah
I
think
if
I
can
elaborate
a
little
bit
so
the
advantage
with
Kong
for
us
is
it's
an
open
source.
That's
fast,
and
we
are
not
locked
in
to
you
one
of
the
implementation
which
is
tied
up
to
the
vendor
and
we
are
planning
to
ship
the
same
ad
service
that
we
are
building
in
sauce,
exactly
identical.
They
packaged
in
on
pram
right.
D
Software
version,
which
cannot
be
customized
and
handle
two
different
use
cases
of
sarsen
on,
as
well
as
when
we
shipped
things
on
pram
the
license
for
preclude
us
from
kind
of
doing
some
of
the
use
cases
that
that
we
want
to
handle
right,
and
we
cannot
really
pass
down
this
cost
on
our
customers
right.
So
in
that
way,
I
think
it
became
that
perfect
solution
right
in,
like
the
first
few
days
that
we
need
something
which
has
the
enterprise
support
in
production.
D
A
That
makes
me
think
of
a
question
like
open
source,
just
like
abstractly
itself
kind
of
enables
levels
of
infrastructure,
neutrality,
infrastructure
portability
that
previously
proprietary
technology
stacks
did
not
provide.
Have
you
have
you
also
any
anyone
else?
Have
you
seen
sort
of
open
source
as
a
paradigm,
be
sort
of
fundamental
to
innovating,
on
the
infrastructure,
side
and
kind
of
providing
freedom
of
choice
and
flexibility
for
your
developers,
your
customers
I
think.
D
I
want
to
add
one
more
point
that
whether
you
are
on
premises
or
managed,
service
or
SAS
I
think
if
you're,
just
purely
SAS
as
a
consumer
company
are,
are
just
a
SAS
workload.
Still
the
the
complexity
of
different
public
cloud
provider
itself.
That's
a
good
enough
reason
to
to
have
this
kind
of
like
cloud
neutrality
right
so
I,
don't
think
anybody,
or
at
least
our
own
customers
like
Enterprise,
the
customers
that
we
go
and
talk
to
I.
Don't
think
anybody
is
married
to
one
cloud
nowadays
in.
A
The
same
way,
maybe
that
no
one
is
just
investing
on
one
open-source
technology,
they
use
many
cloud
providers,
they
use
many.
How
have
you
all
seen
open-source
be
in
looking
at
cloud
native
and
and
kind
of
evaluating
all
the
technology?
All
the
choices
I
mean
there's
cloud
native
like
map
of
8,000
technologies,
lots
of
choices
out
there?
How
are
you
navigating
the
choices
I.
C
C
A
C
On
the
data
layers,
we
decided
that
we
use
the
cloud
provided,
databases
and
when
we
need
to
move
to,
another
cloud
were
to
support
more
clouds,
so
just
build
the
adapters
for
the
for
those
data
layers,
because
the
complexity
and
burden
of
managing
the
data
layers
is
much
much
more
complex
than
managing
the
compute
layers.
So
this
is
the
directions
that
we
we
choose
to
go.
B
I
mean
sorry,
my
favorite
part
is
just
being
able
to
open
a
github
issue
so
like
basically,
our
philosophy
is
to
just
POC
everything.
So,
basically,
when
choosing
between
like
envoy
or
link
or
dere
sto
right,
we
do
a
POC
with
like
a
small
micro
service,
and
then
we
see
like
does
this
actually
meet
our
needs?
B
Well,
like
open
a
github
issue,
if
there's
a
problem
or
if
we
can't
figure
something
out
and
then
usually
like
if
the
maintainer
is
our
community
can
like
answer,
then
that's
like
a
huge
thumbs
up
for
us
because
it
just
gives
us.
You
know
the
help
that
we
need
and
the
support
that
we
need
to
actually
like
use
their
product
at
a
massive
scale
at
unity,
so
yeah
I'm,
definitely
a
big
proponent
of
open
source,
especially
when
it
comes
to
stuff.
B
Like
you
know,
we
have
like
little
problems
like
gr,
PC
load,
balancing
like
that's,
not
like
a
native
kubernetes
thing,
because
it
uses
HTTP
too
so
like
finding
like
a
solution,
whether
it's
like
client,
pooling
or
like
using
ISTE
or
envoy,
like
those
are
things
that
we
definitely
POC
and
then
you
know
try
to
standardize
on
at
the
company.
I'm
sure
you
guys
also
have
a
lot
to
say
about
open
source.
How.
A
E
Definitely
try
to
stick
to
open
source
as
much
as
possible,
partially
because
it's
just
so
great
to
be
part
of
a
community
that
is
trying
to
solve
similar
problems.
They
can
talk
with
and
say
hey.
This
is
my
solution.
What
is
yours
look
like
when
my
team
was
first
looking
to
replace
our
ingress
HTTP
router?
We
were
looking
at
a
couple
different
options.
E
One
of
them
was
build
our
own
load
balancer
and
then
the
other
one
were
looking
at
was
envoy,
and
so
we
kind
of
did
a
feature
by
pieter
comparison
and
come
on
boy
provide
a
lot
out
of
the
box
that
we
did
not
have
to
build
test
options.
We
went,
but
what
we
didn't
know
at
the
time
was
how
wonderful
of
a
community
it
is
that
we
could
open
an
issue
and
get
a
lot
of
great
feedback
from
the
maintainer
Zano.
E
This
is
something
that
we
could
fix,
or
maybe,
if
you
want
to
provide
a
pull
request,
were
happy
to
review
it
and
get
it
accepted.
Likewise,
we
have
quite
a
few
engineers
that
Pinterest
contributing
to
the
kubernetes
ecosystem,
so
kind
of
being
in
this
sort
of
family
of
people
trying
to
solve
same
technology.
Problems
has
been
extremely
beneficial
for
Pinterest
and
we
tried
to
leverage
that
as
much
as
we
can
very.
B
Whatever
cloud
native
means,
that's
a
great
question
so
for
me,
I
would
just
say:
POC
everything,
I
think,
as
you
mentioned,
as
well,
like
find
the
tool
like
the
right
tool
for
the
job.
So
don't
just
go
for
the
shiniest
thing,
because
it
probably
won't
need
me
or
needs,
and
if
it
is
super
new
as
well
like
kind
of
be
cautious.
So
we've
used
like
some
Google
cloud
api's
that
were
in
alpha
stage
and
then
they
completely
change
when
they
move
to
beta
right.
B
It's
so
like
using
those
things
in
production
is
really
scary
at
scale.
So
definitely
like
just
be
cautious,
like
work
with
the
provider
or
the
open
source
community
and,
like
figure
out
what
will
actually
like
meet
your
needs
and
then
educate
your
developers
so
that
they
can
like
manage
some
of
them
for
as
well.
C
So
if
you
go
to
one
edge,
you
lose
on
the
other
and
you
really
need
to
understand
what
you
need
as
an
organization.
What
is
your
true
pain
point
and
and
then
pick
the
right
sweets,
because
there
are
so
many
cloud
solutions
out
there
and
you
need
to
choose
the
right
one
for
you
and
there's
no
silver
bullet.
You
need
to
adjust
to
your
needs.
D
Yeah
I
think
I
agree
with
both
Michelle
and
I
said,
I.
Think
doing
your
due
diligence
in
front.
It's
very
important
whether
you
are
startup,
who
is
rapidly
growing
and
and
being
in
this
growth
world,
where
it's
very
hard
to
replace
things,
and
you
have
to
kind
of
live
by
the
choices
you
made
so
be
be
cautious
with
that
or
you
can
be
enterprise
who
need
a
great
partner
in
the
the
journey
of
what
you,
what
you're
building
and
what
you're,
supporting
and
I
didn't
think
being
in
cloud
native
you'll.
D
Be
able
to
do
those
customizations
or
you'll.
Have
that
great
partner?
Who
is
willing
to
kind
of
support?
The
alteration
to
the
to
the
services
that
you
made
right
are
the
way
you
are
using
so
I
think
that's
where
this
this
ecosystem
of
open-source
with
the
enterprise
support,
is
kind
of
the
trend
that
we
see
all
around
right,
that
you
have
a
great
partner,
always
available
whenever
you
need
help,
and
you
can
customize
this
open-source
world
how
you
see
fit
Turk.
E
It's
difficult
to
not
repeat
anything
goes
already
said,
but
coming
from
a
different
angle,
all
these
technologies
in
this
colony
of
space
are
moving
incredibly
fast.
There's
a
lot
of
development
going
on.
So,
if
you
do
decide
to
use
these
technologies,
I
would
urge
you
to
try
to
stay
up
to
date,
because
things
are
changing
all
the
time
and
adapting
all
the
time,
and,
along
with
that,
you
all
have
the
ability
to
influence
the
direction
of
these
projects.