►
From YouTube: Convergence of Serverless APIs & Compute - Sarah Allen, Google (Intermediate Skill Level)
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Convergence of Serverless APIs & Compute - Sarah Allen, Google (Intermediate Skill Level)
Serverless has different meanings to different communities — serverless APIs allow developers to build apps that don’t have servers, whether they be Web or native mobile using cloud APIs or serverless compute that offers ways for developers to build zero-ops distributed systems. This isn’t one word with two divergent meanings, but different approaches that are converging. Sarah will share real-world production use cases that illustrate how developers are using these technologies together.
About Sarah
Sarah Allen created early web platforms that were serverless before the term was coined — on the original Shockwave team, she created ways for developers to create apps when the web was young. Later, she did server-ful platforms like Flash video and open source developer tools, at OpenLaszlo and 18F. For the past year, she has worked at the intersection of Firebase and Google Cloud Platform, leading teams developing serverless events for Cloud Functions and an open source cloud policy language. Additional information: www.ultrasaurus.com/about -- more complete bio & prior speaking experience.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Okay,
I
think
we're
on
thanks
for
hanging
in
here
end
of
the
day
on
Friday,
we've
heard
a
lot
about
serverless
over
the
last
few
days,
mostly
about
functions
as
a
service
that
there's
a
lot
of
excitement
around
functions
and
I'm.
Certainly
super
excited
about
functions,
but
today
I'm
going
to
fold
in
another
important
piece
of
the
puzzle,
which
is
around
serverless
api's,
which
combined
with
serverless
compute,
allow
developers
to
keep
pace
with
a
very
fast
changing
business,
world
and
technical
landscape.
A
In
this
talk,
I'm
going
to
dive
into
some
real-world
use
cases
that
highlight
patterns
that
I've
been
seeing
with
serverless
and
what
works
and
doesn't
work
so
well.
First,
what's
serviced,
it
spent
a
bunch
of
time
with
the
CNCs
service
working
group,
where
we
talked
a
lot
about
this
term.
That
has
now
become
a
bit
of
a
buzzword,
and
it
really
boils
down
to
a
few
things,
which
is.
A
This
is
just
your
code.
You
can
focus
on
building
deploying
running
your
application
without
provisioning
servers
without
worrying
about
VMs
and
it
scales
up
according
to
traffic
and
scales
back
down
again
when
you
don't
need
it,
and
you
only
pay
for
what
you
use
when
people
talk
about
serverless
around
here.
Mostly
we're
talking
about
service
compute
lambda
was
released
in
2014
IBM,
which
you
just
heard
about
at
least
open
wisk
as
open
source
software
in
2016
and
later
the
hosted
version
of
IBM
cloud
functions.
A
We've
got
your
functions
and
Google
Cloud
functions,
I
think
Google
App
Engine
also
meets
the
definition
of
server
lists.
It
was
launched
in
2008
I.
Think
before
service
was
a
term
it
Auto
scales
up
as
you
need
it
and
scales
back
down
to
zero
when
you're,
not
using
it.
This
early
service
contender
enabled
the
spectacular
launch
of
Pokemon
go
and
also
powers
snapchat
today,
but
what's
driving
all
this
serverless
excitement,
I
would
argue
that
it's
the
growth
of
api's.
A
This
is
a
chart
of
the
growth
of
business
values
delivered
through
api's,
which
the
programmable
web
has
been
tracking,
since
2006
developers
today
just
expect
that
they
can
connect
to
data
enrichment
services
with
thousands
of
lookups,
often
just
costing
pennies
and
there's
a
wide
array
of
transactional
api's
that
you
can
use
for
payment
and
e-commerce.
Pretty
much
anything
you
want
to
do.
That
has
been
done
a
lot
of
times.
You
can
find
an
API
and
just
pay
for
usage.
A
A
These
just
say
that,
since
you
may
not
know
recognize
all
the
logos
on
the
chart,
you're
familiar
with
them
when
you
come
across
them
in
the
top
row,
there's
Google,
Cloud,
storage
and
Amazon
s3,
which
are
you
know,
kind
of
the
the
original
serverless
API
is
where
you
can
upload
an
incredible
amount
of
data
and
download
files.
And/Or
blobs
and
it
scales
a
core
magically
in
the
background
and
the
cloud
providers
do
all
the
work
to
manage
large
amounts
of
infrastructure.
A
Then
there's
pub/sub
and
publish/subscribe,
google
cloud
pubs,
pubs,
pub/sub
and
amazon
SNS,
which
allow
you
to
often
stitch
these
things
together.
So
you
can
publish
a
message
on
a
topic
and
receive
it,
and
somebody
else
can
receive
it
often
a
different
part
of
your
infrastructure.
Your
service
application,
also
featured
in
this
talk,
are
cloud
datastore,
which
is
a
beloved,
no
sequel
datastore,
which
allows
you
to
build
an
application
where
the
performance
of
that
application
scales
with
the
size
of
the
results
set,
not
the
amount
of
data,
that's
in
the
system.
A
The
next
generation
of
this
is
Google
Cloud
Fire
Store,
which
combines
with
the
firebase
SDK
to
allow
real-time
data
updates
to
the
client
and
has
the
same
properties
of
cloud
datastore,
and
then
we've
got
Google
bigquery,
which
is
used
for
data,
big
data
analytics
and
Google
Cloud
vision,
which
is
one
of
the
many
Google
cloud
machine,
learning,
api's
and
then
there's
a
number
of
other
API
is
there's
stripe,
which
is
used
for
payment.
The
magnito
API,
which
is
used
for
e-commerce
and
lucky
seat,
which
is
used
to
pick
winners
and
a
lottery.
A
So
the
first
pattern,
the
most
common
one
in
terms
of
usage
of
functions
in
terms
of
the
number
of
functions
executed,
our
data
pipelines
or
the
extract
transform
load
pattern.
So
typically,
a
log
file
will
be
uploaded
to
an
s3
or
Google
Cloud
Storage
bucket.
That
will
trigger
a
function
which
does
some
processing
and
then
stores
the
results
in
a
database.
Often
these
are
long
pipelines
that
do
many
things
that
call
machine
learning,
api's
or
api's
to
find
out
more
data
and
or
validate
the
data
that's
being
sent
through
then.
A
The
next
most
common
use
case
is
notifications.
So
in
classically
you
would
need
to
stand
up
a
server
and
pull
for
changes.
If
you
want
to
see
that
something
changed
in
a
particular
query
now,
instead,
you
can
just
listen
for
that
change
and
have
a
function
triggered.
Of
course
it
doesn't
have
to
be
a
data
storage
query.
It
could
be
any
API
where
that
a
state
change.
Maybe
it's
done
doing
a
time
intensive
task.
Maybe
it
notices
something
different
in
the
world
that
triggers
a
function
computer
compared
with
traditional
API
construction.
A
Of
course,
you
can
also
just
do
notifications
by
email,
SMS
text,
or
what
have
you
very
closely
related
to
notifications
or
real-time
updates,
illustrated
here
is
firestore,
which
does
a
lot
of
the
heavy
lifting
for
you,
combined
with
the
firebase
SDK,
so
that
you
can
listen
for
events
on
the
on
the
client
and
write
a
serverless
app.
That
just
runs
in
your
browser,
your
mobile
app
and
reflects
changes
to
the
user.
A
The
next
pattern
is
content
management,
so
this
is
probably
the
most
commonly
used
example,
where
of
the
makes
thumbnail
or
you
upload
a
big
image,
and
that
triggers
a
function
which
then
resizes
the
image
and
stores
a
small
version
of
it.
In
a
database,
then
client
access
is
something
that
I
don't
hear
talked
about,
but
I
see
used
incredibly
frequently,
so
there's
a
number
of
different
serverless
authentication
system.
A
A
One
pattern.
That
kind
of
surprised
me
to
see
so
frequently
is
live
data
migration,
although
once
I
started
hearing
about
it.
Of
course
it's
it's
a
great
use
of
serverless.
So
in
this
case
you
have,
of
course,
your
your
data
source
or
my
drum
migrating
from
needs
to
support
events.
But
during
your
migration
you
can
have
no
downtime,
because
a
right
to
the
data
store
triggers
a
function.
A
Then
you
write
to
the
new
place
and
then
and
that's
my
list
of
six
common
serverless
patterns
and
what
I'm
going
to
do
next
is
dive
into
for
use
cases
from
a
wide
range
of
domains
using
different
technologies.
Where
you
can
see
these
patterns
at
work,
the
first
one
is
Hawkins
dynamics,
so
these
are
Hawkins
dynamics.
Is
a
sports
science
company
focused
on
providing
cutting-edge
hardware
and
software
systems
for
measuring
and
assessing
athletic
performance
and
potential?
So
these
are
these
force
plates.
A
Are
these
big
plates
on
the
ground
right
and
you're
an
athlete,
and
you
put
one
foot
on
each
plate,
you
jump
and
when
you
land
it
detects
the
force
of
your
landing
and
it.
It
then
conveys
all
of
that
to
give
you
visibility
into
how
you
were
jumping
and
your
athletic
performance
or
to
your
coach
so
I'll
dive
into
how
this
works.
So
these
force
plates
are
connected
wirelessly
to
an
android
app
and
they
send
the
data
to
the
android
app
and
then
the
android,
and
that
that's
great
because
it
works
offline.
A
You
don't
have
to
be
connected
to
the
wider
Internet
and
the
the
force
plates
and
the
Android
app
a
lot
work
together
and
then,
when
the
Android
app
is
online,
it
authenticates
to
fire
store
with
firebase
off
and
then
sends
data
to
fire
store.
And
then
the
coach,
no
matter
where
they
are
in
the
world,
can
view
the
athletic
performance
of
that's
happening
right
now
in
real
time
or
over
time.
A
And
the
athlete
or
their
coach
can
view
the
performance
data,
and
this
is
an
exactly
an
incredible
example
of
serverless
at
work,
and
it
was
only
when
I
dug
into
this
particular
case,
store,
study
and
was
talking
to
the
developer.
That
I
learned
that
they
had
a
live
migration
that
they
had
done
using
Google
Cloud
functions
as
well,
so
they
previously
had
been
on
the
firebase,
real-time
database
and
so
what
they
did
when
they
wanted
to
migrate
to
a
fire
store.
A
And
it's
really
a
nice
use
of
service.
The
second
case
study
very
different
domain.
The
Hamilton
musical
is
very
popular
in
the
United
States,
so
this
is
a
musical
about
US
history
and
they
built
a
mobile
app
for
the
musical
and
a
mobile
app
that's
for
musical
is
is
not
the
product
right.
The
product
is
the
musical,
so
the
mobile
app
really
needs
to
be
delivered
at
relatively
low
cost
and
be
operated
by
non-technical
folks,
whose
primary
job
is
they're,
not
mobile.
Apps.
A
A
So
when,
when
this
was
in
San,
Francisco
like
a
hundred
thousand,
people
would
enter
this
lottery
every
day
and
my
friend
entered
the
lottery
every
day.
For
four
months,
and
then
we
actually
we're
able
to
see
Hamilton
three
days
before
it
closed.
It
was
amazing,
so
think
you
can
imagine.
This
is
a
lot
of
spikey
traffic,
perfect
use
case
for
serverless.
So
how
does
that
work
exactly
so?
The
mobile
app
authenticates
with
firebase
authentication?
A
That
also
saves
the
profile
data
to
the
real-time
database,
and
then
people
can
sign
up
for
the
lottery
I
think
after
4
p.m.
the
previous
day
or
something
and
then
on
a
timer
every
on
a
cron
job
with
App
Engine,
cron
I
think
every
morning
at
9
a.m.
they
call
out
to
lucky
seat,
which
is
an
API
specifically
built
to
fairly
randomize
the
winning
ticket
and
then
the
real-time
database
that
that
winning
ticket
has
written
to
the
real-time
database,
which
notifies
the
client
the
second
use
case.
A
The
second
part
of
the
app
is
really
a
content
management
system
until
I
ran
my
own
mobile
development
company
several
years
ago.
I
never
realized
that
major
TV
shows
and
theater
productions
usually
have
their
own
mobile
app.
It's
it's
a
thing.
So
the
app
needs
a
way
for
the
operator
on
the
backend
to
provide
content,
and
typically
this
is
somebody
in
the
entertainment
industry,
who's
fairly
technical,
but
not
a
programmer.
A
So
so
the
admin
web
app
allows
for
uploading
images
to
Google,
Cloud
storage
and
then
that
triggers
a
function
which
which
then
can
size
the
images
for
all
the
different
mobile
devices.
Right
then
back
to
Google,
Cloud
storage
also
write
metadata
to
the
real
time
database
and
that
sync
to
the
app
pretty
straightforward
and
then
the
last
use
case
is
merchandising,
so
they
so
it's
typical
for
a
mobile
developer.
A
So
the
person
comes
to
the
website
and
for
their
e-commerce
visit
through
the
Google
tag
manager,
which
embeds
the
firestore
SDK.
It
writes
information
about
the
visit
to
fire
store
and
that
triggers
a
couple
of
data
pipelines.
So,
first,
a
google
cloud
function
triggered
off
the
right
stores
the
data
in
bigquery.
That's
then
available
to
the
recommendation
engine
to
query.
Another
Google
cloud
function
uses
the
vision
API,
and
this
is
really
interesting.
A
What
they
found
was
that,
because
they
served
so
many
different
languages,
the
metadata
that
was
taxed
about
the
product
wasn't
that
reliable
to
find
good
product
info.
So
they
actually
may
use
the
image
of
the
product
to
analyze
its
metadata
about
the
product
and
feed
that
into
that
recommendation
engine,
and
then
they
can
do
real-time
notifications
to
the
client
for
anonymous
users
and
then
for
registered
users.
They
can
periodically
send
email.
A
So
this
is
the
whole
picture
together
and
this
architecture
made
it
easier
to
make
changes
which
allowed
them
to
easily
set
up
a
be
testing
which
significantly
increased
the
quality
of
their
recommendations
and
their
revenue.
So
with
serverless
guesswork
bootstrapped
their
company
grew
a
business
that
now
serves
a
hundred
million
users
with
just
three
developers.
A
So
this
is
the
semi
o
Skateway
standing
in
the
orchard,
and
they
you
can't
see
in
the
trees.
There
are
devices
hanging
in
the
trees
which
collect
data
and
send
them
to
the
Gateway
and
there's
also
ways
that
the
Gateway
can
communicate
back
and
control.
The
pest
population
or
control
irrigation
and
then
the
Gateway
talks
to
the
cloud
in
this
case
periodically
the
Gateway
uploads
its
logs
of
IOT
data
and
images
to
s3
and
then
as
three
when
it
gets.
A
New
data
triggers
and
SNS
sends
a
message
on
an
SNS
topic
which
hops
over
to
Google
cloud
and
adds
a
message
to
a
pub
sub
topic
which
triggers
a
cloud
function
which
then
writes
to
cloud
datastore.
Then
elastic
Beanstalk
runs
their
traditional
web
app
and
gets
the
data
of
cloud
datastore
and
presents
the
data
to
the
farmer
who
runs
the
orchard.
Who
can
then
act
on
that
data?
It
was
surprising
to
me
how
some
developers
so
easily
mix
and
match
services
across
clouds.
A
A
Some
people
are
saying
that
serverless
is
zero.
Ops,
but
I
feel
a
little
conflicted
about
that.
It
certainly
reduces
your
officers
burden.
We
don't
have
to
manage
servers
and
VMs
anymore
and
that's
great,
but
even
if
you're
not
manning
servers,
you
still
have
a
kind
of
ops.
You
have
to
make
sure
your
app
works
and
I've
been
hearing.
People
talk
about
this
as
app
ops,
I,
don't
know
if
that
words
gonna
stick.
But
how
do
you
know
your
apps
working
in
production?
What
are
you
doing
it
fails?
You
still
have
to
worry
about
these
things.
A
One
of
the
key
challenges
is
observability.
You
need
to
pay
attention
to
when
your
services
services
are
failing
and
with
server
lists.
You
typically
have
many
small
functions
connected
via
events.
An
end
user
might
observe
a
failure.
Many
hops
away
from
the
root
cause
when
we
build
apps
with
server
lists,
we're
actually
building
a
distributed
system,
and
those
of
you
who've
built
infrastructure
who
are
coming
from
a
world
of
this
is
easier
because
I'm
not
managing
my
whole
cluster
you're,
familiar
with
what
you
might
need
to
do
to
hook
this
up.
A
We
also
have
a
lot
of
application
developers
that
are
coming
from
client-side
development,
where
this
is
a
whole
new
world
and
I
think
as
service
providers.
We
all
have
to
think
about.
How
do
we
give
people
these
tools
just
make
this
easier,
but
to
some
degree
it's
about
what
your
app
does.
What
are
the
signals
that
you
need
to
make
sure
your
app
works?
So
we
need
to
be
thoughtful
about
logging,
setting
up,
monitoring
and
alerting
and
doesn't
come
for
free.
A
Then
what
happens
when
something
goes
wrong?
You
have
to
debug
it
things
are
different.
When
your
VM
is.
There
has
a
problem
in
scales
down
to
zero.
You
have
to
debug
it
differently.
You,
you
can't
use
the
same
tricks
that
maybe
you
did
when
you
when
you
just
ran
VM
as
yourself
you
with
with
every
service
platform
right
now.
You
have
to
do
a
a
bit
of
experimentation
to
get
your
work
flow
down.
A
There's
a
lot
of
activity
in
this
space
and
I
expect
things
will
get
better,
but
it's--but
Wild,
West
right
now
and
then
security
security
is
different,
sort
of
with
a
cloud
native
micro
services
architecture.
Your
security
boundary
is
going
to
be
a
bit
different.
You
need
to
be
thoughtful
about
key
management,
but
remember
the
exact
same
security
issues
we've
always
had
you
still
have
so
serverless
does
reduce
your
ops
version
but
doesn't
go
opps
burden.
It
doesn't
go
away,
you're
still
responsible
for
making
sure
your
app
works.
A
So
sometimes
servers
can
be
nice,
like
serverless,
isn't
for
all
things.
If
you
have
a
long
live
job,
if
you
have
sustained
throughput,
sometimes
it's
cheaper
and
easier
to
just
manage
your
Vin's.
If
you
already
have
an
ops
team,
maybe
you
know
that's
fine.
Vms
can
be
nice,
so
in
summary,
there's
a
lot
of
patterns
that
are
emerging.
That
I
think
are
really
exciting
that
we're
starting
to
see
how
these
things
fit
together
and
what
service
is
really
good.
For
what
we're
seeing
over
and
over
again
is
that
serverless
enables
developer
velocity
and
flexibility.
A
The
key
value
that
I've,
seen
over
and
over
again
is
delivering
business
value
with
fast
time
to
market
with
server
lists.
Even
though
right
now
it
might
be
a
little
painful,
delivering
business
value
three
months
early
because
you
didn't
have
to
build
the
infrastructure
you
would
normally
build,
can
make
a
dramatic
difference
in
the
solution
that
you're
providing
and
can
make
a
big
change
to
your
business.
So
now,
I'd
like
to
open
the
floor
for
some
questions.
A
A
The
question
was
about
firebase
real-time
database
versus
cloud
fire
story,
so
firebase
real-time
database
is
the
original
firebase
product.
That's
vertically
scalable
it
scales
really
high,
but
there's
a
limit
and
but
it's
very,
very
good
for
incredibly
high
throughput
low
latency
interactions.
So,
if
you're
doing
like
a
shared
whiteboard
for
our
base
real
time
database
is
for
you
cloud
firestore
has
global
scale
and
has
all
the
properties
of
cloud
datastore,
and
so
it's
the
logical
successor,
while
also
not
handling
some
key
use
cases
of
the
real-time
database,
so
they're
they've
each
got
their
niche.
A
A
A
You
know
what
was
a
system
out
of
RAM.
You
know
it's
this
getting
hot
and
CPU,
and
now
we're
seeing
people
looking
at
business,
metrics
and
really
thinking
about
like
is
this
working
right
is:
is
my
app
still
delivering
value
because
my
my
machines
could
be
running
fine,
but
they
no
longer
functions
in
the
way
that
it
intended
to
so
I
think
that
type
of
application
monitoring
we're
going
to
see
much
more
sophistication
around.
A
Well,
I
think
that
all
the
different,
proud
cloud
cloud
providers
have
limits
to
how
long
their
functions
run
and
and
I
know.
That's
that's
a
pain
point
for
some
folks
and
I.
Think
that
will
you
know
we'll
sort
of
see
how
that
plays
out
in
the
industry
in
terms
of
you
know,
does
it
must
like
must
H?
Must
it
be
a
short-lived
job
for
it
to
live
in
the
serverless
world
like
in
reality.
A
A
So
yeah,
the
question
was
why
why
are
our
users
using
one
cloud
provider
over
another?
Why
use
Google
cloud
functions
or
AWS
lambda,
and
you
know
and
there's
some
feature
differences,
but
primarily
what
I'm
seeing
is
that?
Well,
there's
some
folks
that
some
of
the
big
companies
want
to
have
multiple
cloud
providers
for
redundancy,
but
most
commonly
there's
a
particular
product
that
they
love
on
one
cloud
provider
and
another
product
that
they
love
on
a
different
cloud
provider
and
they
just
use
those
two
things.
Just
the
way
like
well,
I
might
use
stripe
for
payments.
A
You
know
like
that
doesn't
mean
that
I'm
like
unloyal
to
Google
cloud
platform,
then
that
they're
not
seeing
the
platform's
as
I
must
use
all
of
these
things
in
one
category
and
some
of
the
things
like
a
lot
of
a
lot
of
the
C
reasons
we
see.
People
using
Google
cloud
is
because
of
the
wide
array
of
ml
options,
and
so
people
will
use
functions
along
with
the
set
of
products
that
are
vented
that
they
really
like.