►
Description
State of Serverless [B] - Mark Peek, VMware & Doug Davis, IBM
Serverless and FaaS computing is gaining in popularity to easily create microservice applications. In this talk we will discuss what are the characteristics of serverless, the status of the serverless working group within the CNCF, and the open source options available for running serverless and associated services with a focus on kubernetes.
About Doug Davis
Doug works in IBM's Open Source and Standards division. He's been working on Cloud related technologies for many years and has worked on many of the most popular OSS projects, including OpenStack, CloudFoundry, Docker and Kubernetes.
About Mark Peek
Mark is a Principal Engineer at VMware working across areas of interest such as cloud management, cloud native applications, and open source. Currently he is leading the work on serverless within VMware. Mark contributes to a wide range of open source projects and is the VMware representative for the Cloud Foundry TAB, CNCF and OCI.
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
So
I'm
mark
peek
principal
engineer
with
VMware
and
my
co-presenter
is
I'm
Doug
Davis
from
IBM
and
we're
gonna
be
going
over
the
state
of
server
lists.
So
before
we
start,
let's
get
some
hands
going
up.
How
many
people
know
what
serverless
is
all
right?
How
many
people
know
what
functions
as
a
services
all
right?
How
many
people
know
the
difference
between
those
two?
A
Ok,
ok,
so
what
we're
going
to
do
is
talk
a
little
bit
about
you
know.
What
is
the
rule
is
why,
when
the
users
accept
our
use
cases
and
then
we'll
drop
in
to
Doug's
gonna
go
over
some
of
the
CN
CF
serverless
working
group.
Talk
about
that
and
some
of
the
some
of
the
futures
that
we're
gonna
be
doing
on
that
working
group.
A
So
before
we
start
in
on
server
list
itself,
let's
first
talk
about
functions
as
a
service.
You
know
one
of
the
things
that
we've
seen
is
the
progression
of
compute.
You
know
started
with
bare
metal
servers
went
to
virtual
machines.
Obviously
you
know
me
coming
from
VMware.
That
was
important
thing.
A
In
fact,
I
think
it's
pretty
funny
that
you
know
IBM
and
VMware
talking
about
server
list,
but
I
digress,
and
so
you
know
as
we
as
we
move
from
virtual
machines,
public
cloud
and
then
containers
took
us
by
storm
a
couple
of
years
ago,
and
you
know
it's
a
wonderful
thing,
but
as
people
have
looked
at
how
they
want
to
write
their
programs,
how
they
want
to
consume
compute
they've
thought
you
know.
I
really
just
want
to
focus
on
my
business
logic.
A
I
want
to
write
my
function
and
I
just
wanted
to
execute,
and
so
that's
one
of
the
reasons
that
functions
as
a
service
is
really
interesting
to
people.
Just
you
know
be
able
to
write
the
code
submit
it.
The
infrastructure
is
already
there.
You
have
wonderfully
fast
startup
times.
When
you
look
at
density
packing
you
can,
you
can
pack
more
functions
in
into
the
same
amount
of
compute
and
in
be
able
to
schedule
across
a
lot
of
different
nodes.
A
That
way,
the
other
part
of
it
is
that
as
you're
looking
at
functions
of
the
services
way
to
break
up
your
monolith,
you
can
now
write
those
functions.
Be
able
to
have
things
that
are
very
directed
for
the
API
usage
that
you
need,
so
you
know
going
along
those.
You
know
what
is
it
that
that
we
want
to
see
in
this
function?
Well,
it's
event-driven.
What
we
want
is
a
event
coming
in
some
way
to
have
an
action
occur
that
will
run
this
function.
It
will
run
this
function.
A
It
made
you
some
some
back-end
work
and
may
send
a
Senate
event
back
out,
but
you
know
it
definitely
will
will
do
some
work
there,
but
it's
also
very
short
duration.
The
the
current
cloud
providers
very
fast
execution
times,
I
think
right
now.
Aws
is
around
five
minutes,
but
you
know
it's
not
intended
for
long-running
workloads.
A
You
might
be
better
off
using
containers
or
vm's
instances
for
for
those
types
of
things,
but
as
as
we
see
some
of
the
the
open
source
projects
coming
along
I
definitely
could
see
that
as
being
one
of
the
areas
where
they
can
provide
additional
value.
Is
you
can
choose
your
own
duration?
You
can
increase
that
and
be
able
to
control
your
own
destiny
there.
A
It's
definitely
stateless.
They
you
you
just
yeah,
all
it
is
doing
is
providing
the
compute.
You
don't
want
to
use
any
storage
associated
with
that
a
function
runtime
you
will
rely
on
external
services
in
order
to
store
the
state
out
into
back-end
services
or
another
way
of
storing
state
is
sending
another
event
back
out
to
be.
You
know,
additional
functions
or
the
trigger
other
other
events
to
happen.
A
I'd
also
say
that
one
of
the
key
areas
is
auto
scaling,
because
what
you
want
is,
as
these
events
are
coming
in,
the
infrastructure
will
respond
to
that
workload
coming
in
and
will
then
auto-scale
out
the
number
of
functions
that
you
need
in
order
to
handle
the
ingest
of
those
events
into
the
infrastructure,
and
then
you
know,
public
cloud
is
talking
a
lot
about
the
lower
cost,
which
is
you're
only
having
to
pay
for
what
you
use
when
the
function
runs.
You
can
get
time
billed
to
that.
That's
that's
your
bill,
so
you
don't.
A
You
know
this.
This
kind
of
dovetails
into
more
of
the
service
thing,
but
it's
it's
definitely
a
a
cost
savings
associated
with
public
cloud
only
having
to
pay
for
what's
actually
running.
So
what
is
what
does
this
function?
Look
like
here's,
a
very
simple
example
of
a
function.
It's
a
JavaScript
has
parameters
coming
in,
that's
it's
being
triggered
by
an
event.
Let's
just
say
that
it's
an
HTTP
event
there,
there's
parameters
associated
with
that
call.
One
of
them
is
a
name.
We
look
at
the
name
and
we
say
alright,
hello,
world
or
hello
name.
A
If
there's
a
name
associated
with
it
very
simple.
The
the
JSON
payload
is
sent
back
out
as
a
response,
so
when
you're
looking
at
how
functions
can
work
for
just
redoing
your
api's?
This
is
a
very
good
simple
example
of
that,
and
you
know
it
really
is
this
concept
of
being
able
to
control
the
actions
running
through
your
infrastructure
and
being
able
to
chain
together
those
functions.
A
So
what
does
this
look
like?
Overall?
Is
you
have
the
event
sources
coming
in
from
a
variety
of
different
areas?
You
know
it
could
be.
Computers
could
be
web
browsers,
IOT
phones,
you
know
all
kinds
of
different
devices
will
be
contacting
into
your
infrastructure
actions
occur.
You
know
a
lot
of
people
who
will
say
actions
triggers
events,
but
it's
all
somewhat
the
same
thing.
It
will
then
go
into
the
function
executor
in
scheduler.
A
More
than
likely,
as
you
look
at
this,
it's
it
will
use
back-end
services
so
things
like
event,
buses,
blob
stores,
other
databases
in
order
to
I.
Either
query
information
store
information,
but
it
isn't.
It
doesn't
necessarily
need
those
back-end
services.
It
can
be
just
stand
alone.
Do
some
compute
send
the
answer
back
out
as
an
event,
but
it
is
this
ecosystem
that
we're
seeing
one
way
to
think
about
that
is
that
as
you're
developing
your
overall
cloud
native
application,
you
need
to
look
at
these
components
as
design
patterns
that
you
use.
A
So
now
we're
gonna
take
a
step
back
to
service.
You
know
the
stock
was
about
the
state
of
service,
so
I
talked
about
functions
as
a
service,
and
now
what
is
the
real
distinction?
There
I'd
say
that
this
is
coming
more
from
a
public
cloud
point
of
view
where
functions
as
a
service
is
how
you
actually
run
the
functions,
how
you
execute
them,
etc.
Serverless,
on
the
other
hand,
is
the
thought
that
I
can
just
hand
this
function
off
to
some
infrastructure.
Someone
else
is
maintaining
it.
A
Someone
else
is
operating,
it
I,
don't
have
to
care
about
it,
and
so
they
will
figure
out
how
to
auto
scale
it
for
you.
They
will
say
you
know
if
it's
not
running,
it
doesn't
cost
you
anything
and
I
and
I
think
that's
a
very
important
point
about
this,
but
it's
also
in
the
eye
of
the
the
persona.
So
you
know
1%
the
developer
persona.
It's
always
going
to
be
server
list
to
them
to
the
IT
ops.
You
know
they
might
be
providing
it
functions
as
a
service
infrastructure,
so
Amazon,
Google,
etc.
Public
cloud
vendors.
A
They
have
their
function,
services,
they're,
providing
functions
as
a
service.
We
use
it
as
service.
So
that's
another
way
to
think
about
that
distinction
between
between
those
two
and
then
as
we
as
we
look
at
all
of
these.
You
know
as
a
service,
we
have
functions
of
service
platform
as
a
service
container
as
a
service,
and
it
all
starts
in.
You
know.
Doug
and
I
were
talking
about
this
and
it's
all
starting
to
blend
together,
which
is
it.
A
There
are
subtle
distinctions
between
all
of
these
different
services,
and
it's
really,
you
know
how
do
you
what's?
What's
the
smallest
amount
of
code
that
it's
executing
that
needs
in
order
to
run
and
how
you
interact
with
it?
But
but
I
do
see
that
there
is
this
blurring
of
lines
where
you
say
well,
the
and
I've
had
this
conversation
with
a
lot
of
people.
A
They
say
well
function
as
a
service,
isn't
how
the
paths
you
know,
because
I
just
kind
of
submit
my
code
to
it,
etc
and
I'd
say
yes,
but
there's
probably
a
finer
granularity
on
the
function
that
you're
actually
submitting
to
it.
There's
differences
in
terms
of
how
it
gets
auto
scaled.
You
know
a
path,
may
not
do
the
auto
scaling
for
you.
You
might
have
to
have
more
manual
steps
in
order
to
bring
more
the
number
of
instances
up
autumn.
It
isn't
done
automatically
for
you.
So
there
there's
very
subtle
distinctions
there.
A
Another
distinction
that
I
want
to
make
is
that
you
can
decompose
functions
apart
from
your
application,
so
a
lot
of
times
you'll
create
your
application.
You'll
have
your
your
gets.
Your
puts
different
different
routes,
all
in
the
same
set
of
code
and
with
function
as
a
service,
you
more
than
likely
will
be
decoupling.
Those
creating
individual
functions
for
each
of
each
of
each
of
those
routes.
Each
of
those
endpoints,
in
which
case
then
there
is
a
distinction
there,
where
I
can
now
upgrade
or
modify
a
endpoint
independent
of
having
to
redeploy
the
entire
application.
A
So
it's
I'd
say
that's
another
area
to
look
at
as
to
you
know,
different
viewing,
serverless
paths
and
some
of
the
the
platform
as
a
service
and
container
as
a
service
so
going
over.
Some
of
the
you
know
these.
This
is
just
a
sample
of
some
of
the
use
cases
that
I've
seen
for
using
using
server
lists
or
functions
as
a
service.
You
know
obviously
I
talked
a
lot
about.
You
know:
how
do
you
decompose
for
micro
services
being
able
to
have
API?
Is
there?
Iot
is
a?
A
Is
a
great
use
case
where
you
have
devices
that
may
be
calling
in
you
can't
predict
when
that
load
is
going
to
happen,
so
you
really
want
the
infrastructure
to
how
to
scale
that
for
you
and
you
can
have
very
discrete
functions
to
handle,
handle
those
inputs
batch
and
stream
processing.
This
is
more
of
a
using
functions
to
orchestrate
the
data
being
that's
flowing
between
all
of
your
batch
and
stream
processing,
and
then
there
there's
obviously
DevOps
your
CI
CD
pipelines.
A
You
can
have
triggers
fire,
IT,
ops,
I,
can
imagine
being
able
to
see,
see
issues
occurring
and
be
able
to
be
able
to
now
say
all
right.
If
I
see
this
alert
I
wanted
to
send
the
slack
message
to
this
channel.
If
I
see
this
other
alert,
you
know
maybe
I'm
going
to
call
out
to
Pedro
duty
and
start
waking
some
people
up.
A
Let
me
also
touch
on
a
couple
of
use
cases
that
I've
seen
this
is.
This
is
more
of
an
AWS
use
case,
but
I
think
it's
pertinent,
which
is
theirs.
It
was
reinvent
in
2016.
Coca-Cola
was
talking
about
their
infrastructure,
where,
when
you
swipe
your
credit
card
to
a
Coke
machine
that
would
trigger
a
lambda
function,
that
would
then
do
the
the
charge
onto
onto
your
credit
card.
So
they
you
they
are
only
paying
for
compute
when
you
actually
are
paying
for
a
coke
and
I.
A
Think
that
that's
a
that's
a
really
good
point
about
why
you
would
want
to
use
service
in
in
some
of
your
products.
But
I
will
also
say
that
if
you
go
back
and
look
at
that
video,
they
also
talked
about
that.
There's
a
break-even
point
where
if
they
have
a
low
number
of
transactions,
it
makes
sense
to
have
that
as
using
lambda.
But
as
the
number
of
transactions
increases,
it
actually
makes
more
sense
to
move
over
to
dedicated
instances.
So
you
really
have
to
you
have
to
look
at
your
use.
A
A
There
was
a
talk
from
Nordstrom
about
they
have
a
it's:
an
in
github,
fully
open
source,
hello,
retail
site,
that's
written
all
in
lambda,
but
of
course,
if
you,
if
you
dig
deeper
into
that,
if
the
functions
are
written
there,
but
they're
using
a
ton
of
back-end
services
and
I,
think
that
that's
where
you
have
to
look
at
again
your
overall
costing
model,
what
does
it
cost
to
run?
The
functions
is
one
thing:
how
much
is
are
the
associated
services
to
store
the
state
to
do
the
vending
everything
else?
B
B
It
is
still
a
relatively
new
technology,
and
back
in
2000,
2000
empty
back
in
June
of
2017
is
the
technical
oversight
committing
the
CNC
F
decided
no
there's
newer
technologies
out
there,
let's
figure
out
what,
if
anything,
CNC
I
should
do
about
this
space,
and
so
obviously
the
first
step
in
that
process
is
to
find
out
exactly.
You
know
what
is
serverless
what's
going
on
the
community
today
and
then
see,
if
there's
anything,
we
want
to
do
in
that
space.
So
they
basically
said:
okay,
let's
start
up
a
working
group
and
explore
these
various
things.
B
B
But
there
were
a
couple
of
maybe
contentious
points
in
there,
and
some
of
these
are
things
that
mark
sort
of
touched
on
when
he
was
summarizing
this
stuff,
and
one
of
them
was
actually
zero
cost
one
idle
and
for
those
of
you
who
understand
the
ways
things
like
criminais
days
or
docker,
actually
works
right.
It's
very
hard
to
actually
get
the
scale
of
your
application
down
to
zero.
So
it's
actually
zero
cost.
If
you're
not
using
it
right.
B
The
infrastructure
is
enzymes,
work
that
way
and
a
lot
of
these
cases
you
can
go
down
to
one
and
then
it
can
scale
up
as
needed,
but
to
go
beyond
is
one
down
to
zero.
So
you
actually
get
real
zero
cost,
that's
a
bit
of
a
problem
for
some
infrastructures,
and
so
when
we
just
tried
to
draw
a
firm
line
in
the
sand,
that
said
absolute
zero
cost.
B
This
is
supposed
to
be
about
you
hand,
your
function
will
host
it,
and
you
have
to
worry
about
anything
else
and
that's
great,
if
you're
in
a
public
cloud,
but
in
a
private
cloud,
well,
obviously
you're
not
giving
the
infrastructure
off
to
someone
else
outside
the
company
to
manage
it,
you're,
giving
up
maybe
to
someone
else
inside
your
company
like
an
IT
shop,
and
so
there
was
a
bit
of
a
contentious
point
there,
because
some
people
said
well.
You
can't
have
server
lists
in
private
cloud.
B
B
We
said,
okay,
you
need
to
look
at
this
problem
from
two
different
perspectives:
there's
the
provider
who's,
providing
you,
the
infrastructure,
the
functions
of
service
infrastructure
versus
the
developer,
who
just
wants
to
hand
over
their
code,
and
once
you
look
at
it
from
that
perspective,
you,
then
you
can
say:
okay,
then
it
does
make
sense
right.
Maybe
I
can
then
do
this
in
private
cloud,
because
my
IT
shop
will
be
the
ones
who
absorb
the
cost,
but
from
the
developer
perspective
they
don't
have
to
worry
about
the
cost
anymore.
B
They
don't
worry
about
hosting
it
and
managing
and
stuff
like
that.
So
you
can't
do
this
split
within
your
organization
and
still
get
service,
but
it's
only
service
from
the
developers
perspective,
not
from
the
IT
shop
or
providers
perspective,
and
so
that
then
led
to
this
notion
of
well
there's
server
list
versus
service
technology.
Right
server
lists
is
what
the
developer
sees.
B
Tribulus
technology
is
what
the
provider
or
the
IT
shop
is
going
to
manage,
and
that's
so
weird
how
we
sort
of
dance
that
fine
line
to
nots
really
upset
some
people
who
didn't
want
to
be
not
labeled
service,
even
though
they
didn't
ously
fit
into
some
other
people's
perceived
definition
of
service.
But
once
you
get
past
the
definition
of
what
his
functions,
what
his
service
as
I
said
most
of
it,
went
fairly
smoothly.
B
So
we
highlighted
all
the
things
basically
mark
talked
about
it
in
his
part
of
the
presentation
right,
the
use
cases
areas
where,
as
proven
value,
how
do
you
differentiate
server
list
from
paths
from
containers
as
a
service
or
even
VMs?
All
those
things
are
just
talked
about
there
and
we
also
went
into
a
little
bit
of
detail
of
how
service
works
from
a
technology
perspective
under
the
covers.
Now
we
didn't,
for
example,
take
lambda
or
open
web
screen
like
that
and
say
here's
how
this
does
it?
B
Rather,
we
sort
of
looked
at
at
an
abstract
sense
and
said
what
are
the
general
things
you'll
see
in
the
infrastructure
of
a
function
of
the
service
or
service
infrastructure?
Just
so
as
you're
looking
through
these
various
options
out,
there
you're
not
surprised
by
some
of
the
terms
or
some
of
the
concepts
that
are
presented
and
finally,
in
the
white
paper
we
then
talked
about
well.
What
should
the
CNC
F
do
going
forward
with
service?
B
I'll
talk
a
little
bit
more
about
that
in
a
sec
all
right,
so
the
other
output
that
we
had,
though,
aside
from
the
white
paper,
was
basically
a
spreadsheet
of
what
is
the
service
landscape
right?
What
are
the
cloud
provider
service
offerings
or
the
open
source
projects
out
there?
What
are
the
development
tools
that
are
available
for
server
lists
or
functions,
and
what
kind
of
back-end
services
are
people
making
use
of
today?
Now
this
isn't
meant
to
be
things
that
are
approved
or
you
know,
get
a
gold
star.
You
know
that
we
like
or
dislike.
B
This
is
just
what's
out
there
today.
So
if
there's
something
missing
from
the
spreadsheet
that
you'd
like
to
get
added,
it's
a
Google
Doc
right
now,
just
make
it
as
a
comment.
It'll
get
added
we're
not
there
to
draw
a
bar
or
a
line
in
the
sand
to
disallow
anybody
all
right.
This
is
just
so.
People
can
go
to
once
particular
place
and
say:
oh
what's
out
there
today,
so
they
can
go
play
with
it
all
right
now
to
the
recommendations
itself.
B
Obviously
we
need
to
maintain
that
spreadsheet,
going
forward,
as
I
just
said,
so
feel
free
to
suggest
edits
there,
but
going
forward.
We
want
to
try
to
enable
developer,
Interop
and
portability,
and
in
order
to
do
that,
you
need
to
make
sure
that
you
can
move
your
function
from
one
platform
to
the
next
now
they're
different,
many
different
aspects
around
portability
of
the
functions
and
so
rather
than
trying
to
boil
the
ocean
all
at
once,
we
decided
well,
let's
focus
first
on
events.
B
Can
we
get
a
say,
a
harmonized
or
grade
a
pond
or
interoperable
format
for
these
events
right?
That
might
make
it
a
little
bit
easier
for
you
to
make
your
functions
portable,
not
hundred
percent
portable,
but
a
step
in
the
right
direction.
Now
the
other
one
we
talked
about
was
things
like
the
the
function.
Definition
right
the
packaging
of
it,
how
you
actually
deploy
it.
That's
all
goodness
to
that,
hopefully,
will
be
the
complete
picture
for
moving
your
functions
around
but
event,
and
then
format
was
sort
of
the
first
one.
B
We
decided
we're
going
to
tackle.
I'll
talk
a
little
bit
more
about
that
in
a
sec
and
then,
finally,
any
additional
documentation.
We
could
think
of
going
forward
right
are
there
there
is.
There
are
the
documents
we
could
put
forward
to
help
people
understand
more
about
the
community
more.
What's
going
on
in
this
space,
the
integration
with
other
CNCs
projects-
just
you
know
things
just
to
help
out
the
community
going
forward.
Those
are
things
are
going
to
look
at
producing
in
the
future.
So
let's
talk
a
little
bit
more
about
events.
B
As
I
said,
it's
basically
looking
at
trying
to
see
if
we
can
find
a
common
sort
of
envelope
for
these
events
that
come
into
the
system.
Now
we're
not
going
to
necessarily
look
to
mandate.
All
events,
for
example,
must
be
an
adjacent
format
or
stuff
like
that
right
because
that's
going
to
be
difficult,
but
we
have
a
lot
of
existing
systems.
B
That
is
we're,
gonna
be
looking
for
and
you
this
is
actually
very
similar
to
what
we
see
happening
with
CNI
and
CSI
other
projects
within
the
CN
CF
foundation
and
moving
to
get
that
harmonization
kind
of
add
perspective,
and
it's
important
to
note
that
events
isn't
actually
just
for
functions
or
service.
We
actually
do
see
events
flowing
into
all
types
of
applications,
so
we're
hoping
this
will
actually
get
leveraged
by
those
other
use
cases
as
well,
not
just
functions.
B
You
know
what
are
we
going
to
do
and
we
kind
of
landed
on
this
open
event
specification
that
was
originally
started
off
by
I'm
Austin
from
serverless
Inc,
who
took
the
initiative
to
go
out
there
and
talk
to
a
whole
bunch
of
different
companies
to
try
to
see
if
there's
some
commonality
that
he
can
actually
formalize
in
document
form,
and
you
came
up
with
open
events.
We
thought.
Okay,
that's
a
good
starting
point.
B
So
that's
we're
going
to
start
with
now,
that's
not
to
say
that
we're
not
going
to
look
at,
for
example,
CAD
F
from
CN
CF
or
the
cloud
native
event,
mapping
document
and
use
those
as
inputs,
but
in
terms
of
a
starting
point
we
have
to
start
someplace
I'm,
we're
gonna
start
with
open
events.
Now
this
is
open
to
everybody.
So
if
you
are
interested
in
looking
at
some
of
this
harmonization
or
inability
around
events,
please
come
join
us.
It
is
an
open
working
group
to
everybody.
B
You
don't
have
to
be
a
member
of
the
CNC
F
to
join
in
the
fun
and
we're
welcome
you
to
join
us.
So
here
are
just
some
important
links
for
you,
links
to
the
working
group
itself.
We
do
have
weekly
calls
right
now
at
8:00
a.m.
Pacific
time
links
to
the
white
paper
and
that
landscape
googledoc,
if
you're,
interested
and
I
believe
that's
basically
it's
now.
So
thank
you,
but
we
do
have
other
service
tracks
in
this
very
room
right
after
he
reads
want
to
summarize
what
they
are.
B
So
you
know
if
you're
interested
sort
of,
obviously
please
stick
around
for
those
other
tracks
and
with
that
I
believe
we
have
about
ten
minutes
for
questions
and
people
have
any,
of
course,
the
pay
I
believe
the
PDF
is
available.
Fehb
remark:
you
uploaded
it.
Yes,
the
PDF
is
available
from
our
little
thing
on
the
shed
or
sched
whatever
it's
say,.
B
A
B
Yeah
so
I'll
take
a
little
bit
of
that,
so
yeah
yeah,
oh
yeah.
So
we
closed
you
couldn't
yet
the
question
is:
is
there
a
performance
impact
basically
dealing
with
these
small
little
bits
of
functions
as
opposed
to
entire
application
and
then
spinning
them
up
and
down,
for
example,
going
down
I
assumed
going
out
like
zero
instances?
You
know
the
cost
of
spending
up.
That
very
first
instance
could
be
a
lot
right
and
I
think
that
is
a
problem
and
I
depending
on
the
infrastructure.
They
deal
with
it
different
ways.
B
Right,
for
example,
some
of
the
cloud
providers
will
allow
you
to
set
up
basically
like
a
ping
that
will
ping
your
your
functionary
down,
then
services.
So
we
always
have
at
least
one
running
or
at
least
for
a
period
of
time
and
then
maybe
after
30
minutes
to
an
hour.
Even
that
will
drop
down
to
zero.
So
then
there
will
be
a
performance
hit
for
that
first,
one
to
come
back
up,
but
at
least
for
that
third
30
minutes
or
so
you
shouldn't
get
a
performance
set.
B
There
are
other
infrastructures
that
try
to
deal
with
that
a
different
way.
For
example,
open
wisk
will
actually
pause
your
container
so
that
the
startup
time
is
very,
very
fast.
It's
not
starting
from
cold
boot
in
essence
right
and
that's
how
they
address
it.
So
their
last
different
ways
that
people
are
trying
to
work
on
that
issue,
and
it's
so,
but
it
is
definitely
something
to
think
about
anything
that
was.
A
Good
you
want
to
switch
back
to
the
schedule
there
we
go
yeah,
so
in
case
you
were
expecting
a
demo
from
us.
We
weren't
going
to
give
the
demo,
but
if
you
do
want
to
see
it
functions
as
a
service
in
the
action
there's
quite
a
few
projects
up
here
that
are
open
source,
the
will
I'm
sure
be
giving
some
really
good
demos.
C
So
you
talked
a
lot
about
the
orchestration
and
how
you're
trying
to
get
the
definition
I
think
for
the
events
and
stuff
like
that
coming
the
function.
Are
you
guys
involved
with
other
groups,
I'm
thinking
like
metrics
tracing
and
all
that
work
that
could
come
into
place
and
have
an
impact
on?
Yes,.
B
A
B
We're
trying
to
get
people
like
open,
metrics
involved
in
the
working
group
as
well
yeah.
So
if
there's
something
or
there's
somebody
you're
aware
of
that,
we're
not
talking
to.
As
you
look
at
the
working
group
thing,
please
let
us
know,
because
we
want
to
reach
out
to
as
many
people
as
possible.
Yes,.
D
So
I
wanted
to
dig
a
little
bit
more
into
this
kind
of
startup
issue
because
it,
it
seems
to
me
like
there's,
there's
two
possibilities:
either
one
you're
you're
coming
from
totally
cold
start
and
you
need
to
spin
up,
and
that
has
to
take
at
least
a
few
hundred
milliseconds
right
or
you're
already
running,
in
which
case
what
is
the
advantage
of
service
at
all,
because
you're
not
really
service
if
it
was
already
running?
So
how
can
you?
How
can
you
ever
win
life.
A
B
A
B
So
so
so
to
me,
I
had
the
I
dissimilar
question
right
when
I
first
came
across
serve
list.
I
thought
of
service
versus
has
very
very
similar
right.
You
give
all
your
code
they'll
manage
it
for
you,
that's
great,
but
look
at
this.
The
first
second
bullet
the
first
indented
bullet
there.
When
someone
started
talking
about
scaling
your
guests
as
a
post,
your
entire
application-
that
was
the
killer,
app
or
killer
scenario.
To
me,
that
said,
that's
cool
right,
because
I
can
now
scale
up
a
get
which
is
relatively
lightweight.
B
Talk
to
a
back-end
system
returned
data
very
quickly.
I
could
scale
that
out
to
a
million,
but
only
have
maybe
a
hundred
instances
of
update
right
that
to
me
means
I
can
scale
that
up
faster
and
have
more
those
than
my
entire
application
scale.
So
it's
all
about
better
resource
utilization,
but
at
a
very,
very
high
level.
Conceptually
I
do
tend
to
agree
with
you
that.
E
B
Not
aware
anything
specific
for
service
a
mark,
you
know,
but
I
would
assume
that
in
most
cases
we're
dealing
with
containers
here,
they're
running
the
functions
anyway.
So,
as
is
tio,
you
know
you
can
is
tio
eyes
if
that's
a
phrase,
your
function
container
the
exact
same
way
because
to
the
infrastructure,
it's
still
just
a
container,
so
you
can
put
that
side
car
in
there
to
get
the
is
tio
benefits
realize
whether
it's
a
function
or
a
full-fledged
application.
I
can't
imagine
that
be
any
different.
I'd.
A
Say
inside
of
the
public
lip
I'd
say
with
respect
to
the
public
cloud,
you
know
they.
Definitely
they
have.
You
know
I
am
for
AWS
being
able
to
provide
some
level
of
authentication
etc,
but
on
open
source
projects.
I
haven't
quite
seen
that
yet,
but
I
think
that
that's
going
to
be,
you
know
kind
of
the
next
wave
of
things
and
I
know
of
some
projects
that
are
looking
at.
How
do
you
do
better,
multi-tenancy
and
and
other
security
across
the
across
your
entire
fast
implementation?
F
G
Some
always
curious
how
technologies
develop
and
where
they
come
from.
Was
this
somebody
working
on
a
path
that
said
you
know,
there's
a
certain
use
case
that
I
want
to
fine-tune
it
and,
as
they
got
going
said
wow
this
is
actually
something
we
can
cleave
off
and
create
as
a
separate
model
of
compute.
Or
is
it
somebody's
PhD
paper
that
they
then
thought
well,
there's
a
real-world
application
and
brought
it
back
I.
A
The
earliest
instance
of
using
server
lists,
I,
think
came
from
iron.I
Oh
quite
some
years
ago,
and
I
think
that
they
were
seeing
just
going
from
a
pass
to
Kaz
to
you
know,
just
being
able
to
submit
a
function
and
that's
the
only
history
that
I've
been
able
to
dig
out
of
that
yeah
and
and
then
obviously,
AWS
came
out
with
lambda.
That
is
doing
something
similar.
F
Yeah
when
we
think
about
cost
savings
of
serverless
elegance,
it's
great,
we
think
about
infrastructure,
but
the
real
benefit
that
I've
seen
or
her
talked
about
is
really
the
benefit
to
the
development
workflow
and
how
that's
optimized
and
the
biggest
cost
of
any
application
in
my
expertise
is
actually
the
time
to
build
these
things.
And
so,
if
you
can
optimize
that,
that's
that's
really
great.
B
You
want
to
take
that
one
worker
does
me
to
me:
it's
all
just
containers
right
and
so
that
I
would
assume
all
the
same
tooling
for
logging
and
tracing
still
apply
here
in
the
same
way.
I
would
hope,
and
that
most
of
the
differences
here
is
the
the
mecha,
the
tooling
you
use
to
actually
either
develop
your
application
or
function
and
the
tools
to
deploy
it.
But
beyond
that,
once
you
can
in
the
infrastructure
level,
I
would
hope
most
of
it
should
be
fairly
common.
In
my.
A
Opinion
I
think
that
kind
of
greenfield
opportunities
right
now
to
have
things
that
make
it
easier
to
debug
to
to
actually
step
through
the
code
to
understand
what
the
failure
modes
could
be
even
unit
testing.
Those
functions
which
are
written
assuming
certain
infrastructure
I
think
is
challenging
as
well.
So
definitely
I'd
like
to
see
people
think
about
that
and
come
up
with
good
good
opportunities
for
that.
I
think.
H
E
H
H
Is
you
think
of
service
as
functions
plus
kind
of
this
not
worrying
about
the
server,
because
I
would
think
of
service
as
kind
of
more
general
than
just
functions
like
you
know,
if
you
look
at
like
a
CI
or
far
gate,
that's
kind
of
like
a
server
list
container
product
you'll
get
App
Engine,
it's
kind
of
service
source
to
deployment
system,
so
I
was
just
curious
on
your
view
of
whether
you
think
of
server
list
as
purely
a
function
system
with
that
server
like
server
list
property
or
you
think
of
server
lists.
More
generally,.
A
My
answer
to
that
is
that
server
list
could
be
things
other
than
functions
as
a
service,
because
really,
when
you're
looking
at
it,
it's
a
it's
more
of
the
managed
service
back-end
as
a
service.
Any
of
the
services
that
you're
using
along
with
functions
as
a
service
or
could
be
considered
service
and
I-
think
that
if
you
take
kind
of
this
definition
of
it,
where
you're
not
having
to
pay
money
for
when
it's
idle
looks,
or
that
is
that
it
encompasses
all
of
those
types
of
opportunities.
I.
I
One
more
I
was
I
was
just
gonna
amplify.
One
thing
on
the
surrealist
part:
serverless
means
not
having
to
provision
or
think
about
your
instances.
So
in
the
sense
of
you
know,
host
a
database
like
the
Google
spanner
could
be
thought
of
the
server
list
if
you're
not
having
to
provision
specific,
spanner
instances
and
it
just
scales
when
you
need
it.
I'm.
B
Running
to,
though,
is
that
we
talk
about
service
as
strictly
at
that
abstract
level.
Then
you
get
back
to
the
question.
The
gentleman
over
there
asses
will
stare
and
say
that
in
pass,
is
it
really
just
scaled
down
to
zero,
or
is
it
more
than
that
and
that's
where
it
gets
a
little
fuzzy
true
about
path
could
be
service
I
agree,
but
it
depends
your
perspective.
No
get.
You
know
those
are
fighting
words
to
some
people,
so
alright,
great.