►
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Cloudstate—Towards Stateful Serverless - Jonas Bonér & James Roper, Lightbend
The Serverless experience is revolutionary and will grow to dominate the future of Cloud. FaaS however—with its ephemeral, stateless, and short-lived functions—is only the 1st step. It's great for processing-intensive, parallelizable workloads, but limited in use-cases, making it hard to impl general-purpose apps. What’s needed is a next-gen Serverless platform for general-purpose app dev for our new world of real-time data & event-driven systems. What’s missing is: ways to manage distributed state in a scalable & available fashion, long-lived stateful services, ways to co-locate data & processing, and options for data consistency. This talk will discuss challenges, requirements, and introduce you to our proposed solution: CloudState—an OSS project building next-gen Stateful Serverless on Akka, gRPC, Kubernetes & GraalVM, with client support for Go, JavaScript, Java, Swift and more.
https://sched.co/Zeln
A
Let's
see
so
I
just
want
to
start
by
saying
that
you
know
a
lot
of
people
talk
about
serverless
and
as
the
same
thing
as
function
as
a
service
and
but
but
for
me,
that's
not
really
true,
I
think.
Certainly
I
think
function
as
a
service.
Fast,
in
short,
is
a
really
good
first
step
was.
It
was
really
groundbreaking
when
it
when
it
came
about,
and
it's
really
been
shown
in
the
way
showing
what's
possible,
but
it's
only
the
first
step
on
a
long
journey
towards
this.
You
know
nirvana
this.
A
This
amazing
cloud
experience
that
we
all
hope
to
to
get
to
one
day
for
me,
so
serverless
is
really
all
about
an
experience,
an
experience
for
developer
for
operations
for
deployment.
That
is
completely
new.
You
know
you
know
in
order
the
one
that
sort
of
removes
as
much
as
possible
from
the
essence
and
moving
it
away
to
the
runtime
to
the
back
end.
A
So
you
as
a
developer,
we
as
developers,
can
focus
on
only
the
essence
you
know
and
what
I
would
you
know
what
I
would
like
in
in
my
sort
of
vision,
grand
vision
for
the
for
the
future
of
the
cloud.
I
would
like
to
build
this
or
build
any
type
of
application,
build
for
general
purpose,
application,
full
applications
in
this
new
experience,
functions
and
services.
A
Tackling
is
currently
sort
of
tackling
one
subset
of
the
use
cases
in
a
non-travel
application,
sometimes
a
large
portion,
sometimes
a
small
portion,
but
it's
just
really
hard
hard
to
tackle.
You
know
everything
that
we
need
in
a
non-trivial
re
real
world
application
in
just
function
as
a
service,
so
we
need
something
more.
A
So
the
question
is,
then:
what
is
the
missing
piece?
What
is
missing
here
and
you
know,
I
believe
that
it's
state
it's
it's.
You
know
it's
good
ways
of
working
with
state
solid
models
for
abstracting
overstate
to
essentially,
you
know
having
good
ways
of
of
of
abstracting
over
states,
so
the
runtime
can
manage
it
for
us
effectively.
A
You
know,
and
so
are
some
of
the
technical
re
requirements
that
I
see
that
we
need
in
such
a
sort
of
new
way
of
writing.
Any
type
of
application
in
this
new
experience
is
first
support
for
stateful
long-lived
addressable
components,
components
that
that
can
be
virtual
as
well.
It
means
that
we
have
stable
references
stable
addresses,
but
they
can
still
they
can
still
move
move
around,
maintaining
their
daily
integrity
in
their
state,
while
the
address
remains
stable.
A
A
For
broadcast,
and
and
for
things
like,
like
modeling
orchestration
of
of
workflows,
you
you
using
things
like
sagas
process
managers,
etc.
We
also
need
you
know,
options
for
managing
distributed,
state
reliably
at
scale.
You
know,
and
and
not
just
having
one
size
fits
all,
not
saying
that
everything
needs
to
be
strongly
consistent
or
everything
is
eventually
consistent.
But,
having
you,
you
know,
options
ranging
from
strong
to
eventual
through
causal
consistency,
so
you
can
fit
fit
serve
the
the
weakest
model
that
gives
the
that
gets
the
job
done.
A
You
know,
because
if
you
add
layers
of
safety
or
guarantees
on
top
that
you
actually
don't
need,
that's
wasteful,
you
know,
so
you
actually
want
the
minimum
guarantees
that
gets
the
job
done.
That
liberates
the
runtime
to
do
even
more
things
in
terms
of
scale
and
availability.
Okay,
we
also
want
intelligent
adaptive
placement
of
of
stateful
functions.
Things
like
sharding
having
a
physical
co-location
of
state
and
processing
as
well
as
sticky
routing.
A
A
It
just
is
it
sort
of
ends
up
on
your
mailbox
or
on
your
queue
to
your
function
and
and
passed
into
your
into
you
for
processing
and
the
same
thing
message
out
you
only
you
own
the
immediate
sort
of
event,
and
you
know
you
don't
need
to
worry
about
how
it
work
will
end
up
who's
going
to
pick
it
up
et
cetera
and
the
mechanics
for
doing
so.
They
have
well-defined
interfaces
for
messaging
and
message
out
or
eventing
an
event.
A
If
the
function
manages
state,
it's
himself,
the
function
can't
sort
of
see
in
and
understand.
What's
called,
what's
what's
really
going
going
on
here
and
it's
it's
a
it's
a
factor,
sort
of
unconstrained
database
access,
which
sounds
like
a
good
thing.
I
mean
more
power
is
good
right,
but
it's
actually
not
always
the
case,
because
it
makes
it
really
hard
for
the
runtime
to
automate
operations
on
behalf
of
the
function.
A
So
so
it's
really
hard
to
understand.
Sort
of
the
intention
of
each
axis,
for
example,
is
the
operation
to
read
or
is
it
right?
Can
it
be
cached?
Can
consistency
be
relaxed
or
or
a
strong
consistency
always
needed?
You
know,
can
operations
proceed
during
partitions
and
failures,
etc?
Right
it's.
If
unders,
if
the
runtime
understands
these
things,
you
can
make
intelligent
sort
of
decisions
more
effectively
and
also
you
know,
see
broadly
across
all
of
your
entities
and
making
and
making
things
you
know
collectively.
A
A
You
know
and,
as
I
said
in
the
functional
service
is
really
good
of
abstracting
over
communication,
so
you
have
messaging
and
a
message
out.
As
we
just
talked
about
the
question
is
then
the
question
we
asked
ourselves
at
lachman
was:
is
it
possible
to
abstract
over
state
in
the
same
way
that
functions
to
service
abstracts
over
communication?
A
So,
instead
of
just
messaging
a
message
out,
you
also
have
statement
and
state
doused.
So
it's
sort
of
an
inversion
of
control
here
in
instead
of
the
function
manages
himself.
The
state
gets
passed
to
him
and
he
can
just
emit
state
and
all
the
boys
or
all
the
sort
of
hard
things
around,
managing
that
how
how
of
the
state
is
handled
in
the
back
end
is
so
delegated
now
to
the
runtime
in
a
true
serverless
fashion.
A
You
know
the
the
problem
is
that
that
crud
doesn't
always
fit
this
model,
but
we
need
new
models
and
new
ways
of
thinking
about
the
state
now
I'll
get
to
that
just
in
a
second
so
that
that
so
that's
what
sort
of
the
the
the
premise
when
we
start
a
cloud
state
trying
to
answer
the
question:
can
we
abstract
our
state
in
this
way
and
can
we
provide
you
know
a
stateful
addition
to
function
as
a
service?
That's
great
for
a
state,
less
workloads,
you
know
so
so
the
joint
thing
gives
us
it.
A
So
what
is
cloud
state
you?
Can
you
can
you?
Can
you
can
find
out
more
after
this
talk
if
you
go
to
cloud
state
or
io,
but
the
overview
is
that
you
know.
First,
is
open
source
full,
fully
apache
youtube
it's
available
in
github.
You
can
just
go
to
go
check
it
out
and
mess
around
with
the
code
and
contribute.
A
Ideally,
if
you
like,
the
sort
that
deserves
short
one
sentence
is
really
that
is
distributed.
State
management
for
the
cloud
in
a
serverless
experience,
as
I
talked
about
it,
and
and
it's
really
it's
really
two
things.
First
is
a
reference
implementation,
but
it's
also
standards
or
a
protocol
and
a
specification.
A
A
A
You
know
between
the
back
end
and
the
client
I'll
get
to
that
just
in
a
second
it
leverages
in
canadian
kubernetes
and
also
runs
on
gravity
and
which
allows
us
to
compile
it
down
to
nate.
You
know:
suzaku
runs
on
the
jvm,
it's
very
important
to
minimize
the
the
the
memory
overhead
and
the
startup
times,
and
growl
vm
really
helps
us
with
that.
So
it's
really
polyglot
and
here's.
Here's
where
we
sort
of
leverage
grpc
the
grpc
sits
right
in
between
you
know,
is
the
protocol.
A
How
how
how
clients
sort
of
make
make
make
use
of
this
of
these.
This
sort
of
distributed
state
management
and
essentially
any
any
language
that
has
supports
for
grpc,
can
can
be
supported
by
cloud
state
because
you
know,
essentially,
all
these
clients
are
grpc
clients
and
we
currently
have
support
for
javascript.
Typescript
java
go
dark,
python.net,
rust,
swift
and
scala.
Not
all
are
them
are
complete,
but
a
lot
of
them
are
being
worked
by
the
community
as
we
speak.
A
So
it's
really
exciting
to
see
the
community
pick
these
up
and
serve
and
and
sort
of
cracking
these
these,
these
client
libraries
out
it
all
supports.
Like
policy.
You
know,
as
I
said
you
know,
crud
is
not
always
the
best
and
best
you
know
answer
to
to
the
to
sort
of
the
serverless
state
serverless
story,
but
you
know
other
models
that
I
think
fits
better.
Is
that
that
that
we
support
nine
clustered
it's
event
sourcing.
A
I
won't
want
to
talk
to
go
through
what
that
is
really
and
how
it
works,
but
the
best
sourcing
is
really
really
cool.
Cr
dt
is
like
is
essentially
conflict-free
replicated
data
types.
It
allows
you
to
share
state
freely
of
the
cluster
without
worrying
about
you,
know,
race
conditions
and
and
inconsistent
data.
It's
eventually
consistent
while
event
sourcing
is
strongly
consistent,
so
it
gives
you
two
models
for
that.
We
also
have
key
value
stored
and
it
supports
that
across
a
wide
range
of
databases.
You
know
sql
nosql,
new,
sql
and
also
in
number
of
replication.
A
We
can
do
java
implementation
of
an
order
and
we
can
have
a
javascript
function,
implementing
the
inventory
in
this
in
in
this
simple
example.
But
the
interesting
thing
is
that
for
all
the
clients,
web
clients,
iot
clients,
you
know
they
communicate
over
grpc
to
these
entities,
but
they
do
that
through
the
through
the
cloud
state
proxy
and
the
cloud
state
proxy
is
we're
managing
all
the
data
on
behalf
of
all
these
entities,
so
it
repopulates
them
as
needed.
A
You
know
during
as
they
are
requested.
You
know
so
so
so
all
of
these
entities
are
always
fully
hot.
They
always
have
the
latest
data
available.
They
are
truly
really
end
points.
You
know,
and
the
database
sits
in
front
of
it
again
having
this
inversion
of
control
where
his
entity
is
just
you
know,
sort
of
sent
the
the
things
he
needs
at
this
at
each
moment.
So
to
speak
and
the
class
a
proxy
looks,
looks
across
all
these
entities
and
optimizes
the
data
storage
for
all
of
these
state
models
across
all
the
entities
you
have.
B
B
Unfortunately,
I
don't
think
we'll
be
able
to
use
this
for
this
session,
because
I
think
the
organizers
of
kubecon
already
have
a
q,
a
application
in
place,
but
maybe
next
to
kubecon.
They
can
use
this
so
to
prepare
for
this
presentation.
I've
already
got
a
few
things
in
place.
I've
I'm
going
to
use
javascript
for
this
cloud.
B
State
supports
a
range
of
different
languages,
but
javascript
is
is
a
language
that
many
people
know
so
I've
set
up
a
package
json
I've
got
a
docker
file
so
that
I
can
build
this
and
deploy
it,
and
the
first
important
thing
that
we're
going
to
look
at
is
the
protobuf
file
for
the
q
a
service.
So
here's
our
jrpc
service
here
service
q,
a
there,
are
two
rpc
calls.
B
B
So
another
thing
to
look
at
both
of
these
requests.
Ask
request
and
watch
request,
have
a
field
on
them
called
presentation,
and
that
field
has
an
annotation
on
it
saying
what
the
entity
key
is.
So
a
single
cloud
state
service
may
serve
many
entities
each
with
a
unique
key,
and
this
is
how
cloud
state
knows
when
it
proxies
the
calls
going
to
the
service.
B
B
B
Now
to
implement
this
service,
I'm
using
a
crdt
codt
stands
for
conflict-free
replicated
data
type
and
what
crdts
allow
is
for
state
to
be
shared
between
many
nodes.
So
we
can
deploy
this
to
many
nodes
and
those
many
nodes
can
can
read
and
update
that
state
independently,
with
no
coordination
and
they're
guaranteed
to
all
converge
on
the
same
state.
B
B
B
So
I
can
then
check.
Does
the
state
have
the
question
that
is
being
asked?
If
it
doesn't
have
the
question
that's
been
asked,
I
will
set
it
to
a
new
g
counter.
Now
g
counter
is
another
crdt.
It's
a
counter.
G
counters.
It
stands
for
grow
only
counter
they're
great,
because
you
can
have
100
nodes
up
incrementing
these
counters
all
simultaneously,
with
no
coordination
and
you're
guaranteed
that
every
single
increment
that
you'll
do
will
be
counted
nothing's
going
to
overwrite
each
other.
There's
no
coordination,
no
looks.
B
So
that's
the
ask
call
done
the
next
thing
that
we
want
to
implement
is
the
watch
call
so
similar
to
us.
We
take
a
request
and
context
parameter
we're
not
going
to
actually
use
the
request
parameter,
and
one
thing
I'm
going
to
do
here
is
create
a
helper
function
to
copy
the
questions
from
the
crdt
map
into
a
straight
json
object.
B
So
there's
the
keys
of
this
object
are
going
to
be
the
questions
themselves
and
the
values
will
be
the
the
current
count,
the
current
value
of
the
counter,
so
we'll
iterate
through
the
current
or
map
and
for
each
counter
in
question.
We
will
then
update
that
counter
and
finally
return
the
questions.
B
If
there
are
any
fields
that
have
updated.
So
if
the
number
of
keys
in
there
is
greater
than
zero,
then
we'll
return
the
updated
questions
and
now
we're
almost
finished.
We
just
register
those
command
handlers
on
the
entity,
so
the
ask
function
will
be
used
to
handle
the
ask
command.
This
is
from
here
that
will
handle
that
and
watch
method
will
handle
the
watch,
jrpc
method
and
finally,
we'll
start
the
entity,
and
now
I've
implemented
my
q
a
stateless
function.
B
So
let's
have,
let's
now
build
that,
so
I'm
going
to
run
npm
run
docker
build
push.
So
this
is
a
helper
function
that
I
created
before
and
while
that's
running
I'm
going
to
quickly
show
you
this
ui
that
I
created.
So
this
is
a
separate
deployment.
This
obviously,
is
not
part
of
cloud
state,
but
it's
going
to
use
that
stateful
service
that
we
just
created.
So
it
will.
Let
us
select
a
presentation
from
here
and
be
able
to
ask
questions
on
it.
B
B
B
B
This
just
run
one
node,
then
it
wouldn't
be
that
interesting,
because
it's
very
easy
to
get
state
consistent
on
onenote,
but
because
it's
running
on
six
nodes
and
because
anything
can,
when
a
request
comes
in,
it
could
go
to
any
of
those
nodes.
If
those
nodes
aren't
sharing
their
state
and
the
crdts
aren't
working,
then
this
demo
won't
work.
B
So
it's
all
running
now,
let's
go
to
a
presentation
and
I'm
going
to
ask
a
question
and
it
appears
there
there's
a
little
bit
of
a
delay
there.
That's
because
I
haven't
done
anything
to
try
and
update
the
state
locally
in
the
in
the
client.
When
I
ask
a
question,
it
actually
relies
on
this
on
the
the
update
of
the
crdt,
which
then
will
get
gossiped
to
the
other
nodes
and
then
get
pushed
down.
B
Does
it
work
across
browsers
and
we
can
see?
Yes
indeed,
it
does.
If
I
vote
in
this
one,
I
should
see
that
go
up,
so
we
can
see
voting
works.
We
can
vote
all
over
the
place
and
just
click
vote
and
all
all
these
things
should
eventually
converge
on
the
same
state
as
all
the
nodes,
and
I
don't
know
actually
which
nodes
these
are
connecting
to
it's
using
a
load
balancer
that
would
randomize
it
so
they're,
probably
not
connecting
to
to
all
the
same
nodes.