►
Description
5 Things Developers Should Know About Serverless - Alan Ho, Apigee
Serverless computing has been the "holy grail" for developers because it lets them just "write code". Serverless is a growing movement that go beyond vendor specific technologies such as AWS Lambda. In this talk, Alan will provide developers and overview of what "Serverless" really means for your organization, and the technologies available to Node.js developers. He will go over serverless options for compute, storage, networking, and show real world examples of Serverless computing from companies like Autodesk.
About Alan Ho
Engineer and Entrepreneur in the field of mobile, e-commerce, cloud computing, and decision management system. At Apigee, he leads developer programs including developer evangelism and training. He also lead product management for Apache Usergrid - the only Apache Backend as a Service (recently graduated to a top level project)
A
All
right
how
many
people
here
and
actually
played
with
serverless?
Oh
okay,
that's
good!
It's
a
lot
better
than
my
previous
talk!
Okay,
my
previous
at
a
conference.
How
many
here
are
developers
from
Austin
Texas?
Oh
great?
How
many
here
are
founders
from
Austin
Texas?
Oh
great,
awesome!
Okay,
we
have
a
few
in
the
crap,
all
right,
yeah
and
just
to
show
of
hands
how
many
people
here
have
used
containers?
A
All
right
just
a
show
of
hands,
because
it's
20
minute
talk
I
just
want
to
give
it
would
you
prefer
to
have
a
cool
demo
or
when
you
hear
like
to
prefer
to
hear
production
deployment
so
like
a
production
employment
such
as
Autodesk
for
a
cool
demo?
Please
urge
at
hand
okay
and
then
for
production
deployment
story.
A
C
B
We
go
alright,
so
my
name
is
Roscoe
kolinsky
I'm
here
helping
out
with
note
school
this
afternoon.
So
are
you?
You
are
learning
interested
in
learning,
node
or
sort
of
honing
your
node
school
on
your
node
skills
drop
by
node
school,
which
is
can
be
just
down
here
at
the
end
of
the
hall
from
one
till
three
and
I'm
here
today,
I'll
be
the
emcee
for
this
room
for
the
rest
of
this
morning.
Session
and
I'm
here
excited
to
introduce
Alan
Howe
from
Google,
which
can
you
talk
about
service,
alright,.
A
So,
there's
a
bit
a
lot
of
talk
about
server.
Let's
say
this
is
a
cool
new
technology.
A
lot
of
vendors
are
pup,
are
pushing
it
really
hard,
but
you
know
the
question
is:
what
does
it
really
mean
to
a
developer
and
isn't
really
any
different,
like
I'm
ready
being
bombarded
with
all
these
container
technologies
do
I
even
should
I
even
bother
about
server
list,
so
is
it
ready
yet
well?
I
just
wanted
to
give
you
like
five
things.
A
You
should
know
about
server
list
and
give
a
more
high-level
overview
about
from
an
architectural
standpoint
how
we're
coming
to
this
to
to
the
server
lists.
So,
just
a
little
bit
about
myself,
I
founded
a
company
in
Austin
Texas
called
in
stops.
It
was
an
API
company
that
did
performance
monitoring,
got
a
choir
by
a
company
called
Apogee
in
San,
Jose
and
just
two
weeks
ago,
got
acquired
by
Google.
So
for
all
those
founders
out
there
keep
on
hustling
for
all
the
startups
in
Austin,
keep
on
hustling.
A
So
what
is
server
list
I'd
like
to
start
with
a
definition
of
server
list,
and
if
you
go
on
the
internet
and
google,
it
I
personally
didn't
find
any
good
definitions
that
suit
my
criteria
and
what
I
believe
server
list
is.
Is
a
code
execution
model
that
the
cloud
provider
abstracts
the
complexity
of
managing
individual
servers
right
and
the
reason
why
I'm
going
to
talk
about
cloud
provider
is
because
server
list
really
is
a
lot
about
money?
It's
not
not
really
about
programming
and
we'll
get
it
we'll
get
to
that
a
little
bit
more.
A
So
what
are
the
attributes
you
shouldn't
have
to
manage
any
servers
right.
So,
even
though
there's
a
even-even
serve
services
like
relational
databases,
a
service
that
amazon
has,
you
still
have
to
manage.
Your
individual
servers
is
still
based
on
servers,
whereas
server
lists.
You
know
you
want
to
use
services
that
don't
make
you
have
to
think
about
servers.
You
shouldn't
have
to
think
about
low
balancing
and
you
should
definitely
be
paying
by
request.
A
Serverless
really
is
the
stack
reimagined
so
and
I'm
gonna
when
I
say
the
stack
reimagined
right.
We've
always
had
this
concept
of
networking,
compute
and
storage,
where,
as
certain
you
know-
and
it's
and
it's
like
many
different
iterations
of
it,
we're
at
so
serverless
you're
networking
a
can't.
Your
communication
is
done
via
an
api
gateway
or
some
sort
of
pub
sub
mechanism.
Your
compute
is
done
by
a
function
as
a
service
and
your
storage
or
your
databases
is
done
by
a
back-end
service.
So
let
me
get
into
each
of
these
components
individually.
A
You're
still
giving
in
a
VM-
and
you
know
the
VM
and
then
the
VM
would
execute
the
code
whereas
function
the
service
you're
providing
code.
So
today
live
you
listen
to
a
lot
of
functions,
service
providers.
They
may
use
containers
underneath
the
hood,
but
there's
no
reason
why,
in
the
future,
when
you
give
a
code,
they
can't
take
your
code
and
then
you
know,
compile
it
down
and
push
it
up.
Push
it
onto
an
FPGA
right.
A
So
I
think
in
the
next
ten
years,
you're
going
to
see
you're
going
to
see
server
lists
that,
under
the
hood
technology
of
server
lists
for
function
of
the
service
evolved
very
differently.
It's
not
going
to
be
running
underneath
the
hood.
It
might
not
be
containers,
it
might
be
something
totally
different.
The
other
thing
I
want
to
talk
about
like
the
gotchas
and
one
of
the
big
gotchas
for
fun.
A
Reading
having
your
cash,
your
in-memory
cache
spill
over
a
disk
that
doesn't
work
anymore,
using
your
own
monitoring,
write
your
own
logging
system
that
doesn't
work
anymore,
you're
kind
of
forced
to
use
whatever
logging
system
they're
built
in.
So
you
really
need
to
rethink
about
how
your
application
operates,
especially
at
the
time
of
Buddha
and
last
but
not
least,
you
pay
by
request.
There's
a
lot
of.
A
Interestingly
enough,
all
the
major
cloud
providers-
I,
don't
have
IBM
over
here,
I
just
heard
of
a
open
whisk,
but
a
lot
of
the
major
product
cloud
providers
have
their
own
functions
and
service
and
they're
all
fairly
similar.
So
what
about
communication?
So
when
we
talk
about
communication,
you're,
not
thinking
about
putting
in
load
balancers,
there's
like
the
because
you
know
underneath
the
hood
you're
not
managing
servers
anymore
and
rather
there's
two
levels
of
abstraction,
which
is
API
gateways
and
pub/sub
mechanisms.
A
So
if
you
have
a,
if
you
have
an
event
that
needs
to
be
a
synchronous
request,
reply
event,
you
definitely
want
to
have
an
API
gateway
in
front
of
it.
You
definitely
wouldn't
want
to
have
use
an
API
gateway.
It's
also
useful.
An
API
gateway
is
also
useful
for
external
events
as
well.
If
it's
a,
if
it's
a
synchronous
event,
then
using
a
pub/sub
mechanism
is
important.
So
talking
a
little
bit
more
about
API
gateway,
why
do
you
want?
A
Why
would
you
need
it
so
things
that
traditionally
would
be
in
your
application
is
now
actually
pushed
up
into
your
API
gateway.
A
good
example
of
this
is
mapping
rest
to
RPC.
So,
if
you
think
about,
if
you
actually
look
at
the
programming
model
from
a
function
of
service,
they
they,
you
need
something
to
actually
map
your
resources.
A
You
know,
map
your
resources
and
the
rest
verbs.
You
know
get
put
post,
etc
to
your
actual
functions
to
your
actual
functions,
and
this
is
probably
better
done
in
in
the
in
the
Gateway
and
there's
other
features
that
you
also
want
to
have
in
the
Gateway
that
you
want
to
take
out
of
your
application
code.
These
are
things
like
ooofff,
you
know
rate
limiting.
You
know
things
of
that
sort,
security,
related
things
and
some
analytics
as
well,
that
you
want
outside
of
your
application
code
and
rather
within
the
Gateway
itself.
A
A
So,
let's
give
an
example:
who's
played
with
Pokemon
okay
know
as
the
many
as
I
thought.
As
I
thought,
so
this
is
a
graph.
It
is
about
a
graph
of
I
think
about
two
months
when
the
Pokemon,
when
Pokemon
Niantic
labs,
said
hey,
we're
gonna
launch
this
game.
They
gave
the
Google
cloud
platform,
team,
original
target
and
a
worst
estimate
and
as
you
can
see,
that
it
was
50x
the
original
launch
target
after
just
two
months,
I
think
they
blew
through
their
worst
case
scenario
in
12
hours,
so
these
systems
are
extremely
high
scale.
A
Okay,
what
are
the
benefits
biggest
benefit
money
because
you're
leveraged
it
you're,
letting
the
cloud
provider
optimize
the
infrastructure
for
you
right
you're,
not
managing
the
servers
yourself.
They
usually
because
they're
optimizing
across
a
lot
of
customers,
they're
able
to
drastically
reduce
their
costs
and
they
usually
push
on
say.
Usually
they
usually
push
on
the
cot
that
cost-savings
down
to
you,
so
you
get
into
you
either
you
can
read
a
lot
of
reports
about
customers
are
using
actually
I.
Think
yesterday.
A
That
was
a
conversation
bye-bye
bustle
talking
about
how
much
money
they
saved
a
lot
of
companies
saved
a
lot
of
money.
The
second
big
benefit
is
there's
I
would
say
no
ops,
but
there's
definitely
less
ops
when
you
have
to
deal
with
function.
The
service,
sorry,
when
you
have
to
deal
with
serverless
biggest
example
of
less
OPS's
managing
Cassandra
clusters
like
because,
if
you
have
like
hundreds
of
micro
services,
you
want
to
have
a
separate
database
for
each
of
those
services,
because
sharing
database
across
micro
services
is
kind
of
an
anti-pattern.
A
A
You
know
simple
programming,
simple
programming
model,
but
with
limitations.
This
is
an
example
of
Autodesk.
They
have
a
production
deployment
using
a
combination
of
Apogee,
ava's,
lambda,
SNS,
ATS,
SNS
and
dynamodb.
You
can
see
here
that
they
put
a
put
a
gateway
in
front
of
a
lot
of
their
services
that
they
believe
that
are
going
to
be
reused
in
the
future.
They
don't
put,
they
don't
put
a
gateway
in
front
of
all
of
them
and
you
can
see
in
order
to
it's
it's
it's
they
would
to.
A
This
previously
would
have
been
just
one
big
monolithic
system
and
they
would
split
up
into
many
many
small
services.
Another
thing
to
note
here
too
is
they
use
a
lot
of
cues
in
between
each
of
the
services,
because
if
they
make
them
all,
you
know
synchronous
requests.
You
know
these
could
take
a
lot
very
long
time
and
actually
driving
the
cost
to,
because
you
remember
these,
for
the
functions
of
service,
your
charge
model
is
usually
by
request
and
how
long
each
request
takes.
A
So,
if
you
have
a
call,
if
you
have
one
request,
that's
calling
a
blocking
call
right
to
another
service
that
doesn't
really
need
to
be
a
blocking
all
you
end
up
paying
money
for
that,
while
it's
blocking
all
right.
So
the
big
question
is
serverless
versus
containers.
I
get
a
question
about
this.
All
the
time
and
I'm
just
kind
of
talk.
I
want
to
talk
to
a
real-world
use
case,
which
is
Autodesk
why
they
have
they
have
both
and
some
of
the
considerations
for
both
is
for
containers.
A
They
had
a
lot
of
workloads
that
needed
to
access
the
filesystem,
Hadoop
kind
of
kind
of
like
Hadoop.
You
know
these
are
big
big
data
kind
of
things,
so
you
know
server
list
wasn't
even
an
option
and
the
other
area
is
because
you
don't
have
actual
access
to
control
of
the
underlying
operating
system
or
even
the
environment.
So,
for
example,
if
you
Zetas
lambda,
you
have
to
choose
your
you.
You
choose
which
node
version
to
use
and
there's
usually
behind.
A
For
the
longest
time,
they've
been
like
on
I,
think
node
that
they've
been
like
one
or
two
versions
behind
LTS,
all
the
time
they're
getting
better,
though
so
you
don't
have
access
to
it.
So
if
you
need,
if
you
have
specific
libraries
or
you
know,
high
performance
computing
requirements
that
needs
oh
s,
level
access-
or
you
know
you
know,
being
able
to
customize
your
node
environment.
You
know
you
just
won't
be
able
to
do
that
with
serverless
all
right,
quick
demo.
How
many
minutes
do
I
have
left?
A
Okay,
great,
so
I
want
to
show
you
a
bot
that
I
created
instead
of
doing
BOTS,
I'm
kind
of
sick
of
slack
BOTS.
You
know
toys,
slack
BOTS,
so
I
decided.
Let's,
why
don't
we
do
a
production
bot,
so
you
can
actually
try.
If
you
have
a
laptop
too
you
can
do.
You
can
actually
try
this
out,
go
to
action,
comm,
slash
developers
and
what
I
was
trying
to.
We
have
a.
We
have
a
bot
on
our
you
know.
A
A
A
A
How
do
I
implement
OAuth
is
like
one
of
the
most
common
questions
that
people
ask
alright.
So
how
did
that
work
so
on
intercom?
This
is
kind
of
our
live
chat,
application
we
created
a
web
hook
and
then
we
basically
select
the
messages
that
we
want.
Events
that
we
want
to
get
notified
on
the
API
gateway.
A
This
is
a
pudgy
edge.
We
selected
we
were
able
to.
We
basically
are
proxying
cloud
functions.
This
is
Google
cloud
functions
and
cloud
functions
is
talking
to
a
called
API,
a
I,
so
API
AI
is
another
recent
Google
acquisition
that
does
natural
language
processing.
So,
for
example,
you
can
you
can
do
things
you
can
put
in
some
example.
Expressions
like
how
do
I
implement
OAuth
and
it
gives
a
reply,
and
this
is
the
code
that
we
that
we
use
to
actually
implement
it.
So
it's
fairly
just
going
quickly
through
it.
A
You
know
we
handle.
This
is
the
event.
This
is
the
function
that
we
export
out
and
that
is
going
to
be
compiled
and
executed
by
Google
Cloud
functions.
It
simply
takes
the
conversation
ID
and
the
canta
and
the
raw
text
from
the
from
the
conversation,
and
it
makes
a
request
to
API
AI
to
get
a
response,
and
you
know
if,
after
it
parses
the
response
and
sends
to
intercom
the
result.
A
A
A
Here
are
the
five
things
you
should
know:
number
one
serverless
isn't
lambda
or
some
vendor
new
technology,
but
it's
rather
the
stack
reimagined,
it's
a
drastically
simpler
programming
model
and
there
are
a
lot
of
gotchas
to
can't
access
the
file
system
limited
access
to
tweaking
your
indexes.
It's
all
about
cost.
A
Yeah,
so
the
question
was,
you
know
when
the
serverless
not
work
for
cost.
What
I,
what
we
typically
see,
especially
for
large
enterprises,
is
that
if
you
have,
if
you
have
like,
if
you
have
a
workload
so
typically,
what
happens
is
that
if
you're
doing
like
this
very
small
project,
it
really
makes
sense
to
use
and
it
doesn't
have
a
lot
of
traffic.
A
It
makes
sense
to
use
server
list
because
you
don't
even
know
whether
or
not
it's
going
to
be
popular
or
not
so
just
just
that
that
itself
becomes
very,
it's
very,
very
cost
effective.
But
if
you
have
a
system
that
you
know
is,
has
some
ridiculously
high
performance
requirement
and
then
you
have
the
ability
to
optimize
the
code
even
at
that
maybe
the
operating
system
level
right
then
it
doesn't
make
sense
to
you
server
lists
because
you
know
you're
getting
massive
utilization
out
of
your
servers
underneath
the
hood.
A
D
A
So
that's
the
kind
of
nice
thing
as
server
list
that
you
can
actually
for
AWS.
There's
a
can't
remember
there
there
are
local.
Actually
there
are
local
testing.
You
can
run
the
functions
locally
on
your
own
laptop
and
then
you
upload
it
actually
I
didn't
show
you
how
what
it's
like
to?
Actually,
you
know,
load
a
function,
so
this
is
so.
This
is,
if
you
look
at
the
this,
is
basically
the
command
to
upload
a
a
function.
A
So
I
would
usually
do
all
my
testing
locally
on
my
own
host
and
I
would
just
run
this
g-cloud
command
and
it
would
just
package
up
the
function
and
deploy
it
on
the
cloud.
The
good
thing,
too,
is
that
you
know
kind
of
the
model
for
server
list.
Is
you
write
individual
functions
and
then
you
upload
it?
So
you
it's
much
more
iterative.
You,
you
kind
of
deploy
one
function
at
a
time.
E
C
E
A
That's
that's
actually
good
I
mean,
like
you
know.
What
I'm
trying
to
get
here
is
server
list
isn't
about
function
as
a
service
server
list
is
a
stack
right,
so
I
would
consider
firebase
as
a
back-end
as
a
service
for
serverless
right.
So
I
mentioned
firebase
as
a
back-end,
a
service
to
use
right.
You
want
to
think
about.
That's
why
I'm
trying
to
get
the
biggest
point
of
the
talk
is
that
it
is
the
stack
reimagine.
So
I
like
using
cloud
functions
with
with
firebase,
would
totally
make
sense.
A
There
isn't
a
official
standardization.
The
question
is:
is
there
a
standardization
effort
going
on
and
the
answer
is
no,
but
one
sort
of
if
you
want
to
choose
different
clouds,
actually
I
really
recommend
checking
out
the
serverless
framework.
There's
an
open
source
server
list
framework
out
there
and
I'm,
not
hundred
percent
sure
if
they
bit
their
beta
they're
in
development
or
their
beta
in
the
Google
Cloud
functions,
so
that
actually,
that
framework
is
actually
going
to
be
working
across
multiple
clouds.
But
the
good
thing
is
honestly:
I've
actually
done
both
actually
before
this.