►
Description
Are you prepared to transition from a monolith to microservices? Organizations worldwide are embracing microservices in an effort to be more agile, but implementation can be challenging. This Kong Summit 2019 panel of industry leaders discuss the challenges and strategies for transitioning towards microservices and how organizations can best prepare to get started.
Paul Dickens | Selina Liu | Karishma Irani | Tammy Butow | Ryan Michela
Learn more about Kong: https://konghq.com/
A
Thanks
Chuck,
so
we've
talked
about
today
about
this
journey.
It's
microservices
and
you
know
a
lot
of
times.
You
can
think
of
this
as
sort
of
the
ideal
world
we're
all
trying
to
get
to
the
truth,
is
we
all
know
in
this
room?
There
are
a
lot
of
pitfalls.
You
might
experience
on
the
way
there
and
so
we're
gonna
talk
today
a
little
bit
about
how
to
set
your
teams
up
for
success.
So
joining
me
are
four
people
who
know
this
journey
well
and
can
talk
to
that.
So
first
up
is
Karishma
irani
principal
p.m.
A
B
I
was
kind
of
hoping
you'd
forgotten
that
so
I
work
at
launch
directly
and
for
those
of
you,
the
name
just
rolls
right
off
the
tongue
launch
directly.
So
for
those
of
who
you
who
may
not
know
what
launch
Darkly.
Does
it's
a
feature
management
platform
that
allows
dev,
dev
and
operation
teams
and
p.m.
and
pmm
teams
feature
flag
things,
so
you
can
test
in
production,
so
launch
directly
had
already
adopted
microservices
well
before
I
started
there,
but
over
over
the
years,
as
I've
bet
with
customers
and
basically
wondered
what
it
is.
B
That
makes
them
one:
a
transition
to
micro
services,
I
hear
all
kinds
of
crazy
reasons.
The
first
one
is
well.
My
manager
just
asked
us
to
the
second
one:
is
it's
caused
by
an
acquisition
and
the
third
one
is
well
everyone's
doing
it,
so
we
should
do
it.
None
of
these
are
good
catalyst,
their
transition
to
micro
services
so
launch
start.
Lee's
primary
reason
is
just
the
growth
of
the
company.
B
A
C
I
work
at
Salesforce
and
we
are
an
old
company.
As
far
as
the
Internet
is
concerned,
we
go
back
like
20
years
and
over
those
20
years
we
started
and
continued
to
build
this
enormous
monolith.
It's
staggeringly
huge
thousands
of
engineers
work
on
it
every
day
and
that
just
doesn't
scale
for
us
anymore,
thousands
of
engineers
in
one
codebase,
all
interacting
and
all
integrating
with
each
other
continuously.
D
If
I
can
say
to
somebody
hey
like
what
are
our
top
five
critical
services,
you
know
and
if
we
can
then
say,
let's
focus
on
fixing
those
first
and
making
sure
those
are
really
good.
That's
a
very,
very
good
way
to
get
results
and
I
to
work
at
Dropbox
where
we
were
doing
the
migration
to
microservices
as
well.
Because
of
that
reason
it
helps
you
just
create
a
better
product
for
your
customers.
That's
more
reliable
and
more
durable
hi.
E
Everyone
Selina
from
Airbnb
so
very
similar
to
like
Salesforce,
Dropbox
and
other
stories
shared
here.
We
were
just
like
growing
so
much
our
more.
We
like
our
monolithic
application,
was
built
on
Ruby
on
Rails,
and
that
was
very
handy
initially
when
we
were
trying
trying
to
like
push
off
features
like
I
guess,
create
new
flows
for
hose
to
book
for
guests
to
book
listings
for
hosts
to
manage
their
listings,
but
down
the
road.
E
Our
team
grew
pretty
quickly
and
our
ways
of
working
also
evolved
so
shifting
to
I,
guess,
SLA
or
service
oriented
architecture,
kind
of
helped.
Us
rethink
the
ways
that
we
collaborate
and
also
help
us
to
you
know
like
spin
up
new
business
verticals
and
also
think
about
I
guess
scaling
our
technical
infrastructure
for
the
long
term.
A
Yeah
I
want
to
make
sense
and
I
think
one
thing
that
we've
talked
about
in
the
past.
As
a
group
here
is,
you
know,
as
you
decide
to
take
this
first
step
into
the
micro
services,
regardless
of
what
group
of
services
you're
tackling
there's
sort
of
a
benefit
to
having
some
operational
maturity
or
some
agreements
among
teams,
so
that
you
can
scale
that
up.
Tammy
I
think
you'd
mentioned
the
idea
of
making
sure
there's
some
automation
in
place
or
maintain
ership
agreements.
Yeah.
D
D
My
team
that
I
was
leading
at
the
time
one
of
the
teams,
I
led
storage,
databases
and
code
workflows
and
the
code
were
close
team
created
a
really
easy
to
use
file
like
a
Yama
file
for
anybody
to
be
able
to
say
this
is
the
service,
and
this
is
who
owns
it.
This
is
who
you
need
to
contact
and
I,
think
that's
also
really
important,
because
then
you
can
figure
out
how
you
can
improve
if
you
identify
issues
and
then
when
I
went
to
gremlin
I
was
like.
D
Actually,
this
is
pretty
cool
too,
because
you
can
do
chaos
engineering
on
a
service
to
test
that
everything
works
like
say,
for
example,
your
automation
for
your
service,
you
can
break
something
on
purpose,
check
that
everything
works
out.
If
it
doesn't,
you
can
use
your
ownership
file
to
be
able
to
contact
the
owner
super
important
and
a
massive
company.
D
E
E
I
think
we
are
trying
very
hard
to
really
consider
the
boundaries
between
services,
because
if
you
get
that
wrong,
it's
really
really
hard
for
you
to
lie
refactor
across
different
services
as
compared
to
when
you
were
just
like
in
the
monolithic
application.
You're.
Just
like
you
know,
working
with
modules.
They
have
like
software
boundaries,
so
I
think
having
a
more
formal
review
process
was
like
really
helpful,
for
you
know
just
like
maintaining
it,
and
you
know
trimming
the
ecosystem
through
something.
That's
leaner,
yeah.
A
A
C
We
have
virtual
architecture
teams
which
are
purely
advisory
in
nature.
It's
an
opportunity
if
someone's
building
our
team
is
building
a
service
and
they
want
to
talk
about
databases
or
you
know,
restful
api
is
or
something
they
can
submit
a
plan
for
review
and
then
senior
engineers
around
the
company
can
all
comment
and
it
provides
a
venue
for
kind
of
vetting
to
some
of
these
designs
and
getting
a
lot
of
organizational
feedback
on
it.
A
B
So
that's
the
obvious
challenges
that
I'm
sure
everyone's
run
into,
but
I
want
to
point
out
two
very
specific,
unique
challenges
that
I've
seen
repeatedly
in
customers
of
all
size
and
all
kinds
of
industries.
The
first
one
is
communication.
So
it's
it's
not
a
coincidence
that
micro
services,
the
era
of
micro
services,
sort
of
coincided
with
the
whole
concept
of
DevOps.
It's
bickers.
We
need
to
revisit
our
communication.
We
need
to
revisit
how
we
address
issues,
how
we
go
about
solving
them
and
how
we?
What
are
our
processes?
B
So
what's
our
communication-
and
the
second
thing
I'd
like
to
highlight,
is
when
you
move
to
micro
services,
they're,
basically
complex
chains
and
there's
no
standardization,
so
it's
hard
to
test
people
can
only
guess:
hey
I
tested
my
machine,
it
should
work
in
production,
that's
not
a
great
statement
and
personally
as
a
product
manager.
It
frightens
me
when
I
hear
that
so
I
think
the
second
one.
C
I
think
about
the
critical
importance
of
automation,
so
you're
mentioning
DevOps
and
the
need
for
that
with
micro
services,
with
a
monolithic
application
and
a
small
dev
team
you
can
get
away
with.
You
know,
build
test
release
is
you
know,
compile
zip
package,
and
then
you
know
manually
put
it
onto
a
machine
when
you
get
to
a
micro
services
architecture
that
just
doesn't
scale
your
building.
Your
testing,
your
automating,
like
all
of
that
stuff,
has
to
be
automated
and
locked
down
or
your
organization
is
just
gonna
fall
over
itself
in
human
operational
problems.
C
So
all
you're,
like
DevOps,
becomes
supercritical
all
of
our
continuous
automation,
continuous,
deploy
all
those
kinds
of
ops
things
you
hear
about.
You
really
do
need
to
have
those
solidly
in
place
before
you
try
to
go
to
micro
services
or
you're
just
going
to
trip
over
yourself
during
the
transition
I.
D
Think
one
of
the
big
things
that
changes
is
incident
management
and
specifically
on-call
and
I-
think
in
a
lot
of
really
great
ways
too.
So
if
you
use
microservices
instead
of
a
mono
lift,
then
you
can
make
sure
you
set
up
all
of
your
on
call
schedules
correctly
that
you're
paging
the
right
team.
You
can
also
do
some
really
cool
work
with
on-call
training,
something
that
I
like
to
do
that
I've
been
doing
for
the
last
few
years
at
gremlin
and
Dropbox
is
on-call
training
by
injecting
failure
doing
chaos
engineering.
D
So
you
can
actually
start
with
a
really
small
blast
radius
because
of
my
career
services,
you
can
say
we're
going
to
inject
some
like
latency
and
packet
loss
into
specifically
like
the
payment
service,
and
then
we're
gonna
see
make
sure
that
the
right
person
knows
how
to
handle
it.
The
right
person
gets
paged.
D
E
Would
agree
that
I
think
in
a
monolith
you
don't
get
you
don't
I,
guess
you
don't
achieve
graceful
degradation
as
easily
it's
a
single
point
of
failure,
but
at
the
same
time,
I
feel
like
in
a
micro
services
where
all
you
have
many
points
of
failure,
so
I
think
the
challenge
would
be
for
services
to
be
resilient
and
to
be
robust
enough
to
handle
failures
downstream
and
that
a
lot
of
times
means
like
defining
I,
guess
or
identifying
solved
dependencies
versus
hard
dependencies
and
defining
I.
Guess
like
the
default
behavior.
E
If
any
downstream
service
were
to
fail.
So
I
think
that,
like
that
burden
falls
on
the
part
of
like
the
product
engineers,
building
or
running
the
service,
to
be
active
in
doing
that
and
I
think.
Another
thing
is
also
just
like:
defining
the
contracts
between
different
services
I
think
it's
not
as
easy
to
iterate
on
your
module
when
it's
a
service,
that's
running
in
production
as
compared
to
when
you
were
just
I
working
on
a
library
within
a
monolith.
I
think
it
I
guess
evolving.
E
C
It
might
might
return
bogus
answers,
there's
all
sorts
of
crazy
things
that
can
happen
so
thinking
about
resiliency
and
micro
services
is
a
whole
new
domain
of
thinking
for
a
lot
of
developers,
but
it's
also
critically
important
to
deal
with
the
coves
kind
of
like
partial
failures,
something
to
think
about.
It's.
A
Interesting
I
think
it's
a
waste
nicely
into.
If
you
think
about
you,
know
kind
of
two
parts
of
this
journey.
You
have
a
lot
of
different
teams
now,
especially
at
large
organizations,
they're
sort
of
choosing
their
own
version
of
the
best
tool
for
the
job,
and
so
that
means
that
you've
got
organizational
communication
challenges,
but
you've
also
got.
If
you
look
at
like
the
CN
CF
logo
charts
any
number
of
things
that
you
might
choose,
how
do
you?
How
do
you
guys
decide?
You
know?
What's
a
trend
versus
what's
a
fad?
D
Favorite
thing
to
do
is
battle
testing,
so
I
like
to
try
new
technology.
It's
actually
one
of
the
values
that
we
have
that
gremlin
like,
for
example,
our
agent
is
written
in,
but
yeah.
What
we
like
to
do
is
actually
like
take
different
technologies,
put
them
alongside
each
other
and
actually
see
which
one
comes
out
on
top
I.
Think
that's
a
great
thing
to
do.
I
think
you
should
always
make
time,
because
you
know
if
I
used
to
work
at
a
bank
and
I
used
to
work
on
mainframe
stuff
too.
D
So
you
know,
I
know
what
it's
like
to
be
stuck
in
the
past
and
it's
much
better
to
encourage
everyone
around
you
to
think
about.
How
can
we
do
better
like
because
that's
a
way
to
compete
as
well
and
keep
your
customers
like
you
know
if
you
have
a
faster
system
that
you
build,
that
serves
your
customers,
that's
much
more
reliable.
You
know
that
works
really
well,
especially
if
you're
in
like
the
e-commerce
world
or
if
you're,
in
banking
as
well.
E
For
I
guess
the
nice
thing
about
SOA
is
that
different
teams,
only
different
services
can
choose
whatever
I
guess
language
or
a
tech
stack.
They
want
to
use
like
there's
technical,
hello,
Joe
heterogeneity
in
that
sense,
but
I
guess
for
infrastructure
team
that
serve
other
engineering
teams.
The
stories
like
slightly
different
I
think
the
process
will
be
more
deliberate
and
more
careful
in
terms
of
like
choosing
new
technology
to
adopt
that.
Would
that
would
I
guess
impact
other
product
teams.
E
I
think
we
historically,
we
have
like
adopted
it's
mostly
a
case
by
case
basis,
where
we
look
at
different
technologies
and
do
a
very
careful
evaluation
of
the
pros
and
cons
and
how
they
fit
into
our
existing
tech.
Stack
and
I
really
agree
with,
like
metal
testing.
I.
Think
it's
a
lot
about,
like
you,
know,
prototyping
and
then
like
doing
a
proof
of
concept
before
rolling
it
out
to
the
masses
a
lot
of
times
when
someone's
really
passionate
about
a
new
technology
or
new
solution.
E
You
could,
like,
you
know,
add
a
flag
like
if
you,
if
you
they
could
give
engineers
the
option
to
opt
in,
but
the
default
would
still
be
falling
back
to
existing
technology.
So
I
think
by
socializing
your
like
new
technology
or
the
thing
that
you're
you
know
championing
for
I.
Think
that's
how
you
get
by
it's
all
very
Democrat
process
team.
C
Autonomy
is
one
of
the
big
selling
points
of
a
microservices
architecture,
teams
get
to
make
their
own
engineering
decisions
and
that
works
really
well
on
the
small.
But
when
you
start
dealing
with
some
of
these
cross-cutting
concerns,
if
each
team
chooses
a
different
feature,
flagging
service
and
some
of
them
use,
launched
darkly
and
some
of
them
use
other
random
random
things,
you
know
someone
else
uses
a
random
library.
They
found
on
the
internet,
and
another
team
builds
their
own.
D
B
A
A
D
Say
the
Linux
foundations
events,
those
are
really
great.
They
have
a
lot
of
really
interesting
things
and
what's
a
good
mailing
list
that
you
can
join
I've
been
involved
working
with
them
like
I,
find
like
all
of
the
communities
out
there,
you
can
just
email
them
and
ask
for
what
you're
interested
in.
Usually
you
always
get
a
response
back
on.
That's
what
I've
found
for
sure
yeah
anyone
needs
help.
Let
me
know
yeah.
E
Personally,
I
attend
meetups
just
to
like
meet
other
engineers,
I
think
it's
very
easy
to,
especially
when
you
work
for
a
big
organization
to
get
siloed
into
like
your
own
tech
stack
and
not
know.
What's
out
there,
I
think
it's
like
going
to
meetups
and
like
events
like
these
are
really
helpful
for,
like
just
like
you
know,
getting
yourself
exposed
to
the
wider
community
and
also
I
guess
getting
different
points
of
view
from
other
people.
B
For
us,
we
try
to
create
a
lot
of
these
events
and
avenues
internally.
So
one
of
the
ways
is
we
have
this
concept
called
a
weird
talk
where
you
can
pick
any
topic
and
share
it
with
the
entire
company.
You
can
give
a
talk
and
people
can
volunteer
to
come
in.
This
ranges
from
how
to
make
yeast
for
beer
to
here's.
A
new
tool.