►
From YouTube: Building the Next Era of Software
Description
The pace of innovation continues to accelerate, and building the next era of software requires using the latest tools, technologies and best practices to maximize effectiveness. This Kong Summit 2019 panel of leading industry practitioners discuss what’s at stake in building new software, strategies and tactics for creating change, and lessons they’ve learned in trying to make the future of software a reality at their organizations.
Melissa van der Hecht | Peter Tsatsaronis | Nancy Wang | Preeti Somal | Alex Golden
Learn more about Kong: https://konghq.com/
A
Hi
I'm,
Melissa
and
wow
what
a
keynote
I
am
so
excited
by
the
next
era
of
software
at
Kong,
koomer
envoy,
studio.
I
cannot
wait
to
get
hands-on
with
this
and
all
the
stuff
that's
going
to
be
introduced
over
the
next
couple
of
days.
I
am
also
super
excited
to
be
sharing
the
stage
for
the
next
half
an
hour
with
four,
absolutely
incredible
leaders,
so
let
me
bring
them
up.
We
have
Alex,
who
is
the
head
of
enterprise,
API
programs
at
Rakuten.
B
A
A
A
So,
firstly,
thank
you
all
so
much
for
joining.
We
welcome
Richter
Kong
summit.
Welcome
to
our
first
panel
of
the
conference
and
we've
been
speaking
a
little
bit
beforehand.
We
heard
this
morning
about
what
the
next
era
of
software
looks
like
things
like
cloud
automation,
machine
learning,
everything
being
smartly
connected,
it's
crazy!
How
much
there
is
today
and
what
I'm
really
excited
to
learn
about
is
what
really
the
next
era
of
software
means
for
you,
because
it's
obviously
different
for
each
one
of
us
and
for
every
single
organization.
A
C
So
moving
from
this
centralized
to
decentralized,
we
had
a
look
at
what
was
available
around
the
API
gateway
a
market,
and
we
looked
at
all
the
the
native
gateways
that
were
available
and
based
on
our
user
set.
It
was
probably
not
fit
for
purpose
at
that
time,
so
we
actually
explored
the
market
on
API
gateways
across
the
board
and
ended
up
picking
Kong
mm-hmm,
so
we
basically
container
we
basically
containerized
it,
and
then
we
deployed
in
a
nice
es+,
serene
AWS,
nice
and
now
we're
basically
providing
it's
a
multi-tenant
environment.
C
So
each
of
the
development
teams
have
their
own
instance,
so
they
can
run
and
manage
their
own
api
gateway
as
such,
but
we
provide
the
gateway
as
a
SAS
service.
So
the
teams
themselves
don't
necessarily
have
to
have
gateway
expertise
embedded
in
each
of
the
teams.
They
can
just
focus
on
delivering
business
value
for
their
products
and
we
provide
the
Gateway
as
a
service
as
an
internal
SAS
offering
mm-hmm.
A
C
So
we've
got
as
part
of
the
service
we've
built
what
we
called
a
CLI
tool
and
this
CLI
tool
and
effectively
you
get
your
API
definition
or
your
swagger
and
in
the
importer
into
this
tool,
and
we've
built
a
lot
of
the
the
governance
and
the
standards
of
the
API
definitions
inside
at
all.
So
if
you
actually
adhere
to
all
of
the
standards,
this
tool
will
deploy
and
publish
your
API
into
your
Kong
environment
and
also
publish
it
into
our
internal
developer
portal.
C
So
then,
what
that
does
it
allows
any
engineer
across
the
organisation
to
log
into
the
portal
and
see
what
is
running
in
our
environment
real
time,
and
we
built
a
a
workflow
where
you
can
actually
request
access
to
any
of
the
api's
that
are
currently
lot
of
for
reuse
across
the
organization,
and
that's
all
really
just
is
an
abstract
layer.
So
a
lot
of
the
development
team
needs
to
know
all
they
need
to
know.
C
Here's
their
got
a
common
interface,
which
is
a
sale
lights,
all
that
we
built
and
they
don't
really
need
to
know
that
complexities
of
running
a
manager
gateway.
So
it's
just
co
lights.
All
over
the
top
of
it
and
we
can
chop
and
change
cloud
providers,
we
can
chop
and
change
gateway
so
and
it's
seamless
to
the
end-users
for
us
so
yeah.
It's
a
pretty
pretty
funky
little
cook
tool
that
we
built
that.
A
D
That's
right
so
how
chic
or
you
know
our
roots
are
in
open
source
software.
We've
got
six
projects
out
there
way,
grant
and
Packer,
and
you
find
breakage
and
Packer
in
pretty
much
every
sort
of
modern
dev
pipeline
that
exists,
as
well
as
we've
been
sort
of
pioneers
around
the
whole
infrastructure.
As
code
category
with
terraform
dynamic
secrets,
management
with
Walt,
we
have
a
service
discovery,
service,
mash
product
called
console,
as
well
as
a
runtime
scheduler
called
nomad.
Now,
what's
really
interesting
for
us
is
our
products.
Our
open
source
products
are
downloaded.
D
That
happens
if
you're
running,
let's
say,
teams
of
people
or
multi
data.
Centers
and
so
on,
but
our
goal
is
really
to
enable
kind
of
that
core
use
case,
the
technical
problems
that
are
solved
to
be
enabling
that
in
the
open-source
community,
so
that
we
can
get
practitioners
really
using
and
loving
our
tools.
One
pattern
we
see
a
lot
of
is
long
lines
of
what
Peter
was
talking
about.
D
A
D
D
So
we
see
customers
running,
not
just
multiple
clouds,
but
also
multiple
technology
stacks
within
their
existing
environments,
and
you
know,
while
it's
really
great
to
sit
around
here
and
talk
about
micro
services
and
serverless,
and
all
of
that,
the
reality
in
a
customer's
environment
is
it
takes
time
and
effort
to
get
there,
and
so
how
do
we
provide
products
and
tooling
that
sort
of
enable
that
journey
without
needing
a
massive
rip
or
place
or
a
lift
and
shifting?
You
know
every
cloud
project
I've
seen
that's
been
a
lift
and
shift
the
companies
have
regretted
it.
A
C
B
Yes,
I'd
like
to
think
so
at
the
you
know,
I'm
in
the
technology
section,
so
we're
primarily
working
on
at
api's
I'm,
including
you
know
some
Hong
Kong
and
some
are
also
not
dong,
Kong
and
we're
really
trying
to
work
with
all
of
the
teams
throughout
the
entire
group
that
are
working
with
api's
and
enable
them
as
well.
So
one
thing
we're
looking
at
is
a
machine
learning
and
how
we
can
use
that
to
give
additional
insights
to
the
team.
B
So
something
like
the
Kong
vein
is,
you
know
exciting
for
us,
especially
how
it
can
generate
the
documentation,
the
swagger
automatically,
and
we're
also
looking
to
utilize
machine
learning,
to
also
give
those
insights
to
all
the
teams
in
rockton,
so
not
we'd,
like
all
the
api's
to
maybe
be
on
kong,
but
they're,
not
all
there
yet
so
we,
but
we
do
want
to
give
the
additional
insights
to
the
teams
who
are
not
Hong
Kong,
so
we're
looking
into
that.
That's.
E
I
don't
want
to
spoil
the
surprise
that
we
invent,
so
you
have
to
wait
until
then
to
hear
about
all
of
them,
but
that
creates
a
lot
of
challenges
right,
as
you
can
imagine,
predicting
SL
A's
that
our
customer
facing
as
well
as
SL
O's
that
are
internal
facing.
So
wouldn't
it
be
great
to
have
something
that
can
predict
so,
for
example,
automatic
load,
balancing
algorithms
right
predicting.
You
know
when
things
happen
and
doing
automatic
stress
testing
in
that
sense,
so
I've
definitely
seen
a
lot
of
innovation.
E
A
And
some
of
the
stuff
that
we're
saying
in
general
is
completely
changing
the
way
that
we
have
to
work
internally,
the
way
that
we
have
to
work
with
customers,
the
way
that
we
have
to
test
things
and
make
sure
that
our
data
is
secure.
How
much
of
an
impact
does
this
had
already
Nancy?
Let's
start
with
you,
how
much
of
his
impact
is
has
had
already
and
how
your
teams
operate,
how
you
communicate
and
who
you
communicate
with
in.
E
F
A
D
One
thing,
I'll
just
add,
is
what
we
are
seeing
from
our
customers
before
they
actually
get
to
the
point
of
using
the
service
mesh
like
step.
One
is
service,
discovery
right,
and
so
that's
where
we
see
a
lot
of
usage
kind
of
just
making
sure
that
the
service
discovery
foundation
is
in
place
and
then
from
there
they're
building
on
to
the
service
mesh
mm-hmm.
F
D
Not
as
much
we
do
actually,
let
me
take
that
back.
We
do
see,
for
instance,
with
Walt
right.
We
do
have
customers
large
telcos,
where
set-top
boxes
are
actually
authenticating
against
a
central
wall.
So
we're
starting
to
see
that
pattern,
where
sort
of
the
the
tech
devices
and
the
the
proliferation
still
needs
to
make
sure
that
they
are
accessing
security,
tokens
and
identity
and
they're
all
sort
of
coming
back
into
a
system
like
Walt,
so
that
use
case
definitely
is
top
of
mind.
Yeah.
E
That's
a
good
point,
so
the
work
that
I
sit
in
with
an
AWS,
Storage,
automation
and
messaging
recently,
I
incorporated
IOT
org
as
well
and
so
thinking
about
data
protection
and
for
IOT
devices.
Given
the
fact
that
today
many
of
them
operate,
different
protocols
is
going
to
be
one
of
the
challenges
in
interesting
challenges
to
solve
and.
A
B
B
Yes,
so
it's
not
not
our
team,
but
Rock
10
is
planning
to
launch
a
mobile
network
in
Japan,
and
you
know
also.
We
are
really
excited
about
the
5g
and
rock
10.
We
have
you
know
many
different
services
from
online
marketplace
that
travel
outside
to
even
the
sports
teams.
We
have
so
we're
really
wondering
what
kind
of
how
we
can
really
deliver
next-generation
services
over
the
5g
technology.
What.
A
Kinds
of
things
are
you
kind
of
playing
around
with
to
support
that?
Well,
let
me
rephrase
this:
have
there
been
things
that
you've
been
showing
around
with
and
so
far
kind
of
discarded,
because
maybe
you're,
not
organizationally,
ready
or
the
technology
isn't
quite
fit
for
it?
What
are
some
of
the
most
failure
stories
that
you
can
learn
from.
C
So,
from
my
perspective,
one
of
the
failures
that
we
had
was
you
know
we
went
to
this.
You
know
multi-tenant
hood
environment
for
the
first
time,
and
you
know,
as
we
were
onboarding
more
and
more
tenants,
we
got
to
a
point
where
we
had
to
actually
halt
onboarding,
because
we
were
basically
running
out
of
one
account
when
I
double
just
account.
We
see
now
BP
saying
we
grew
so
quickly.
C
We
ran
out
of
IP
addresses
and
then
we
started
hitting
all
these
constraints
and
limits,
and
it
was
taking
weeks
to
do
upgrades
and
bring
on
more
and
more
tenants
that
we
actually
halted
the
whole
onboarding
process
for
about
a
month
we're
a
architected
the
way
we
were
managing
and
onboarding
this
multi-talented
platform
yeah
and
we
ended
up
landing
on.
You
know
five
different
accounts
and
slightly
changing
the
way
we
we
built
out
this
multi-talented
platform
yeah.
It
comes
with
its
own
challenges
which
were
working
through,
but
you
know
we
grew
so
quickly.
B
C
A
daily
basis,
and
then
it
was
going
hourly
and
then
before
you
knew
it
also
yeah
it
was
it
was.
It
was
an
interesting
month.
We
did
a
lot
of
singing
and
dancing
we're
trying
to
on
board
at
the
same
time
and
slow
down
and
people
stopped
onboarding,
but
al
it
was
fun.
It
was
one
of
the
failures
that
we
learnt
and
now
we're
sharing
it
with
others
across
the
organisation
and
others
out
there.
So
yeah.
That
was
probably
one
of
the
one
of
the
failures
that
you
know.
A
C
A
D
Absolutely-
and
you
know,
I
think
the
thing
that
makes
her
shakur
unique
is
engineering,
is
a
hundred
percent
distributed
and
remote,
so
literally,
all
of
us
work
out
of
our
homes
and
so
that
sort
of
adds
another
unique
challenge.
What
we
find,
of
course,
is
that
our
work
environment
is
github
with
open
source,
we're
contributing
and
collaborating
in
github
all
day
long.
D
Getting
that
feedback
from
the
community
is
is
really
tight
loop
because
our
engineers
are
looking
at
the
issues
and
PRS
that
come
in
and
are
sort
of
practicing
the
the
tooling
and
the
usage
of
that
tooling
in
the
model
that
the
tooling
puts
forth
as
well
on
a
daily
base.
We
clearly
sort
of
use
our
own
products
internally
as
well.
D
We
just
a
few
weeks
ago
at
Hershey
cons,
launched
terraform
cloud,
which
is
a
cloud-based
offering
now,
as
you
can
imagine,
it
runs
on
our
own
products
as
well
right,
so
we
we
kind
of
have
that
tight
loop
operating
and
in
terms
of
just
how
we
work.
You
know
we
write
down
a
lot
of
things,
so
we
have
a
very
strong
RFC
process.
We
do
get
product
requirements
from
product
management
and
just
the
nature
of
being
remote.
We
feel
like
that.
D
Asynchronous
communication
is
much
more
thought
through
because
you're
you're
sort
of
analyzing
and
putting
things
down
and
and
really
working
through
that
versus
having
kind
of
one-off
conversations
that
you're
not
following
up
on.
So
it's
an
exciting
model
and
it's
working
well
for
us-
and
you
know-
we've
been
sharing
a
little
bit
more
of
heart.
That's
working
and
it's
been
really
well
appreciated
as
well.
That.
A
E
Sure,
so,
being
on
the
product
management
side
very
similar
to
what
Preeti
said
right
engineers
should
be
practitioners.
You
know
this
is
something
that
I
learned
when
I
was
a
product
manager
back
at
Google,
which
is,
as
a
p.m.
you
should
dog
food,
your
own
product
right,
because
you
yourself
are
the
best
QA
that
you
can
possibly
be
for
your
future
or
whatever
you
might
be
designing.
E
So
that's
something
that
I
try
to
tease
out
whenever
I
interview
candidates,
and
especially
since
it
sounds
like
all
three
of
the
other
panelists
use,
AWS
to
some
extent
right
when
I
hire
what
we
call
technical
product
managers
onto
my
team.
That's,
where
are
we
going
to
have
they
gone
through
scenarios
in
which
they've
tested
their
own
product
and
found
bugs
in
the
process?
Mm-Hmm.
A
Say
one
of
the
things
that
may
be
a
bit
of
a
side
tangent,
but
one
of
the
things
that
I
found
really
interesting
recently
is
in
August.
The
Business
Roundtable
said
that
for
the
first
time
ever,
this
is
about
180
of
the
CEOs
at
the
top.
Companies
gather
together
and
they
agree
what
their
priorities
are,
and
for
the
first
time
ever
this
summer
they
said
shareholder
profits
is
obviously
a
number-one
priority,
but
it
is
no
longer
the
number
one
priority.
Corporate
or
social
responsibility
is
now
very
important,
and
how
much
does
this
play
a
role?
A
B
Acton
actually
I
think
it's
a
big
part.
Our
mission
is
actually
to
empower
people
in
and
society
through
innovation.
So
it's
something
that's
happening.
It's
discussions.
We
have
a
kind
of
company-wide
level
is
I,
know
everything
that
we're
building
is
to
empower
society,
so
I
think
accent.
Certainly
it's
there
it's
in
the
back
of
our
minds,
and
maybe
it's
not
something
like
with
every
you
know
sprint.
You
know
it's
like
okay.
What
are
we
gonna
do
for
society
this
print,
but
it's
it's
always
there.
Something
were
thinking
about.
That's.
E
Ice
yeah
for
sure
I
mean,
in
addition
to
simply
saying
you
know
your
product
has,
let's
say
eleven
nines
of
durability
or
it's
you
know,
started
across
multiple
places
when
buyers
are
thinking
about
services
and
products.
Today-
and
this
is
you
know,
agnostic
of
different
companies
right
I've
worked
with
or
interacted
with
is.
How
are
you
impacting
the
community,
and
so
part
of
that
has
been
the
reason
why
I
started
a
nonprofit
organization
called
a
fancy
woman
and
product
when
I
was
a
p.m.
E
at
Google,
we
just
bring
all
the
leaders
together,
agnostic
of
who
you
work
for
where
you
work
right
of
how
do
we
together
help
bridge
the
pipeline
problem?
Because
if
you
look
at
some
of
the
you
know,
leadership
in
tech
right,
there's
still
a
lot
of
work
to
do
in
terms
of
making
that
community
more
diverse,
because,
ultimately,
when
you
have
more
diverse
decision
makers
that
only
benefits
the
product
and
ultimately
your
bottom
line,
yeah.
F
E
E
Would
say:
observability
yeah
in
my
opinion,
because,
given
that
there
are
more
technologies
being
built,
humans
are
ultimately
you
know.
We,
we
have
a
limited
memory
or
the
ability
to
connect
the
dots
and
find
what
is
it
root
cause
of
problems,
and
so
that's
where
back
to
I
believe
Preeti's
earlier
point
on
service
meshes
right
is
being
able
to
identify
either
emergent,
behavior
and
combine
observability
with
management
to
help
you
identify
problems
earlier
and
also
give
your
customers,
at
the
end
of
the
day,
a
better
and
more
predictable
SLA
for.
C
Myself,
it's
probably
you
know,
really
leveraging
cloud
native
where
possible,
really
leveraging
technical
services
leveraging
other
SAS
capabilities,
because
I
find
the
business
spend
a
lot
of
time
and
effort
running
platforms
and
software
when
they
really
should
be
focusing
on
their
actual
product
themselves.
So
that's
probably
a
bit
of
whatever
advice
for
myself
and.
D
You,
you
know
I
absolutely
agree
with
that
and
I
think
for
for
me.
It's
also
just
trying
things
out.
Open-Source
is
such
a
wonderful
paradigm,
because
you
can
actually
try
the
software
and
see
if
it
works,
for
you
right
so
you're
not
making
a
big
decision
that
the
days
of
sort
of
you
know
having
to
go
through
and
make
a
kind
of
a
final
decision,
because.
F
D
A
My
last
question
really,
then,
when
it
comes
to
adopting
open
source
and
then
productizing
it
putting
into
your
pipelines
communicating
back
to
the
business,
you
may
not
know
what
the
technology
is.
How
important
is
it
to
have
a
rigorous
process
around
that,
or
is
it
still
successful
to
kind
of
just
try
things
out
and
stick
them
in
and
over
time?
Eventually,
things
will
confirma
so.
D
I
know
we'll
probably
different
from
the
banking
environment
versus
a
vendor,
but
even
sort
of
looking
back
at
my
experience
from
Yahoo.
You
know
the
projects
that
were
successful
were
always
grassroots
right.
It
was
engineers
who
are
really
passionate
about
the
problems,
they're
solving
they're,
finding
products
and
tools
that
solve
those
problems
really
well
and
are
very
easy
to
use
and
that
passion
then
kind
of
snowballs
into
a
much
bigger
effort
within
the
company,
and
so
before.
D
You
realize
it
you're
running
your
mission-critical
apps
on
something
that
started
off
as
a
grassroots
project,
and
it's
at
that
point
that
the
policy
in
the
governance
and
all
of
those
pieces
sort
of
start
becoming
more
critical,
and
so
that's
the
the
adoption
sort
of
that
we
are
seeing
and
they're
both
from
sort
of
my
vendor
perspective.
From
my
experience
at
harsha
corp
and
then
from
a
user
perspective.
From
my
experience
at
yahoo
is
it's
just
sort
of
starts
with
that
grassroots
focus?