►
Description
In this fireside chat, industry leaders with experience driving revolutions in software development and infrastructure will discuss transitions to microservices, Kubernetes, cloud native and open source across industries. The panel will also discuss how requirements have changed, and what paths these technologies and architectures could take in the future.
Learn more about Kong: https://bit.ly/2I2DypS
A
All
right,
hello,
everyone-
I
am-
I'm
super
excited
to
be
here
with
cameron,
purdy
and
brandon
phillips
for
a
25
minute
discussion
on
a
number
of
key
topics
that
I
know
everyone
listening
is
interested
in
cameron
and
brandon
in
some
ways
need
no
introduction,
they've,
they're,
they're,
very
famous,
in
what
they've
done
in
their
past
in
the
industry.
But
let
me
quickly
ask
them
to
to
introduce
themselves
and
talk
a
little
bit,
maybe
about
what
you've
been
up
to
in
the
last
couple
of
years.
Cameron.
Let's
start
with
you.
B
A
Our
industry
sometimes
tends
to
sort
of
grasp
something
and
consider
it
the
holy
grail
of
how
something
you
know,
problems
are
solved.
We've
all
been
through
these,
these
different
phases.
You
know
cameron,
you
remember
the
whole
ejb
phase
where
it
doesn't
matter
what
the
question
was.
The
answer
was
you
got
to
write
it
in
ajv's
and
you
know
we
can
probably
come
up
with
a
number
of
other
examples
where
this
has
happened.
You
know
web
services
and
so
on
and
now
you
know
a
lot
of
people
I
talk
to.
A
They
are
in
the
middle
of
transforming
into
microservices
they're,
taking
their
applications
and
building
separate
remote
services
to
talk
to
each
other
and
there's
always
this
dynamic
that
comes
in
when
you
are
taking
a
system
and
make
bringing
it
into
multiple
different
processes
that
need
to
communicate.
That
seems
to
be
a
reflection
of
of
trying
to
abstract
the
way
people
work
versus
how
the
system
should
really
be
designed
and
best
work.
So
with
that
in
mind,
what
is
your
thought
about?
A
C
C
It
is
pretty
convenient
when
you
have
like
a
piece
of
functionality
that
is
totally
fine
to
be
degraded
by
days
or
minutes
or
hours,
and
have
those
pieces
of
system
pulled
out
so
that
if
you
screw
it
up
or
you
need
to
modify
the
code
or
you
run
out
of
resources,
it
doesn't
take
down
the
rest
of
the
system
so
yeah.
I
think
I
think
there
are
legitimate
reasons.
C
A
B
At
the
other
end,
you
know
it's
really
easy
to
deal
with
state.
If
you
have
a
one
process,
you
know
monolithic
application,
because
it's
all
in
one
place,
but
you
know
but
you're.
You
know
your
feet
are
in
cement
at
that
point,
because
you
just
can't
move
very
well.
So
it's
a
it's
about.
You
know
how:
how
do
you
find
the
correct
fault
lines
in
order
to
be
able
to
take
a
large
system
and
break
it
down
into
digestible,
manageable
pieces
and
at
the
same
time,
how
do
you
you
know?
C
B
You
know
understanding
the
domain
well
enough
to
appreciate
which
pieces
of
the
application
are
going
to
depend
on
on
which
parts
of
the
state,
but
there's
you
know,
there's
also
a
an
understanding
of
you
know
what
coping
mechanisms
you'll
have
available
for
the
inevitable
fact
that
there
will
be
some
information.
That's
required
to
be
shared
in
some
form
across
multiple
services.
A
Great
before
we
leave
the
microservices
topic
cameron,
the
the
programming
language
that
that
you've
been
you've
been
working
on,
tell
us
a
little
bit.
Maybe
if
it
has
an
opinion
on
the
question
of
services
and
microservices,
and
how
that
that
brings
everything.
That's
how
it
brings
it
into
into
the
fault.
B
B
But
yet
it's
not
actually
trying
to
solve
the
microservices
problem
that
you
have
in
the
wild.
So
to
speak,
where
you
have
where
you're
building
many
many
different
services,
so
I
I
think
it'll
it'll
obviously
be
able
to
be
used
for
that
type
of
thing,
but
while
inspired
by
it,
it
doesn't
doesn't
just
solve
it
automatically.
A
Very
cool:
let's
shift
topic
a
little
bit.
We
talked
about
statefulness
and
how
almost
every
service
has
state.
I'm
gonna
bring
a
wild
one
here.
You
know
in
some
ways
it
feels
like,
first
of
all
that
almost
everybody's
either
on
kubernetes
and
moving
to
kubernetes.
Although
I
know
that's
not
really
true,
there's
still
a
lot
of
applications,
that's
not
on
kubernetes,
but
definitely
the
momentum
is
there
and
a
lot
of
times
I
hear
well.
Kubernetes
is
great
for
stateless
applications,
but
not
so
good
for
stateful
applications
and
and
brandon.
A
How
does
that
change
I
mean
given,
given
what
cameron
was
also
just
talking
about?
Almost
every
application
has
state.
So
what
does
this
mean
for
moving
to
kubernetes
with
all
these
services
that
actually
have
state,
and
you
have
to
manage
state?
Is
that
a
good
fit
there
and
is
how
we
solve
that
problem?.
C
I
think
that
problem
kind
of
just
goes
back
to
the
early
days
of
kubernetes,
like
the
the
team,
was
just
extremely
cautious
about
running
workloads
and
a
lot
of
the
apis
for
like
managing
state
and
file
systems
and
stuff
weren't
there.
I
think
today
it's
just
not
a
problem
to
run
stateful
workloads
and
I
think.
B
B
Yeah,
it's
interesting
what
brandon
was
saying,
and
quite
often
what
you
see
is
this
evolution
of
an
application
where
it
begins
with
everything
owned
by
the
application
and
over
time
you
know
more
formalism
comes
into
play
and
the
database
becomes
its
own
realm
and
its
own.
You
know
it
ends
up
with
its
own
dedicated
team
for
managing
it
and
so
on.
B
So
you
definitely
see
some
of
that,
and
I
you
know,
I
think
the
you
know
state
has
always
been
one
of
the
most
challenging
parts
of
our
industry
in
managing
state,
which
is
you
know,
speaking
of
oracle,
where
we,
where
we
met,
you
know,
that's
why
it's
been
such
a
great
business,
so
many
people
need
help.
You
know
managing
state
right,
the
I
think
the
the
you
know.
How
does
it?
How
does
an
organization
deal
with
with
that
state
as
it
grows?
How
do
they?
B
How
do
they
deal
with
the
evolution
of
their
organization?
How
do
they
transition
from
a
point
where
you
know
the
application
owns
a
state
to
where
it's
more
centralized
and
then
how
does
that
translate
between
you
know
their
own
data
center
and
running
that
in
the
public
cloud?
Those
are
those
are,
I
think,
the
challenges
that
the
companies
are
are
continuing
to
face
together.
A
C
I
mean
my
thoughts
as
somebody
who
started
career
in
in
in
the
linux
kernel.
Was
this
like
the
ultimate
triumph
of
the
posix
and
like
linux,
cisco
interface
like
essentially,
I
think
java
tried
to
abstract
something
away,
tried
to
protect
your
application
operating
system
and
then
linux,
just
that
cisco
interface
became
so
ubiquitous
and
so
widely
adopted
in
the
industry.
C
It
kind
of
removed
any
values
that
jvm
could
provide,
not
to
say
that
all
the
value,
but
a
lot
of
it,
and
that,
coupled
with
so
many
so
much
experimentation
through
like
the
late
90s
and
2000s
in
different
languages
that
weren't
on
the
jvm
and
were
getting
quickly
adopted.
I
think
it
yeah
it
sort
of
made
something
like
docker
inevitable,
to
package
up
those
applications
in
a
way
that
was
separate
from
the
way
that
the
linux
distros
were
actually.
B
I
think
one
of
the
interesting
things
is
that
you
know
what
kubernetes
proves
is.
Is
we
never
take
out
the
trash
right?
It's
like
we're.
Just
collectors
right,
it's
like
oh
javascript,
sure
I'll,
keep
that
java
yeah.
Why
not?
Let's
take
that
too?
Oh
linux
yeah
we'll
take
linux.
Let's
take
one
of
those
two
of
those
we'll
throw
some
python
in
there
and
you
know
it's
it's
it's
a
it's
too
bad
that
they
use
the
term
tarball
so
many
decades
ago,
because
if
they
hadn't,
we
would
have
just
called
kubernetes
a
tarball.
B
C
I
I
started
my
career
in
networking
and
I
find
it
just
hilarious
that
we
have
now,
like
the
hardware,
accelerated
1500
maximum
transition
unit
like
accelerators
it's
just
because,
like
the
internet,
it's
just
built
on
1500
bytes
and
like
you're,
just
never
gonna
you're,
just
never
gonna
get
rid
of
it.
It's
it's
in
the
dna
now
like
that's
just
how
that's
how
packets
are
switched.
A
Is
kubernetes
going
to
be
in
the
dna?
Do
you
think
you
know
back
when
we're
working
together?
Brandon?
I
remember
you
know
people
telling
me
they're
actually
putting
kubernetes
on
on
things
like
satellites
or
airplanes.
You
know
and
when
I
asked
why
you
know
because
they
had
like
two
processors
on
the
thing
the
the
answer
was
more
like
oriented
towards.
Well,
it's
the
way
we
do
things.
A
C
I
I
think
it'll
be
here
for
a
long
while,
and
I
do
feel
it.
It
fits
that
niche
of
the
linux,
the
lower
levels
of
the
linux
stack
just
never
bothered
to
define
what
a
container
was
and
so
kubernetes
for
better
or
worse
made
the
definition,
and
so
I'm
sure
that
we're
going
to
have
all
sorts
of
fast
forward.
10
years
from
now
we're
going
to
have,
like
you
know,
lightweight
system
d
in
it
processes
that
implement
a
subset
of
the
yaml
parser
for
kubernetes
for
embedded
systems.
C
I
I
think
it's
inevitable,
because
it
it's
a
language
for
expressing
those
sorts
of
constraints
and
and
restarting
services,
and
whether
service
is
healthy
or
not,
and
it's
yeah.
It's
become
kind
of
a
what
used
to
be
like
an
init
process
role,
it's
kind
of
redefined
that
I
think
in
a
lot
of
ways
that
make
a
lot
a
lot
of
sense
and
a
lot
more
user-friendly.
B
In
a
sense,
it's
a
it's
an
indictment
of
of
software
engineering
in
in
in
total.
In
that
you
know,
kubernetes
should
have
never
had
to
exist
like
it's.
It's
almost.
The
fact
that
it
does
exist
proves
that
as
computer
scientists
and
as
an
industry,
we
we
did
a
whole
bunch
of
things
wrong.
At
the
same
time,
it's
one
of
the
most
amazing
pieces
of
engineering
that
we've
ever
witnessed.
So
it's
like
it
has
to
exist
because
of
all
that
mess
that
we
should
have
cleaned
up.
B
So
I
like
to
think
of
it
as
a
you
know
the
same
way
after
a
holiday.
You
know
you
have
these
giant
plastic
things
that
you
shove
everything
in
until
the
next
year
when
the
holiday
comes
on.
Kubernetes
is
our
our
giant
plastic
container
methodology?
It's
how
we
it's
how
we
avoid
having
to
deal
with
all
the
messes
that
we've
recreated
over
the
past
several
decades.
A
A
Some
argue
that
we
are
we're
entering
a
new
mainframe
era
where,
like
everything,
you're
building
is
now
based
on
all
these
cloud
provider,
services
and
they're,
just
so
sticky,
something
like
amazon
lambda
not
to
not
to
not
to
pick,
but
you
know
something
like
that
can
be
quite
sticky
right
and
and
once
you've
written
your
whole
application.
Thousands
of
lines
of
code,
in
that,
how
are
you
gonna,
have
a
chance
of
portability?
A
C
Yeah,
I
do
think
it's
yeah,
it's
just
this
constant
struggle
between
investment
of
time
for
that
abstraction
versus
the
business
value
of
of
just
getting
something
shipped,
and
so
I
think,
it'll
be
an
internal
internal
struggle.
I
mean
at
the
time
I
feel
like
jvm
defended
itself,
because
there
was
there
was
some
unknowns
and
like
what
the
server
cpu
architecture
would
look
like.
B
C
I
I
think
one
of
the
other
things
like
where
it
is
pretty
easy
to
defend
the
value
of
tracking
yourself
in
the
cloud.
Is
it's
so
expensive
to
have
developers
coding
directly
against
the
cloud
like
if
you
give
every
developer
a
cloud
sql
database
and
their
own
gte
cluster
and
everything
like
you're
you're
easily
getting
the
thousands
of
dollars
per
developer
per
month
and
just
infrastructure
for
them
to
like?
Do
their
dev
work?
C
A
B
B
A
You
know
I
just
had
a
flashback.
I
remember
cameron.
You'll,
probably
remember
this:
do
you
remember
a
library
called
rogue
wave?
Yes,
I
remember
using
rogue
wave
and
it
had
things
like
rx
map.
I
assume
you
mean
rogue
wave
for
c,
plus
plus
that's
right
for
c
plus
and
like
rh
array
and
I'd
written
all
against
the
rogue
wave
library,
my
code
and
a
contractor
came
in
and
he
was
like
you
guys
are
using
this
stuff
directly.
Your
code
is
completely
attached
to
rogue
wave.
A
A
A
C
I
mean
there's
a
lot
of
aspects
of
culture
that
important.
I
think,
one
of
them
that
I
remember
specifically
thinking
a
lot
about.
Is
leaders
responsibility
to
create
urgency
in
an
organization
it's
particularly
particularly
when
you're
originating
technology.
It's
really
easy
to
to
focus
on
the
technology
and
not
have
not
have
the
next
goal
in
mind
of
of
either
showing
to
the
customer
or
giving
out
that
next
blog
post
or
that
sort
of
thing.
C
A
C
That's
true:
I
think
that
momentum
is
like
it's
a
it's
where
you
you
have
success
after
success
after
success
and
that
helps
to
motivate
people
and
urgency.
I
I
we
always
thought
about
as
dates
where
you
were
trying
to
hit
in
order
to
to
continue
that
momentum,
you
know,
and
so,
but
it
can
be
small
things
like
it's
not
necessarily
deadline
driven.
It's
you
know,
can
we
have
an
internal
company
demo?
Can
you
buy
wednesday?
B
B
And
then
the
other
thing
you
asked
about
the
urgency.
There's
a
couple
great
articles
online.
I
don't
have
a
link
off
hand,
but
on
the
on
the
difference
between
important
and
urgent
right,
and
quite
often,
companies,
big
and
small,
get
into
the
habit
of
focusing
on
on
the
urging
and
ignoring
the
important,
and
it's
so
easy
it's
what
I
call
fire
drill
mode
right.
B
Everyone
loves
fire
drill
mode,
because
it's
like
there's
this
terribly
urgent
thing:
let's
get
everyone
working
on
it,
let's
get
it
fixed
and
then
we
can
give
each
other
high
fives
and
yay.
We
fixed
it,
and
you
know
the
urgent
things
can
block
out
all
the
important
work
and,
and
they
are
so
interruptive.
A
Very
cool:
hey!
I'm
going
to
wrap
it
up
with
just
one
question
from
each
of
you.
What
would
be
the
advice?
You
would
give
a
younger
version
of
yourself
right
now,
perhaps
listening.
Perhaps
thinking
about
the
next
distributed
key
value
store
technology
to
be
building
that
that
goes
beyond
that
cdn
and
coherence.
B
C
Yeah,
I
think,
early
in
my
career,
I
beat
myself
up
a
lot
about
having
to
dig
in
and
maintain
old,
broken
systems,
which
is
like
kind
of
my
my
role
as
an
external
engineer,
and
but
that,
having
that
like
depth
of
understanding,
particularly
of
old
of
all
their
systems,
that
aren't
that
you
didn't
originate
that
were
built
before
you
and
having
that
skill
set
of
essentially
like
for
a
computer
science.
Forensics
like.
Why
does
this
exist?
C
B
I
guess
if
I
had
to
pick
one
tiny
bit
of
wisdom,
I
would
say
you
know
the
people
that
you
see
in
the
industry
who
are
successful
and
doing
incredible.
The
the
distance
between
you
and
and
them
is
tiny.
It's
minuscule,
you
know
just
a
couple
years
ago
they
were
you,
they
were
in
your
shoes.
They
had
no
idea
what
to
do.
Next,
they
had
no
network
to
rely
on.
They
had
no
experience
negotiating
with
vcs
or
closing
around,
or
they
had
no
idea
what
to
do.
B
They
had
never
served
on
a
board,
never
had
a
board,
you
know,
and
and
now
you
look
at
them
and
you
see
the
success,
but
what
you're
missing
when
you
look
at?
That
is
how
little
separates
where
you
are
from
that
type
of
success.
So
sometimes
you
know
you
just
have
to
take
a
step
of
faith
of
you
know.
Of
course
you
don't
know
what
you're
doing,
but
that
doesn't
mean
you
have
to
stay.
Where
you
are,
you
know,
be
willing
to
experiment,
be
willing
to
make
mistakes
and
be
willing
to
fail.
B
A
Yeah
good
advice,
thank
you.
This
has
been.
This
has
been
an
insightful
discussion,
really
appreciate
both
of
your
times
and
good
luck
with
your
future
endeavors.
I
know
there's
more
great
things
coming
up
from
both
of
you,
so
looking
forward
to
seeing
them
and
now
we're
ready
to
take
some
questions.
So
please
ask
your
questions
and
we'll
we'll
do
our
best
to
answer
them.
Thank.