►
From YouTube: It’s a Polyglot World of Stateless Functions and Stateful Actors - Yaron Schneider & Aman Bhardwaj
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.
It’s a Polyglot World of Stateless Functions and Stateful Actors - Yaron Schneider & Aman Bhardwaj, Microsoft
Serverless applications are becoming dominate, but all too often they fall short by only supporting stateless functions, when most applications are polyglot in nature and combine both stateless and stateful services. What’s more when you write code, it's not portable across different clouds and hosting platforms. In this session we will dive into the Distributed Application Runtime, Dapr, an open source, vendor neutral project that has gained community attention as it enables developers to combine highly portable, stateless functions and stateful actors using any language or developer framework of their choice. With built in state management, distributed tracing based on Open Telemetry and pub/sub based on Cloud Events you can take advantage of Dapr to build highly available serverless applications that run on any cloud.
https://sched.co/Zeky
A
A
A
So
developers
are
being
asked
to
write
very
resilient
scalable
micro
services
based
applications
that
mostly
interact
with
other
services,
whether
it's
through
direct
service
to
service
invocation
or
whether
it's
event
driven
and
those
types
of
applications,
have
multiple
languages
that
they're
written
in
so
they're
becoming
increasingly
polyglot,
and
that's
also
a
challenge
because
you
sometimes
need
to
also
leverage
existing
code.
Introduce
new
code
to
the
mix
and
new
languages
need
different
sdks
and
those
stuff
basically
have
developers,
focus
on
things
other
than
their
core
business
logic
like
infrastructure.
A
A
So
really,
a
few
things
that
are
holding
microservices
back
are
having
to
incrementally
migrate
your
existing
code
to
a
microservices
architecture.
You
know
you
need
to
deliver
in
your
business
logic,
and
then
you
want
to
leverage
the
strengths
of
the
microservices
architecture,
but
you
don't
want
to
rewrite
your
entire
code
base.
So
you
go
on
to
these
new
programming
model
runtimes,
but
they
have
narrow
language
support.
Some
of
them
are
bound
to
one
cloud
provider
or
another.
A
They
have
very
tightly
controlled
feature
sets
which
really
have
you
tie
into
a
very
specific
way
in
which
you
need
to
write
your
code
and
some
of
them
only
run
on
specific
infrastructures
and
they're,
not
that
portable.
You
know
between
the
cloud
and
the
edge
and
we're
seeing
more
and
more
code
being
transferred
to
the
edge.
A
So
we
introduced
dapper
to
allow
developers
to
solve
these
hard
problems
of
distributed
applications
and
dapper.
Really,
you
can
think
about
it
as
a
runtime
that
runs
as
sidecar
through
applications
that
gives
developers
sort
of
super
powers
just
the
same
way
that
kubernetes
and
a
lot
of
other
infrastructure
oriented
projects
give
developers
and
operators
the
ability
to
run
distributed
apps
at
scale
with
containers.
Dapper
really
appeals
more
to
the
developer
side
of
things
and
give
developers
apis
that
help
them
focus
on
their
business
logic.
A
Some
of
the
core
goals
of
dapper
are,
first
of
all,
to
give
developers
best
practice
building
blocks,
meaning
all
the
best
practices
that
you
can
find
in
distributed.
Systems
are
basically
built
into
this
sidecar,
so,
whether
you're
doing
a
stateful
operations
or
pub
sub
or
service
invocation
or
any
of
the
other
features
that
dapper
gives
you.
A
A
Some
of
the
capabilities
that
dapper
gives
are
really
called
building
blocks,
which
you
can
see
here
inside
of
the
dapper
block,
so
service
to
service
invocation
is
the
ability
to
find
a
different
service
in
the
cluster,
using
a
unique
id
and
really
get
abstracted
away
from
all
of
the
service
discovery
and
reverse
proxy
mechanisms.
Dapper
will
do
discovery
for
you.
It'll
do
retries
and
it'll
build
in
resiliency
into
your
calls.
A
State
management
is
another
kind
of
building
block
that
we
have,
which
really
gives
you
very
nice
abstractions
over
state
management.
So,
as
a
developer,
you
can
write
your
code
once
and
target
the
key
value
api
and
then
plug
in
different
components.
So,
for
example,
if
you're
running
on
aws,
you
can
just
configure
it
to
use
dynamodb.
A
A
Is
you
getting
distributed,
tracing
for
free
with
dapper,
because
you
talked
to
the
adapter
apis?
That
print
knows
to
talk
the
language
of
open
senses
and
the
protocols
of
open,
telemetry
and
it'll
inject
headers
into
the
codes
and
create
really
this
application
map
for
you,
where
you
can
have
end-to-end
visibility
across
the
calls
into
your
applications
and
from
your
applications.
A
Secrets
are
a
really
nice
thing.
Think
about
you,
know
your
pod
running
in
kubernetes
cluster
and
you
need
to
extract
secrets
from
hashicorp
vault
or
the
kubernetes
secret
store,
and
you
don't
want
to
start
mounting
stuff
on
the
pod.
So
dapper
has
a
really
easy
api,
where
developers
can
just
call
secrets
and
get
them
back
and
then
everything
else
is
really
extensible.
A
Those
building
blocks
and
and
the
components
that
they
use
are
really
plugable
and
there
is
actually
a
separate
repository
under
the
adapter
organization
in
which
community
members
can
contribute
more
and
more
components,
and
then
all
of
this
runs
on
cloud
or
on
the
edge.
So
dapper
does
not
have
to
run
in
a
container.
That's
important.
A
This
is
dapper
hosted
on
kubernetes,
so
dapper
like
a
service
mesh,
really
inject
a
side
car
container
into
your
pod.
So
you
have
your
application
pod
here,
your
application
container
inside
the
pod
and
you
have
the
dapper
container
being
injected
and
because
they're
running
under
the
same
network
namespace
your
application
code
in
the
container
just
talks
via
localhost
to
dapper,
so
think
about
it
like
having
a
special
friend
and
localhost
that
does
things
like
state
management
and
pub
sub
and
service
invocation
and
tracing
and
secret
extraction.
A
For
you,
dapper
is
really
really
lightweight.
It
uses
four
megabytes
of
ram
of
committed
memory.
It's
a
23
megabytes
image.
It's
container
image
size
is
smaller
than
envoy
and
the
link4d
property.
I
think,
and
it
uses
only
four
system
pods.
So
we
have
the
sidecar
injector,
which
is
really
lightweight,
and
we
have
a
certificate
authority
called
sentry
which
gives
you
end-to-end
encryption.
B
Yeah,
so
one
one
idea
for
dapper
is
that
it
takes
more
of
an
additive
approach
and
it
doesn't
preclude
service
developers
from
using
any
of
the
existing
cloud
native
technologies.
So
in
this
slide
you
can
see
that
dapper
runs
in
the
same
part
with
the
user
application
and
the
link
id
and
because
dapper
runs
at
an
application
level,
and
this
and
service
meshes
at
more
of
a
layer
four
level,
so
they
all
can
coexist
in
in
the
same
part
and
and
provided
additive
capabilities
to
the
user
applications.
A
Yes,
so
leicemon
said,
service
meshes
really
work
at
the
network
level,
where
they
intercept
traffic
and
dapper
is
more
of
an
application
level
concern.
There
are
some
overlaps
with
mutual
tls
and
tracing,
but
everything
in
dapper
is
also
configurable,
so
you
can
turn
it
off
or
on
based
on
whether
or
not
you're
running
a
service
mesh.
So
dapper
plays
really
well
with
things
like
html
link.
Reading
another
cncf
project
that
dap
really
integrates
well
with
is
keda.
B
So
this
slide
shows
the
service
invocation.
Building
block
for
dapper
service
invocation
provides
the
capabilities
to
developers
to
directly
invoke
their
service
methods
without
worrying
about
service
discovery
on
a
particular
platform,
so
using
dapper
services
are
deployed
using
an
id
and
and
after
that,
one
service
can
talk
to
another
service
using
that
dapper
service
id.
So
in
this
example,
you
can
see
the
front
end
is
trying
to
make
a
call
to
this.
B
This
back-end
card
service,
and
it
it
just
does
that
over
an
http
post
request
to
its
dapper
sidecar,
and
it
says
that
hey,
I
hate.
I
want
to
talk
to
this
card
service,
and
this
is
the
method
checkout
which
I
want
to
invoke,
and
so
the
car
call
goes
from
front
hand
to
its
stepper
side
card
episode.
Figures
out.
Where
is
the
target
service
running?
It
forwards?
B
The
call
to
the
target
services
sidecar
and
it
lands
on
the
target
service
and
the
response
comes
back
to
the
to
the
front
end
using
the
same
route.
This
is
the
service
and
location
capabilities
for
dapper.
Now,
moving
on
to
observability
dapper
provides
certain
building
blocks
for
observability
like
metrics,
tracings
and
logs,
so
that
service
operators
can
look
at
the
health
and
metrics
coming
out
from
the
adapter
systems.
B
Services
of
the
system
parts
to
to
get
more
insight
into
what
is
going
inside,
the
dapper
side,
cars
and
dapper
indicates
currently
with
open
sensors.
In
future,
we
will
integrate
with
open
telemetry
so
that
metrics
and
logs
coming
out
of
a
dapper
sidecar
can
be
viewed
with
any
of
the
open
source
tools
available
like
jager
or
datadog
and
and
azure
application.
A
And
this
is
a
state
management
for
dapper.
So,
for
example,
an
application
can
talk
to
the
dapper
api
and
this
is
a
quite
a
simplistic
view
of
a
stateful
operation.
The
dapper
does
so.
It
supports
a
key
value
api
model
at
the
moment
where
the
application
basically
says
hey,
I
want
to
save
two
objects
and
they
both
have
keys.
A
So
we
have
star
wars,
themes,
examples
here,
because
we
all
have
stores
in
dapper
and
then
we're
basically
saving
two
pairs
of
keys
and
their
values,
so
the
value
can
be
a
primitive
or
it
can
even
be
a
complex
value
and
that
and
then
dapper
based
on
the
state
story
that
you
configured
it
to
work
with,
will
make
sure
that
the
state
gets
written
and
dapper
also
supports
some
other
advanced
capabilities.
On
top
of
those
basic
primitives.
A
Similarly,
this
is
a
get
statement
where
we
saved
some
state
and
then
we're
calling
dapper
this
the
http
api
to
get
the
state
back.
It's
also
important
to
know
that
all
of
those
calls
are
available
via
jrpc
as
well
and
not
just
http,
and
we
also
have
some
sdks
on
top,
but
really
the
lowest
common
denominator
for
in
terms
of
protocols
are
http
so
that
we're
inclusive
to
all
developers
out
there.
Now
those
are
some
examples
of
of
the
dapper
building
blocks
we're
going
to
talk
about
actors.
A
So
before
we
move
on
to
actors.
This
is,
for
example,
what
a
map
of
our
application
for
tracing
would
look
like
inside
the
cluster,
so
you
get
tracing
basically
for
free
with
dapper.
You
just
set
up
your
tracing
backhand,
configure
it
with
a
simple
yaml
and
then
dapper
will
show
you
the
map
for
your
application.
Calls
what's
nice
about.
A
A
B
A
B
Next,
we
talk
about
the
active
building
block
for
dapper
actor.
Pattern
is
a
computational
model
for
concurrent
or
distributed
systems
in
which
a
large
number
of
these
actors
can
execute
execute
simultaneously
and
independently
of
each
other,
and
actors
can
communicate
with
each
other,
and
then
they
can
create
more
actors.
One
thing
which
is
unique
about
actors
is
that
they
are
single-sided,
so
one
actor
method
can
execute
at
at
any
given
particular
amount
of
time.
B
So
to
tell
now,
actors
existed
in
their
own
language
frameworks
like
akav
for
java,
and
I
cannot
net
is
the
tottenham
equivalent
for
it,
and
then
there
are
other
reliable,
active
patterns
available
like
all
these
and
service
arabic
actors.
What
dapper
does
is
it?
It
encapsulates
the
core
functionalities
of
an
active
framework
in
the
dapper
sidecar,
like
turn
based
actors,
timers
reminders
and
state
management
and
distribution
and
failover,
so
that
users
can
write
their
active
services
services
in
any
language
of
their
choice.
B
They
just
need
to
talk
to
dapper
sidecar
over
http
or
grpc,
and
dapper
will
take
care
of
all
the
core
functionalities
of
an
actor
system,
and
dapper
can
can
scale
up
or
scale
down
your
your
active
instances
as
and
when
you
scale
up
scale
up
or
down
your
services.
So
dapper
has
a
placement
service
which
takes
care
of
distributing
your
acting
instances
across
multiple
parts
of
your
service
of
your
service
and
as
they
come
up
and
down,
adapter
will
redistribute
their
actual
instances
across
these
parts.
A
Yes,
so
we
can
actually,
if
you
think
of
drones,
for
example,
you
could
model
a
drone
as
a
pod
and
then
you'd
have.
Maybe,
if
you
have
a
thousand
drones,
you'll
have
a
thousand
pods,
but
with
actors
you
can
actually
host
millions
of
actors
inside
of
a
single
container,
which
is
really
powerful.
Really,
okay.
Let's
stop
talking
now
and
show
some
demos.
So
I'm
going
to
be
sharing
my.
A
A
A
All
we
have
is
a
simple
web
server
that
listens
to
some
endpoint
called
sample
topic
and
then
we're
printing,
hello
from
kafka
and
the
body
and
just
sending
back
a
200
response.
What
could
be
simpler
than
that?
Really,
I'm
not
tying
into
any
fast.
This
can
be
a
long-running
type
of
application.
So
this
really
meets
me
as
a
developer,
where
I
am,
and
so
I'm
listening
to
sample
topic
here
and
the
only
thing
as
a
developer
that
I
need
to
do
to
start
getting.
Events
is
just
write.
A
So
I
will
go
over
here
to
my
terminal
with
my
node
app
and
I'm
going
to
use
the
dapper
cli
to
allow
me
to
run
both
the
dapper
sidecar
and
my
applications.
This
is
a
developer
facing
tool.
That's
really
good
for
the
inner
dev
loop
stage,
so
I'm
doing
dapper
run
and
I'm
giving
my
application
an
id
here
and
I'm
telling
my
I'm
telling
the
apple
which
port
my
application
is
listening
on
and
then
I'm
just
launching
my
node
application.
So
this
will
on
after
one
time
and
my
application
side
by
side.
A
And
the
python
is
currently
sending
events
to
kafka,
also
through
dapper,
and
we
can
see
this
here
really
simple
python
application,
and
we
can
see
that
these.
This
has
the
dapper
url
here.
So
the
python
application
is
just
having
a
really
simple
loop
and
it's
calling
dapper
on
localhost
calling
bindings
and
calling
the
sample
topic
name.
So
the
python
app
also
has
this
yaml
that
we
saw
before
and
it's
ending
a
very
simple
payload.
So
a
very
simple
you
know:
sdk-less
python
app
sending
messages
to
a
very
slim,
node.js
application.
A
A
A
A
And
so
we
can
see
that
it's
already
running
and
if
we
take
a
look
at
the
dogs
and
we'll
wait
for
them
to
come
up
and
everything
seems
to
be
up
and
running
and
we
can
use
the
damper
cli
see
that
we
have
the
latest
version
of
the
app
running
and
the
control
plane
is
healthy.
So
that's
all
it
takes
really
now.
The
only
second
step
is
to
deploy
everything
onto
our
kubernetes
cluster,
so
we're
in
the
deployment
folder
here.
A
And
while
this
is
deploying,
we
can
see
that
we
have
kafka
installed
inside
of
our
kafka
namespace.
And
if
we
take
a
look
at
the
pods
that
we
have
here,
we
can
see
that
the
wrapper
pods
running
and
our
two
apps
are
running
too.
So
we
have
two
containers
inside
our
pods,
one
for
the
dapper
sidecar
and
the
other
for
the
user.
App
and
now,
if
we
take
a
look
at
the
logs
for
the
node
app.
A
We
can
see
that
the
same
code
that
was
written
on
our
machine
just
get
containerized
and
it's
talking
to
kafka,
and
if
we
take
a
look
at
our
components,
we
can
see.
We
have
our
sample
topic
component
here
and
now
I
can
just
switch
the
sample
topic
to
be,
for
example,
instead
of
kafka
it
can
be
rabbidmq
or
any
other
of
the
supported,
dapper
components
and
then
without
changing
anything
in
my
code.
I
just
get
events
coming
in
from
the
system
that
I
configured
to
work
with
dapper.
A
B
It
is
okay,
sounds
good,
so
I'm
gonna
demo,
the
next
two
building
blocks
for
dapper.
One
of
them
is
actors,
so
devil
provides
first
class
support
for
language
sdks
to
write
your
actor
applications.
This
is
an
example
using
csharp
sdk,
but
we
have
language
sdks
available
for
java
and
python
and
and
more
are
more,
are
on
the
way.
B
B
Now
you
just
define
your
class
demo
actor
deriving
from
our
base
class
and
implementing
the
methods
inside
this
item
actor.
If
we
look
at
the
methods
called
save
data
and
get
data,
you
can
see
that
save
data
is
interacting
with
the
state
manager
to
save
the
state
and
then
it's
using
state
manager
again
in
the
get
data
method
to
get
the
state.
B
So
what
it's
doing
behind
the
scenes
is
that
it's
making
calls
to
the
adapter
side
car
to
save
the
state
using
the
configured
state
store
for
for
dapper
and
to
configure
a
state
store.
It's
a
familiar
component
yaml.
It
just
says
that
I
use
reddest
as
the
state
store
for
actors
and
that
perside
can
start
using
it
now
how
to
make
calls
to
the
cost
director
service
from
a
client
service.
B
It's
pretty
simple,
you
just
create
an
actor
proxy
and
tell
it
that
you
want
to
talk
to
an
actor
id
and
you
and
you
make
a
call
to
a
particular
method,
and
this
gets
calling
it's
making
cost
to
save
data
and
to
get
data
and
to
run
this
service
you
integrate
with
asp.net
core
while
creating
your
web
host
builder,
you
just
say:
dot
use
active
center
and
then
you
register
your
actor
type.
This
will
configure
the
actor
sdk
runtime
to
talk
to
dapper
site
car
and
bring
the
whole
functionality
of
vectors
to
you.
Now.
B
B
So
in
this
case,
I'm
going
to
show
you
invocation
of
the
actor
method
using
http,
and
this
could
be
any
language
of
your
choice.
So
it's
going
to
make
a
call
to
local
deposit
card
over
port
3500,
and
it's
saying
that
invoke
this
save
data
method
for
demo
actor
type
and
the
actor
id
is
abc
and
once
it
does
that
it's
going
to
save
the
state
into
the
actor
using
dapper
sidecar.
B
And
then
you
can
query
the
state
using
using
the
getdata
method
here.
So
it's
going
to
query
the
state
back
from
the
active
site
card,
so
the
next
building
block
I'm
going
to
show
you
is-
is
pub
sub
from
from
dapper
with
pub
sub.
You
can
have
your
application
subscribe
to
a
topic
and
other
application
publish
emails
to
that
topic
and
your
subscriber
will
will
get
notified.
So
in
this
example,
we
have
a
node,
a
very
simple
node.js
application.
B
Similarly,
there
could
be
python
application
in
this
case.
It's
a
python
application
telling
tapper
hey
I'm
interested
in
topic
a
and
c,
and
these
are
the
routes
on
which
you
should
invoke
me.
Whenever
you
see
a
message
for
those
topics
now,
let's
run
this
node
subscriber
using
that
precisely
using
the
cli
and
then
run
the
python
subscriber
using
dapper
cli
now
to
to
send
messages
to
these
topics.
I
have
a
very
simple
react:
form
application,
which
is
going
to
send
topics
to
we're
going
to
send
emails
to
these
topics.
B
Let's
take
a
look
at
this.
This
server
application,
which
is
publishing
the
events
to
publish
the
events
using
dapper.
You
just
make
an
http
call
to
this
publish
endpoint,
and
then
you
give
it
a
topic
name
and
and
the
body
of
your
of
your
message
and
it
will
be
sent
to
the
side
car
which
it
will
in
turn
invoke
your
subscriber
applications.
B
A
B
B
A
A
And
so
we
invited
to
join
the
dapper
community
over
on
github
getter
youtube
we're
pretty
much
everywhere.
Just
join
us
open
issues
download
the
software.
Try
it
and
yeah
keep
in
touch
with
us.
We
really
want
to
onboard
as
many
developers
as
we
can
to
dapper
and,
with
your
help,
have
it
really
solve
all
the
problems
of
distributed
computing,
we'll
open
it
up
for
questions
now.
Thank
you.
A
A
Yeah,
that's
a
good
question
so
for
that
we
are.
First
of
all,
we
are
going
to
release
performance
benchmarks
for
adapter
pretty
soon
so
we'll
know
the
exact
latency
and
processing
added
latencies
for
dapper.
If
you
were
just
having
your
application,
for
example,
publish
a
message
or
go
to
another
app
directly
or
through
dapper.
A
We
know
today
that
the
network
cost
of
calling
into
dapper
is
about
600
microseconds,
and
we
can
also
share
that
under
load
of
1000
requests
per
second,
with
a
one
kilobyte
payload,
the
dapper
sidecar
will
add
4.2
milliseconds
end-to-end
network
latency,
meaning
the
application
calls
to
dapper
adapter
calls
to
dapper
on
another
vm,
so
a
network
hop
and
then
dapper
calls
into
the
second
app
and
all
the
way
back.
So
it
really.
The
answer
is:
it
depends
on
on
your
latency
requirements,
but
what
we're
seeing
so
far
is
pretty
good.
A
Okay,
liam:
can
we
still
access
native
apis
with
services
like
kafka,
we're
limited
by
the
interface
you're
limited
by
the
interface,
but
dapper
provides
sort
of
escape
hatches
into
specific
features.
So
if
you
actually
go
on
our
repositories
and
take
a
look
at
the
the
specifications
that
we
have
for
the
different
components,
you'll
see
that
it's
very
easy
to
add
very
feature
specific
stuff.
So
you
don't
have
this
lowest
comment
in
a
minute,
dominator
stuff.
B
A
There,
what
is
the
governance
model
of
dapper?
That's
a
very
good
question,
so
currently
we're
actually
building
a
governance
model
now
which
we're
going
to
announce
in
the
next.
I
want
to
say,
I
want
to
say
the
next
month
at
least
announce
the
plans
for
it.
But
if
you
check
out
the
dapper
announcement
blog
from
october
of
2019,
we
made
a
commitment
for
open
governance
and
to
donate
the
upper
to
a
foundation.
A
When
can
we
expect
a
1.0
release
yeah?
That
question
comes
up
a
lot
by
the
end
of
the
year
calendar
year,
so
yeah
we're
shooting,
for,
I
would
say,
the
october
november
time
frame
something
like
that:
everything's
open.
If
you
go
to
the
dapper
organization
page,
you
will
see
projects,
you
will
see
the
milestones.
Anything
that's
marked
as
p1
needs
to
be
done
before
the
1.0
release.
So
it's
all
it
really.