►
Description
You want to migrate your existing application to serverless — and you don’t know where to start. This is a common problem that a lot of architects, CTOs and developers have, as it is very rare that we start as a greenfield project.
In this talk, I will cover some introductory concepts for serverless and walk you through different strategies for migrating an existing application to serverless. We will look at known architectures, existing challenges in our applications and how we can overcome them with serverless. I will also share lessons learned from working on the migration of one existing microservices application into serverless.
Learn more about Kong: https://bit.ly/2I2DypS
A
A
I
started
in
2015
and
been
putting
it
in
production
since
2016.,
I'm
the
host
of
a
youtube
channel
called
fubar,
where
I
post
videos
on
tuesdays
and
thursdays
about
serverless
cloud
computing
and
software
engineer
practices.
They
are
all
hands-on,
tutorials
with
workshops
and
things
that
you
can
try
and
experiment
yourself.
So
if
you
want
to
learn
more,
I
recommend
you
that,
after
this
talk,
you
go
there
and
check
the
channel
out.
A
A
Let's
start
first
talking
a
little
bit
about
what
is
serverless
for
that,
I'm
going
to
use
the
definition
that
jeremy
daily
one
of
our
aws
serverless
heroes
have
used.
Serverless
is
a
methodology
for
planning
building,
deploying
software
in
a
way
that
maximizes
value
by
minimizing,
undifferentiated,
heavy
lifting
and
what
that
means.
Let's
not
reinvent
the
wheel.
A
But
let's
go
a
little
bit
to
a
more
practical,
concrete,
like
definition
of
what
something
is
serverless
when
something
is
serverless
a
component
or
a
piece
of
technology,
a
service,
it
needs
to
adhere
to
these
kind
of
four
tenants,
the
first
one
it
scales
automatically,
meaning
that
you
don't
need
to
plan
for
its
scaling
if
you're
sleeping
and
then
in
the
other
side
of
the
world,
it
goes
viral,
it's
okay,
the
platform
will
take
care
of
it.
Then
you
pay
for
what
you
use.
That's
something
that
is
typical
from
the
cloud.
A
A
That's
again
coming
building
on
top
of
what
is
the
cloud
you
don't
have
to
manage
physical
servers
and
in
the
case
of
serverless,
you
don't
even
need
to
think
about
server
at
all.
You
don't
need
to
think
about
operating
systems,
firewalls
patching
and
installing
software
or
things
like
that.
Everything
is
way
more
abstracted.
A
And
finally,
the
last
bit
is
the
high
availability
built
in
when
you're
working
on
premise
or,
if
you're
working
in
the
cloud,
but
using
virtual
servers.
Usually
you
need
to
think
in
which
data
center
or
availability
zone
you're
going
to
deploy
your
application,
but
when
you're
working
with
serverless,
usually
services
are
regional
and
they
have
the
high
availability
built
in
the
service
already.
So
you
don't
need
to
think
about
that.
A
So,
basically,
at
the
end
of
the
day,
serverless
are
like
lego
blogs.
You
have
compute
service,
you
have
database
services,
you
have
queue
services.
You
have
things
like
that
and
then
you
pile
them
together
and
make
applications
that
work
for
you
without
really
to
not
to
invent
the
wheel
again,
and
you
end
up
with
an
architectural
diagram
that
looks
like
this.
A
This
is
something
that
burning
monk
that
is
jankyu
one
of
our
serverless
heroes
has
shared
around
and
it
became
very
popular
and
it
has
two
views
like
the
complexity
of
serverless
or
then
the
simplicity
of
serverless.
Because
if
you
look
closely,
you
will
see
that
each
of
those
boxes
is
a
little
service.
That
does
one
thing
and
then
basically,
at
the
end
of
the
day,
you
have
a
very
clear
understanding
of
what
this
application
is
doing.
So
when
you
get
familiar
with
serverless,
this
diagram
doesn't
scare
you
at
all.
A
This
is
something
that
is
a
very
clear
architecture,
diagram
of
what
this
application
does.
So
now.
Yes,
let's
start
with
the
first
story,
because
that's
what
you
came
here
for
so
this
story
was
my
first
production
service
to
serverless.
I
was
working
in
2016
in
a
company
that
we
were
building
something
like
netflix,
but
for
cartoons
it
was
not
behind
the
subscription.
We
were
monetizing
with
ads
when
you
monetize
with
ads.
A
The
thing
is
that
you
need
to
be
very
conscious
on
how
you're
operating
the
service,
where
the
costs
are
going,
what
caused
everything,
because
every
cent
counts,
and
it
was
the
beginning
of
summer,
and
we
get
a
message
from
our
primary
stakeholders
saying
that
you
know
your
service
is
a
little
bit
too
expensive.
We
need
to
do
something
about
it.
If
not,
then
this
might
get
cancelled.
A
We
freak
out.
We
were
a
very
small
team
of
developers
inside
a
bigger
organization
and
we
freaked
out.
We
love
our
team.
We
love
the
product
that
we
were
building,
so
we
didn't
want
this
to
disappear.
So
the
first
thing
we
did
as
back-end
developers
with
zero
experience
in
the
cloud
and
zero
understanding
on
cloud.
Is
we
try
to
optimize
our
code
as
much
as
we
want?
A
We
did
everything
that
came
to
our
mind
on
optimizing,
the
algorithms,
the
services
you
have
cash
and
what
you
can
imagine
doesn't
work
then
by
that
time
also,
I
was
playing
a
little
bit
with
serverless.
I
have
heard
about
it.
I
already
have
read
about
it.
We
already
had
some
training
provided
by
aws,
because
we
were
quite
a
big
customer
and
I
thought
like
why
we
don't
give
it
a
try.
Serverless
has
this
promise
that
we
don't
need
to
reinvent
the
wheel,
so
we
can
have
a
small
team
to
like
still
have
a
small
team.
A
We
don't
need
to
hire
anybody.
We
can
try
to
reutilize
services
that
are
in
the
cloud.
We
can
build
small
pieces
of
code
that
we
can
glue
all
our
services
together.
So
this
sounds
something
very
good.
So
then
we
started
the
serverless
migration.
We
did
a
lot
of
things
right.
One
of
the
things
that
we
did
right
is
we
built
a
lot
of
prototypes.
We
did
a
lot
of
benchmarking.
A
We
trained
the
team
very
well,
but
the
thing
is
that
we
did
something
very
wrong
and
that
is
when
we
started
the
migration
we
didn't
plan
to
do
it
in
stages.
We
went
all
in.
We
started
coding
and
coding
and
coding
and
months
pass
and
nothing
was
in
production
yet
and
we
started
coding
and
things
were
not
moving.
We
started
to
get
demotivated.
A
Our
stakeholders
were
calling
us
and
hey
when
this
is
going
to
happen,
so
we
did
this
big
rewrite
and
we
finally
migrated
to
serverless.
It
took
us
a
lot
of
pain.
We
did
it
over
many
weeks.
In
some
point
we
decided
okay,
now
we
need
to
go
live
and
we
start
putting
things
in
production.
There
were
a
lot
of
issues
because
there
was
a
lot
of
code
that
we
wrote
like
six
months
ago
that
now
it
was
seeing
the
light.
A
We
have
learned
a
lot
in
our
process
and
we
were
just
really
not
doing
the
right
things
and
also
a
lot
of
the
things
that
we
decided
like
well.
This
will
be
our
observational
also
ability
tools.
This
will
be
our
login.
This
is
how
we
are
going
to
do
alerts
our
dashboard.
These
are
our
metrics.
This
is
our
ci
cd
pipeline.
A
A
So
this
started
more
or
less.
In
the
same
time
that
we
started
in
2016
and
by
that
time
they
have
some
scaling
challenges,
so
they
have
around
350
donations
per
second,
and
you
might
think
well,
it's
not
that
much
it
is.
Donations
are
very
critical.
You
cannot
just
misplace
a
donation,
put
it
twice
or
forget
about
it,
because
you
lose
the
trust
of
your
donators,
so
they're,
very,
very
important,
and
also
when
this
situation
came
the
day
that
they
were
taking
on
the
television.
A
They
have
to
bring
a
lot
of
hardware
and
set
up
all
these
servers
and
set
up
all
this
infrastructure
for
just
one
day.
So
scalability
was
really
a
challenge
for
them
in
2016.
This
was
the
whole
service
system.
They
had,
they
have
a
monolith
with
all
their
content.
They
have
a
service
called
the
giving
pages
and
they
have
a
service
called
the
donate.
Let's
focus
on
the
donate,
because
that's
the
one
that
they
wanted
to
refactor.
That
was
the
critical
one,
the
one
with
the
have
the
scully
scaling
problems.
A
So
now
the
question
is
where
they
will
start
migrating.
We
can
start
with
strategy
one,
let's
start
with
the
least
critical
part
of
our
system.
But
if
we
continue
with
this,
then
when
we
get
to
the
meat
when
we
get
to
getting
the
value
of
our
investment
back
and
then
the
second
strategy
is,
let's
start
with
the
most
critical
part,
let's
start
with
the
night,
and
then
we
can
see,
but
if
we
do
it
like
this,
we
are
just
jumping
into
a
migration
with
no
experience.
So
what
they
did
is
they
mix
both
strategies.
A
They
did
a
couple
of
services
that
were
not
that
critical
first,
they
gained
experience
they
gained
confirms,
and
then
they
went
and
migrated
the
governing
system.
So
they
started
in
2017,
and
this
is
how
their
system
look.
You
can
see
that
the
monoliths
break
a
little
bit.
They
started
some
other
services
here
and
there,
but
then
you
can
see
a
purple
circle
and
that
purple
circle
is
the
first
serverless
component.
It's
a
small
funds,
races
gallery
that
nobody
really
care
much
if
it
work
or
not.
A
So
they
have
all
the
liberty
to
start
playing
with
it
and
learning
about
serverless
and
all
the
new
technologies
in
2018.
They
were
more
confident
and
now
they
took
free
services
that
were
a
little
bit
more
important
into
serverless.
They
also
start
creating
a
shared
component,
so
they
were
not
just
in
this
monolith.
They
start
building
services
outside
and
reutilizing
components
by
2019
they
were
able
to
migrate
their
donate
system
to
serverless,
and
that
is
where
they
stop
or
maybe
now
they
continue
in
2020.
A
A
And
if
you
look,
these
are
the
cost
of
running
the
service
before
the
migration
and
after
the
migration,
and
you
can
see
that
before
the
migration,
putting
all
these
things
together
cost
eighty
four
thousand
dollars
and
after
the
migration
it
was
five
thousand
three
hundred
or
four
hundred.
So
that's
quite
a
saving
and
more
when
you
think
that
the
serverless
part
of
this
infrastructure
costs
only
92
dollars,
so
basically
the
donation
service.
That
is
what
it
brings
all
the
money
is
costing
so
little
so
yeah.
Now
they
have
the
service
available
for
donation
anytime.
A
So
you
can
just
basically
go
any
time
of
the
year
and
donate
if
you
want
so
what
they
did
is
they
use
the
strangler
pattern.
They
have
this
monolith
and
they
start
breaking
up
in
pieces
little
by
little
until
they
either
have
a
very
small
monolith
or
then
they
were
just
left
with
all
the
migrated
components.
A
So
I
will
now
tell
you
five
steps
that
I
think
they
are
critical
for
migrating:
an
application
to
serverless.
The
first
step
is
to
do
your
foundational
work.
I
will
call
this
step
zero,
so
there
are
six
steps
so
things
you
need
to
do
before
getting
started.
Think
about
how
you're
building
your
microservice
use
the
reverse
congoin
maneuver.
For
that
pick,
the
right
tools
pick
your
infrastructures
code.
A
You
will
build
your
ci
cd
pipeline
and
then,
when
you
go
first
time
to
production,
you
will
learn
about
it
and
you
will
tweak
it
and
you
will
make
it
better,
but
it's
very
very
important
to
start
with
these
concepts
from
day
zero,
because
if
you
start
migrating
without
a
cicd
pipeline,
then
you
will
need
to
incorporate
it
later
and
it
will
be
way
more
painful.
The
same
for
monitoring,
observability,
logins,
developer
tools,
big
tools
that
make
you
feel
comfortable,
but
have
a
reason.
A
Don't
pick
20
different
programming
languages
because
it
will
be
very
hard
to
maintain
so
be
very
conscious
on
what
you're
choosing
and
why
and
then
we
start
with
the
migration.
The
first
step
is
to
if
you
have
a
monolith,
this
applies.
If
you
already
have
microservices,
then
you
can
skip
this,
but
the
first
step
is
to
find
the
themes
of
the
code,
and
that
means
finding
where
the
different
bounded
contexts
are
and
start
creating
like
little
folders
directories
modules,
whatever
programming
language
you're
using
and
how
they're
called.
A
Then
you
need
to
organize
the
code
inside
the
monolith
and
also
organize
the
connection
to
the
repository
of
the
monolith,
because
usually
one
monolith
is
connected
to
one
database
and
now
we
will
migrate
it
to
multiple
databases
per
microservices.
So
you
will
need
to
also
start
with
thinking
the
data
structure
of
the
application.
A
So
I
will
tell
you
few
express
tips
to
design
serverless
applications.
The
first
one
is
to
think
about
logical
microservices.
If
you
don't
have
microservices,
you
might
need
to
start
working
with
them.
Logical
microservices
are
just
bonded
context
of
things
that
do
similar
things.
You
will
have
functions
inside
it
and
then
you
will
have
different
managed
services,
cues
databases,
things
that
all
belong
together
and
they
will
deploy
together.
A
Usually
what
you
do
when
you
have
these
logical
microservices,
you
tend
to
build
the
infrastructure
of
the
whole
logical,
microservice
together,
and
you
tend
to
put
the
code
in
the
same
repository
of
the
functions
and
things
tend
to
become
together.
So
then,
when
you
are
thinking,
oh,
I
need
to
solve
a
problem
in
my
orders.
Then
you
know
where
to
go
and
where
to
find
the
errors
and
where
to
start
debugging
them
the
problems,
usually
logical,
microservices,
like
microservices.
A
Then
you
need
to
think
about
event-driven
architectures,
so
need
to
decouple
as
much
as
you
can
your
functions
and
your
service.
These
microservices
need
to
be
decoupled
from
each
other
to
be
able
to
independence,
release,
to
make
scalable
services
to
make
your
easy
code
to
maintain
and
to
work
on
and
to
add
resiliency
to
your
applications
and
then
inside
your
services.
You
also
need
to
decouple
your
functions
one
from
another,
so
they
are
not
talking
to
each
other.
A
You
have
services
like
queues,
pub,
sub
services
and
event
buses
to
rely
on
to
do
this
work
for
you
and
then
you're
wondering
why
I
would
like
to
put
a
router
between
my
microservices,
why?
I
cannot
make
my
microservices
talk
to
each
other.
Well,
that's
a
bad
practice,
because
then,
every
time
you
add
a
new
micro
service,
they
will
need
to
register
to
all
the
other
micro
services.
It's
a
lot
of
coupling
it's
a
lot
of
pain
and
you
don't
need
that.
You
have
a
bent
bust
in
the
middle
event,
router
in
the
middle.
A
That
will
do
all
the
connection,
and
these
in
the
past
were
a
bottleneck
because
you
have
to
scale
them
as
much
as
your
system,
but
in
the
cloud
nowadays,
these
services
scale
very
well.
So
you
don't
need
to
worry
about
them,
then
you
need
to
orchestrate
your
functions
with
workflows.
So
we
talk
about
the
coupling
your
functions,
one
from
another.
You
can
use
skills,
for
example,
if
you
want
to
have
an
event-driven
approach
or
then
you
can
use
things
like
workflows
to
orchestrate
functions
to
complete
one
operation.
At
the
end
again,
we
have
young
queue.
A
The
burning
hmong
saying
that
orchestration
works
inside
about
the
context
inside
a
microservice
and
choreography
works
between
the
microservices
itself.
So
choreography
is
event
driven
thinking
when
messages
are
flowing
using
buses
and
cues
and
pop
stuff.
An
orchestration
is
not
setting
up
workflows
where
one
message
flows
by
another
and
having
like
a
state
machine
that
is
regulating
the
flow
of
the
architecture.
A
Then
we
need
to
think
how
we
can
replace
what
we
have
with
managed
services
instead
of
rewriting
it,
and
that
means
authentication
use
an
authentication
service,
aws
cognito.0,
whatever
you
want
a
database,
don't
install
it
use,
rds
use
dynamo,
use
atlas,
you
need
two
queues,
don't
make
them
yourself,
use
a
q
service.
You
need
kafka,
use
a
managed
kafka.
A
A
We
need
to
think
who
owns
what
and
now
it's
time
to
migrate
to
independent
databases,
and
here
is
the
perfect
moment
to
decide
if
you
are
keeping
your
old
sql
database
or
you
are
choosing
something
that
is
more
optimal
for
your
workload,
something
like
a
nosql
value
database
that
scales
very
well
and
takes
the
load
very
well,
something
that
is
more
appropriate.
Maybe
if
you
are
doing
relationships
and
recommendations
you
might
want
to
have,
I
don't
know
a
graph
database
or
you
want
something
very
fast.
A
You
might
use
leaderboards
and
you
want
something
like
redis
or
you
want
to
just
store
files
and
use
a
file
storage.
Think
about
how
you
can
migrate
your
database
into
this
new
idea.
Usually
sql
databases
don't
scale
very
well.
They
are
not
very
aligned
with
the
serverless
mentality
in
the
scalability
angle
because
of
the
limitations
of
the
database.
So
maybe
just
thinking
about
how
you
can
refactor
this
database
is
a
good
idea.
A
Then
we
need
to
break
the
api.
That
means
that
we
have
these
old
apis
that
were
calling
the
monolith,
and
now
we
need
to
direct
the
traffic
to
the
new
sources,
and
for
that
we
basically
don't
want
the
client
to.
We
don't
need
to
update
all
the
clients
with
the
new
url
so
using
something
like
a
load
balancer
but
change
the
traffic
and
redirect
the
traffic
will
help
us
and,
for
example,
inside
aws.
Our
load
balancers
allow
us
to
direct
traffic
in
with
weights.
A
So
we
can
try
start
with
only
the
reacting
10
of
the
traffic
to
the
new
api.
So
we
can
test.
We
can
monitor.
We
can
become
confident
that
everything
is
working
fine
and
then
we
can
start
moving
more
and
more
traffic
to
the
new
endpoints.
So
that's
something
you
can
achieve
with
application
load
balancer
that
then
your
clients
don't
need
to
update
and
everything
can
migrate
very
seamlessly.
A
So
that's
it
everything
I
want
to
show
you.
I
think
it's
quite
a
short
presentation
when
you
think
is
packed
with
a
lot
of
information
that
then
you
will
need
to
go
and
search
in
your
cloud
provider
or,
if
you're,
using
aws
in
my
youtube
channel
on
how
to
use
all
these
components
to
grow
and
to
create
your
application.
So
to
recap:
do
your
foundational
work
do
a
little
bit
of
analysis
on
what
tools
and
what
services
you
are
using
move
your
monolith
for
the
cloud.
A
So
then,
you
know
which
part
belongs
to
what
then
move
your
code
to
serverless
using
those
designing
tips
and
many
other
tips
of
good
practices
that
you
can
find
around
and
in
different
webinars
break
the
database
and
migrate
it
to
something
else.
If
that's
a
better
solution,
then
break
the
apis
and
move
them
to
the
new
migrated
microservice
with
a
weighted
system
that
you
don't
need
to
move
hundred
percent
of
the
traffic
to
your
new
endpoint
and
then
repeat
until
you're
done,
and
that's
it
very
simple.
A
I
know
migrating
is
a
very
hard
task
and
the
only
way
to
get
it
done
is
starting
by
somewhere
so
plan
your
migration
and
do
a
little
bit
research
on
what
a
good
migration
strategy
is
not
only
going
to
serve
or
less,
but
there
are
many
talks
out
there
on
how
to
really
think
about
a
migration
strategy.
For
example,
in
aws
we
talk
about
the
six
r's
and
and,
and
things
are
more
business
related
to
migration,
and
that
might
also
help
you
to
get
to
the
step
that
this
is
in
the
six
hours.
A
The
refactor
are
the
one
that
you
are
really
trying
to
rewrite
your
application.
Thank
you
very
much
for
listening
me
today.
I'm
very
happy
to
be
here
again.
I'm
marcia
vishala
developer
advocate
for
aws
and
twitter
is
always
open
for
questions
and,
in
my
youtube,
channel
you'll
find
a
lot
of
information
about
this.
Thank
you
have
a
great
day.