►
From YouTube: Webinar: Dapr, Lego for microservices
Description
Developers building cloud-native applications come across the same challenges – reliable service invocation, state management, event-driven services, and observability to name a few. However, developers should focus on application business logic, not solving distributed application challenges. The distributed application runtime, Dapr (https://dapr.io) is an open-source project that provides developers “building blocks” to solve common challenges when building portable, resilient scalable distributed applications. This session will show you how you can use these Dapr building blocks, and the extensive range of pluggable components, to efficiently build cloud-native applications deployed to Kubernetes and other hosting platforms.
Presenter:
Mark Chmarny, Principal Program Manager @Microsoft
A
All
right,
let's
go
ahead
and
get
started.
I'd
like
to
thank
everyone.
Who's
joining
us
today.
Welcome
to
today's
cncf
webinar
dapper
lego
for
microservices,
I'm
karen
chu
community
manager
at
microsoft
and
cncf
ambassador
I'll,
be
moderating.
Today's
webinar
and
we'd
like
to
welcome
our
presenter
today
mark
charming
principal
program
manager
at
microsoft
and
before
we
get
started
just
a
few
housekeeping
items
during
the
webinar,
you
are
not
able
to
talk
as
an
attendee.
A
There
is
a
q,
a
box
at
the
bottom
of
your
screen.
Please
feel
free
to
drop
in
your
questions
there
and
we'll
get
through
as
many
as
we
can.
At
the
end.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
the
code
of
conduct.
Basically,
just
please
be
respectful
of
all
your
fellow
participants
and
presenters.
B
B
I
want
to
review
some
of
the
kind
of
things
that
drove
us
to
create
dapper
and
what
it's
trying
to
solve.
I
think
there's
many
different
reasons
for
that,
but
I
think
they
boil
down
to
three
things.
I
think
too
often
developers
nowadays
they're
step
one
in
writing
any
new
application.
They
have
to
decide
where
this,
where
this
application
is
going
to
run,
because
moving
that
application
later
to
a
different
platform,
will
often
require
a
complete
rewrite.
B
The
gap
between
what
the
existing
application
looks
like
and
what
it's
considered
to
be
a
modern
application
in
the
community
is
increasingly
larger
and
larger,
and
it's
not
common
to
find
companies
that
have,
I
don't
know,
1500
to
2000
applications
that
they
want
to
modernize.
But
they
want
to
do
it
all
in
one
split
move.
So
these
are
kind
of
the
things
that
set
up
the
context
for
dapper
and
the
type
of
things
that
we
would
like
to
solve
for
for
the
developers.
B
So,
let's
go
into
the
upper
first
of
all,
just
a
short
overview.
Doppler
stands
for
distributed
application
runtime.
Yes,
we've
abbreviated,
three
words
into
four
letters.
I
know
it
was
hard,
but
we've
done
it
in
a
plain
english.
Dopper
is
really
an
event-driven
application.
It's
portable
runtime
that
helps
developers
build
distributed,
applications
regardless
when
they
run
them,
whether
it's
a
bare
metal
cloud
edge
devices
and
I
mean
actually
edge
devices
like
raspberry,
pi
or
something
the
the
runtime
is
kind
of
independent.
Of
that
it's
an
open
source
project.
B
As
of
this
am
I'm
happy
to
say,
and
I
think
we've
landed,
the
11th
release
of
dapper
or
11
major
release,
so
vu
011,
there's
a
decent
number
of
image
pools
that
actually
signals
a
real
live
usage.
So
this
is
not
just
the
kind
of
things
that
it's
out
there
and
sitting,
but
people
using
this
in
real
life.
B
So
what
are
some
of
the
kind
of
principles
that
there
are
behind
dapper?
So,
first
of
all
is
no
limitations
with
regards
to
the
language
or
framework.
If,
if,
if
a
new
language
come
out
comes
up
tomorrow,
something
like
you
know,
I
don't
know,
I
can't
even
venture
to
think
of
what
that
would
be.
We
should
be
able
to
run
if
you
can
start
it.
If,
as
a
process,
we
should
be
able
to
run
it
inside
of
dapper.
B
B
Well,
documented
eight
set
of
apis
that
are
that
provide
a
parity
across
multiple
protocols
and
runtimes,
so
grpc
or
http
protocol
doesn't
matter
the
the
shape
of
the
api.
The
functionality
is
is
the
same,
even
though
the
protocols
are
different
and
it
runs
like
I
said,
before,
around
greater
kubernetes,
as
well
as
any
other
infrastructure
where
it
can
be
like
a
standalone
process.
B
B
You
can
get
either
the
readily
available
version
of
the
opera
or
just
compiled
for
those
two
and
and
and
the
last
thing
is
the
doctor
really
tries
to
meet
the
developers
where
they
are
the
investment
that
you've
done
in
learning
particular
language
java.net
python,
whatever
that
may
be,
we
want
to
make
sure
that
you
feel
at
home
in
in
kind
of
natural.
Idiomatic
is
just
a
fancy
term
for
natural
to
you
that
should
make
you
effective
on
day
one.
B
There
is
no
courses
required;
there
is
no
certification
use,
it
incrementally
start
small
and
then
build
from
there.
So
hopefully
that
will
give
you
a
good
background
where
dapper
was
going
kind
of
logically
and
we'll
go
deeper
into
each
one
of
those,
but
logically
dapper
at
run
time
kind
of
exposes
those
apis
like.
I
was
saying:
http
and
grpc.
These
apis
give
you
access
to
the
most
common
usage
patterns
that
we've
seen
in
distributed
applications
and
we
generalize
them
into
something
that
can
be
consistent
to
you
as
a
developer,
but
yet
flexible
underneath.
B
So,
hopefully
never
again
we
hear
about
somebody
needing
to
move
1500
application
in
once
we
move
to
a
new
platform
so
more
on
those
building
blocks.
Going
deeper
into
there,
these
blocks
are
they're,
independent,
so
they're
not
in
there's
no
dependency
between
each
one
of
those
blocks.
So
we
let's
go
through
those
one
by
one
service
to
service
invocation
or
it's
it's
a
basically
a
reverse
proxy,
like
api
for
communication
between
multiple
services
within
your
application.
B
So
if
you're,
building
microservices
you're
building
a
number
of
different
services
inside
of
something
that's
considered
to
be
an
application
and
for
you
to
be
able
to
dynamically
discover
those
services
and
connect
to
them,
that's
where
dapper
comes
in
the
other
common
thing
that
we
see
pretty
much
is
state
management.
Think
about
durable,
key
values,
object
store
like
s3
or
gcs.
B
That
gives
you
this
put,
get
verbs
capabilities
that
allows
you
to
kind
of
query
by
by
state
the
shape
of
those
apis
is
pretty
consistent,
yeah.
They
have
different
functional
capabilities,
but
to
large
degree
we
can
give
you
a
very
consistent
api
to
that
to
managing
your
state
in
your
application.
With
regards
to
pops
up.
This
is
all
about
messaging
within
application.
There
is,
you
know,
a
different
perspective
on
what
mark
mark
microservices
should
be
doing.
They
should
be
servicing
to
service
invocation
directly
or
they
should
be
in
synchronous
through
pops
up.
B
The
upper
provides
you
both
of
those.
So
if
you're
looking
for
a
messaging
between
your
application,
asynchronous
messaging
between
applications,
you
can
use
pops
up,
that's
built
in
and
you
can
plot
the
specific
implementation
underneath
of
that.
So
if
you
want
to
do
like
a
fanouts
pattern
or
a
fan
in
super
easy
to
do
that
and
there's
a
exact
at
least
once
delivery
semantics,
so
you
don't
have
to
worry
about
kind
of
events
being
lost.
B
B
You
can
trigger
your
code
based
on
external
events
when
they,
when
they
run
when
they
kind
of
happen
outside
of
your
cluster
or
outside
of
your
environment,
and
you
can
send
data
from
your
application
to
outside
resources,
actors
and
I'll
go
through
each
one
of
those
a
little
deeper,
but
trying
to
provide
a
little
summary
here,
actors
very
much
like
an
independent
unit
of
distributed
state
and
single
threaded
compute
capability.
So
if
you're
thinking
of
something
that
is
going
to
require
high
density,
that's
a
great
great
kind
of
category.
For
that
there
are
some
concerns.
B
You
have
to
be
aware
of
around
a
single
thread:
thready
threading
architecture,
but
we'll
talk
about
in
a
second
and
observability
it
very
much
all
about
automatic
kind
of
insight
into
what
your
application
is
doing
so
capturing
the
call
graph
of
of
all
the
invocation
across
graph
across
dapper
and
the
telemetry
with
regards
to
those
metrics
that
are
related
to
how
the
applications
are
responding,
how
many
times?
How
long
did
it
take
and
in
tracing
of
the
invocations
across
multiple
services?
B
If
you're
talking
about
microservices,
you
probably
have
a
call
stock
that
involves
four
or
five
ten
put
even
more
microservices
and
being
able
to
look
at
them
as
a
unit,
helps
you
kind
of
debug
those
issues
and
understand
the
bottlenecks,
and
we
have
secrets
we've
all
heard
about.
You
know
these
leaking
all
the
time.
B
So,
let's
kind
of
talk
about
the
architecture.
So,
regardless,
if
you
run
on
kubernetes
bar
metal,
vm
doppler
uses
this
notion
of
a
sidecar.
And
yes,
I
know
it's.
Okay,
sidecar
is
kind
of
correlated
often
with
kubernetes,
but
in
this
case,
dapper
uses
this
sidecar
approach,
regardless,
where
you're
running
the
the
op
call
the
app
calls
into
dapper
sidecar
and
dapper
kind
of
execute
the
functionality
on
behalf
of
your
application.
B
This
helps
lower
the
utilization
and
offload
il
often
in
some
cases
can
actually
improve
the
performance
of
your
application.
All
services
invocations
are
encrypted
over
mtls
with
automatic
certificate
rotation,
including
situations
where
you
up
upgrading
the
actual
dapper
itself,
and
with
this
release
that
we
announced
earlier
today,
we
also
added
a
spf
identity
for
service
invocation
and
granule
access
controls,
including
all
policies,
if
you,
if
you
like
regal,
yes,
there's
overlap
with
many
mesh
meshes
out
there,
as
you
probably
have
already
realized.
B
So
how
do
I
get
one
of
those
magical
side
cards
that
does
everything
regardless,
where
I
run
well,
if
you're
running
on
kubernetes,
that's
as
simple
as
decorating
a
deployment
with
few
annotations,
and
I
bought
that
text
over
here.
There's
many
of
those
annotations
you
can
add,
but
really
only
two
are
required.
You
say
enable
adapter,
and
then
you
also
tell
me
tell
doctor
what
is
the
id
by
which
you
want
this
application
to
be
used
which
comes
into
servicing
location
and
many
other
things.
B
Dapper
will
automatically
inject
a
sidecar
into
the
pod.
So
it
will
look
very
much
like
the
experience
that
you
had
when
you
were
developing
using
dapper
on
a
local
machine.
It
would,
in
fact
your
application
will
know
anything
different
in
a
standalone
mode.
If
you're
running
outside
of
kubernetes
or
running
on
any
other
infrastructure,
you
can
run
it
using
the
dapper
run
command
in
a
self-hosted
mode
as
we
refer
to
it,
uses
dapper
run
and
regardless
of
what
the
process
is.
B
I've
demonstrated
three
or
four
in
here:
it
could
be
directly
into
runtimes,
so
go
or
node
or
net
or
whatever
they
might
be,
or
it
could
be
actually
an
executable,
that's
already
kind
of
compiled
into
a
machine
code
or
something
like
that.
It's
a
lot
of
flexibility
there
with
regards
to
kind
of
dapper
and
kubernetes.
I
think
this
is
a
good
one
to
go
a
little
deeper
given
cncf
and
kubernetes.
B
We
try
to
keep
dapper
as
light
as
possible.
So
there's
really
only
two
crds
there's
four
system
codes,
although
we
can,
we
can
bring
it
down
to
about
two
if,
if
you're,
some
not
using
some
of
the
features,
so
the
first
one
is
the
sidecar
injector.
This
is
what
checks
for
the
annotations
and
inject
the
sidecar
into
your
pod
century.
Generates
certificates
for
the
sidecar,
implements
rotation
strategy,
the
operator
tracks
deployments
and
deals
with
things
like
resource
discovery
and
component
registry
and
actor
placement
deals
with
identifying
or
finding
where
the
dappers
are
located.
B
So,
let's
go
into
those
building
blocks
a
little
deeper
and
kind
of
show
them
in
a
real
world
like
examples,
so,
starting
with
the
key
value
state
management,
it
is
distributed,
object
store
for
your
applications.
What
that
means
is
that
it
outlives
the
session
of
the
application.
If
your
application
goes
out
of
scope,
it
can
be
restarted
somewhere
else
and
will
have
access
to
the
same
content
same
state.
B
It
has
a
concurrency
configuration
options
for
each
operation,
so
you
can
do
a
first
or
last
wins
if
you're
looking
around
have
concerns
around
concurrency
has
similar
configuration
for
consistency
with
regards
to
whether
it's
a
strong
or
optimistic
consistency,
and
it's
configurable
retry
policy,
which
means
it's
super
granule.
It's
not
only
on
the
entire
service,
but
it's
an
operation.
It
can
be
invoked
per
retry
per
operation.
It's
configurable.
B
We
also
support
bulk
and
transaction
operations
for
situations
where
you
want
to
save
a
number
of
records
or,
if
you
trying
to
retrieve
an
a
number
of
records,
the
back
state
for
those
is
totally
to
you
up
to
you.
There's
dapper
supports,
I
think
check
this
morning
about
12
of
those
so
etcd
redis,
cassandra,
gcp
cloud,
firestore,
aws,
dynamo,
there's
n
number
of
those
configurations
and,
depending
on
what
you
prefer
in
the
environment,
you
might
use
those,
but
the
api
which
will
be
exposed
to
you
to
use
the
state
union
application
is
consistent.
B
B
I
call
this
corporate
db,
but
it
could
be
frankly
anything
it's
a
component
of
a
type
of
state
and
in
this
case
it's
a
mongodb.
So
dapper
provides
these
configuration
options
for
any
number
of
those
components
that
we've
highlighted
before
70
or
some
before.
What
it
gives
you
access
to
is
some
metadata
that
you
can
use
to
configure
the
actual
service
itself,
including,
like
you
know,
the
database
and
other
things,
but
once
configured,
one
registry
in
dapper
now
is
becoming
available
in
your
in
your
dapper
api.
B
So
you
can
post
to
it
by
identifying
the
specific
component
and
save
the
data
to
this
particular
collection
in
in
this
case
to
database.
The
metadata
is
unique
to
a
specific
store.
So
in
this
case
this
might
have
metadata
that's
specific
to
if
you
were
using
xcd,
there
might
be
additional
parameters
there
and
you
will
see
the
other
options
we
provided.
B
Moving
on
to
service
discovery
and
invocation.
So
dapper,
like
I
said,
is
a
reverse
proxy
for
you
in
vocation,
but
that
allows
you
to
kind
of
locate
the
services
and
invoke
them
using
the
assign
id.
So,
in
the
previous
example
we
used,
I
don't
forget
what
we
use,
but
if
you
say,
for
example,
my
service
is
the
id
of
your
application,
you
can
start
invoking
from
all
you.
Other
services
within
your
application
and
and
dapper
will
make
sure
you
find
the
right
right
instance.
B
The
all
of
that
is
dynamic.
There
is
no
configuration
for
this
one
because
the
as
you
kind
of
started
the
services
within
dapper
they
all
automatically
are
registered
and
the
registry
is
managed
for
you.
It
works
in
kubernetes,
it
works
even
across
name
spaces,
so
you
can
cross
the
boundary
of
the
namespaces
and
you
can
invoke
them
over
http
or
grpc.
So,
regardless
what
your
application
is
running
on.
In
this
example,
we
have
a
http
application
that
it's
calling
into
the
grpc
application.
The
api
is
consistent
for
that
application.
B
Dapper
does
the
protocol
translation
so
grpc
to
http
or
http
or
grpc.
All
of
that
is
done
behind
the
scene.
Europe
applications
don't
have
to
be
aware
of
what
the
target
is
using,
like
I
said
before,
invocations
are
automatically
retried
on
a
call
level
which
is
more
granule
with
more
which,
with
what
you
get
normally
from
the
meshes
all
traffic
between
apps
is
over
and
tls
the
automatic
it's
automatic.
B
So
there's
zero
downtime,
even
during
the
third
rotation
process
and
and
upgrades,
and
because
now
dapper
also
support,
provides
the
x
509
certificates.
We
can
do
spiffy
identity
across
clusters
for
service
implications.
So
if
you,
for
example,
have
one
instance
of
dapper
running
on
gcp
and
another
one
on
aws,
you
can
reliably
and
securely
try
to
kind
of
connect
them
and
invoke.
Each
other
doctor
also
have
options
for
policy
through
annotations,
which
kind
of
obfuscates
a
lot
of
the
complexity,
as
well
as
for
a
proper
upper
oppa
implementation
for
rego.
B
So
if
you
prefer,
you
writing
your
applications
in
rego,
sorry
policies
in
regal,
you
can
you
can
do
that.
All
that
comes
with
automatic
telemetry.
You
don't
have
to
create
spams
us,
because
dapper
has
the
awareness
of
how
your
applications
are
invoking
each
other
that
that
parent
trace
id
is
automatically
injected,
and
you
can
start
kind
of
seeing
the
benefits.
I'm
going
to
show
you
this
during
the
demo
later
on.
B
Another
building
popular
building
block
is
pops
up.
It
really
allows
microservices
to
communicate
with
each
other,
so
publishers,
the
publisher,
has
no
knowledge
of
what
the
consumer
is
and
consumers.
No
idea
who
published
the
data
and
dapper
uses
cncf
cloud
events
to
as
a
kind
of
envelope
for
those
so
wraps
all
those
events
for
you.
It
provides
kind
of
at
least
once
consistency
sorry
provides
at
least
guarantees
for
your
for
your
publishers.
B
So
some
of
the
common
implementations
for
pops
up
inside
of
dapper
for
open
source
would
be
like
redis,
nuts
kafka,
rabbitmq,
hazelcast,
there's,
probably
a
missing
bunch
of
other
ones,
and
for
cloud
search
providers
for
azure.
It's
like
a
service,
bus
or
event
hub
for
gcp
is
pop
sub
and
for
aws
sqs
and
there's
a
couple
other
ones
for
each
one
of
those.
B
But
whichever
you
want
to
use
dapper
provides
you
ability
to
scope
those,
so
your
applications
can
be
limited
to
which
topics,
for
example,
which
comp
applications
can
use
each
one
of
those
components
again
very
much
like
we've
seen
before
with
a
state
exactly
same
component,
but
this
time
instead
of
state,
we
say
pops
up
in
this
case,
I'm
using
redis.
This
is
inside
of
the
cluster,
so
we're
calling
into
a
redis
namespace
fully
qualified
name,
and
we,
the
other
thing
you're
going
to
see
here.
B
I'm
going
to
talk
a
little
more
about
secrets,
but
you
actually
see
that
didn't
include
the
password
for
red
is
a
reference,
a
password
we'll
talk
about
how
dapper
kind
of
allows
you
to
do
it,
both
programmatically
and
inside
of
configuration,
but
once
once
registering
inside
of
dapper,
you
get
ability
to
share
post
to
these
topics,
and
consumers
can
kind
of
subscribe
to
them.
There's
two
different
ways
to
subscribe:
to
create
subscriptions
inside
of
dapper.
B
You
can
do
this
programmatically
where
dapper
queries
your
app
for
well-known,
endpoint
and
of
for
subscription,
and
this
is
kind
of
good
for
dynamic
use
cases
where
you
want
to
kind
of
respond
with
a
specific
configuration
and
the
app
responds
with
a
array
of
number
of
different
subscriptions.
Where
you
tell
us
to
which
component
and
topic
you
want
to
subscribe
and
what
is
the
url?
You
want
us
to
send
you
on
doppler
to
send
the
data
to
that's
great.
B
If
you
have
awareness
of
dapper
when
you
are
writing
this
application
for
situations
where
you
already
have
applications
that
are
aware
of
cloud
events
or
are
expecting
cloud
events,
you
can
use
declarative
manner,
which
dapper
provides
a
crd
for
that
allows
you
to
subscribe
to
to
create
subscriptions
program
through
configuration,
so
your
application
actually
has
zero
awareness
of
dapper.
It
just
says
I
I
know
cloud
events
give
me
cloud.
Events
and
apple
will
send
those
to
your
application.
B
Bindings,
like
I
said,
it's
kind
of
a
way
to
extend
the
functionality
of
dapper
and
and
there's
so
many
of
these
out
there.
I'm
just
gonna
list
a
few,
and
I
feel
like
I'm
highlighting
a
couple
of
these
consistently,
but
I'm
trying
to
create
some
variety.
We
have
two
different
flavors
of
binding
there's
input
and
output
bindings
and
the
output
binding
can
do
bi-directional
and
I'll
explain
what
that
means
for
input.
B
You
can
you
can
think
of
those
as
triggers,
so
something
will
come
from
outside
and
trigger
your
code
and
bring
some
data
or
maybe
not,
and
so
kafka
and
all
the
data.
The
kind
of
eventing
service
systems
out
there
are
all
are
good
use
of
kind
of
binding,
but
we
can
also
have
apis
like
twilio
or
twitter
and
so
forth.
It
really
removes
a
lot
of
the
complexity
of
your
application,
having
have
to
have
the
drivers
or
sdks
inside
of
your
code
and
polling
for
that.
Basically
application
says
I
don't.
B
I
don't
know
how
this
was
configured
but
give
me
your
that
event,
and
I
will
do
something
with
that:
it,
your
application,
can
be
in
grpc
or
http.
It
doesn't
matter
that
event
can
be
bound
to
you,
and
switching
between
these
bindings
and
runtime
is
really
as
easy
as
changing
configuration
and,
in
some
cases
relaunching
the
application,
so
that
perhaps
handles
a
lot
of
the
retries
and
failure
recovery.
For
you
and
again,
none
of
that
you
have
to
write
your
application.
B
B
So,
regardless,
if
you're
using
input
and
bounce
output
binding
approach,
the
configuration
of
that
using
component
is
exactly
the
same,
and
at
this
point
you've
seen
me
show
three
different
yamas
that
really
differ
very
differently
very
little.
They
only
have
some
metadata,
that's
specific
to
in
this
case,
for
example,
kafka
that
differs
and
provides
you
ability
to
configure,
but
the
actual
notion
of
configuring,
your
bindings
inside
of
dapper
is
super
consistent
and
easy,
regardless
if
you're
running
kubernetes
or
if
you're
running
on-prem,
that
same
file
will
work.
B
So
in
this
case
we
have
a
kafka
binding
that
defines
a
specific
topic.
It
could
be
n
number
of
those
for
simplicity
of
demo
just
have
one
to
which
it's
going
to
be
used
to
on
the
input
and
for
output.
We
also
have
limit
which
topic
can
be
used
to
send
data
out
of
your
application.
We
support
consumer
group,
there's
a
number
of
other
variables
that
kafka
provides,
but
that
kind
of
is
the
extent
of
that
and
then
for
input.
B
B
You
also
check
before
for
options
on
that,
just
to
make
sure
that
you
actually
have
the
route,
so
it
doesn't
start
flooding
you
with
data
before
you
are
ready
for
that
and
for
calling
outside
of
your
code
into
the
outside
world
you're
just
using
the
consistent
binding
api
with
that
same
component
and
upper
maps.
All
of
that
for
you,
we
talked,
we
touched
on
secrets
a
little
before,
but
secrets
are
generally
hard
problem
and
we've
all
heard
about
leakage
credentials
out
there.
B
Doppler
provides
you
with
this
api
that
that
is
consistent,
regardless
of
which
backend
you
use.
So
I
have
logos
for
four
or
five
four
of
those
out
there
there's
other
options
too,
but
these
cert
the
systems
are
backing
dappers
api
behind
the
scene,
so
you
can
manage
the
rotation
strategy
and
all
that
over
there
and
then
dapper
gives
you
this
consistent
api
that
you
can
use
both
from
within
your
code
through
the
same
api,
so
get.
B
So
in
this
case
we're
using
a
hashicorp
vault
secret
store,
we've
configured,
those
with
a
few
configuration
options.
There's
a
number
of
these
again,
I'm
just
showing
a
few,
but
you
can
now
invoke
that
api
in
dapper
for
secrets
for
specific
password,
and
you
will
get
that
value
of
that.
But
you
can
also
use
this
inside
of
the
configuration.
So
what
docker
will
do
in
this
case,
you
will
substitute
these
secrets
kind
of
inline
those
secrets
for
you.
So
your
configuration
is
free
of
secrets.
B
You
can
check
it
into
repository
and,
as
you
deploy
to
different
environments,
your
entire
solution
is
configurable
at
around
time,
and
observability
is
kind
of
a
built-in
building
block.
There's
there's
some
configuration
for
it,
but
what
there's
a
lot
of
automatic
things
that
happen,
and
so
I
want
to
talk
about
few
of
those.
First
of
all,
there's
a
ton
of
metrics.
B
That
dapper
gives
you
kind
of
a
visibility
into
with
regards
to
the
the
measure,
values
and
the
counts
around
time
series
monitors
behavior
of
itself
of
that
sidecar,
as
well
as
of
your
application,
and
by
default,
uses
prometheus
and
grafana.
There
is
number
of
options
to
switch
into
csp
specific
options
like,
for
example,
monitor
on
azure.
B
That
may
be,
you
get
those
traces
automatically
and
I'll
show
you
later,
but
all
of
that
is
by
default
available
in
zipkin.
If
you're
deploying
some
kind
of
open
source
centric
solution
in
a
csp
environment,
you
can
use
additional
like
application,
insights
on
azure,
for
example,
and
similarly
with
logs
you
get
fluency
and
elastic
and
kibana.
B
Dapper
injects
bunch
of
metadata
into
your
logs,
so
you
get
like
the
type
and
the
host
name
and
component
name
and
app
id
addresses
and
bunch
of
other
things
that
give
you
kind
of
more
context
for
actually
what
happened
there
right
now,
actors
as
a
building
block.
It's
like
I
said
it's
an
object-oriented
programming
model
like
akka
and
orleans
provides
durable
framework
for
hosting
your
actors
that
are
basically
what
what
its
functionality
here
is.
B
It's
a
self-contained
unit
of
code
that
you've
delivered
to
dapper
that
has
both
the
state
and
compute
and
dapper
manages
the
life
cycle
of
that
actor.
It's
based
for
use
cases
with
minimal
io,
because
it's
single
threaded.
So
if
you
start
locking
you
basically
like
the
entire
solution,
but
there
is
a
lot
of
benefits.
People
can
recognize
through
super
high
density.
I
think
the
numbers
have
seen
it's
like.
Thousands
of
actors
within
a
single
pod,
and
obviously
this
can
scale
horizontally
and
that
permanence,
the
state
of
your
actors,
offloads
them
when
they're
not
used.
B
All
of
that
is
configurable.
It
can
rehydrate
them
somewhere
else
with
the
right
state
and
but
because
the
actual
model
is
kind
of
function
of
the
runtime
itself.
Dapper
supports
actors
only
in
java.net
and
python
everything
every
other
building
blocks.
Up
to
now
I
told
you
about
it's
100
across
all
the
frameworks
of
the
different
languages.
B
So
at
this
point
you're
saying
okay,
this
is
great,
but
there
is
a
lot
of
urls
and
grpc
endpoints
and
we
have
not
moved
past
that.
Well,
yes,
we
done
we
pro,
you
can
always
use
the
raw
api
if
you
want
to,
and
in
some
languages
there
are
dynamic,
it's
kind
of
like
a
first-class
citizen,
rest
apis
like
in
node.js,
it's
something
you're
already
used
to,
but
we
provide
also
a
five
sdks
that
we
manage
the
dapper
project
management
is
currently
there's
a
number
of
those.
B
I
know
there's
a
ross,
there's
c
plus
and
a
bunch
of
other
ones
that
the
community
manages
too.
So
if
one
is
missing
that
you
would
like
to
see,
would
love
to
have
you
kind
of
contribute
and
help
working
on
that,
and
they
give
you
this
access
to
the
same
api
and
when
we
go
into
demo
in
a
minute,
I'm
going
to
show
you
how
we
can
leverage
that
to
kind
of
simplify
the
application,
there's
also
integration
into
some
of
the
frameworks
so,
for
example,
functions
or
azure
functions.
B
You
know,
regardless
of
running
on
azure,
aks
or
another
cluster.
You
have
access
to
to
those
functions
and
if
you're
kind
of
into
the
model
of
just
programming
only
at
the
function
unit,
you
can
kind
of
integrate
it
very
easily
into
dapper
and
bind
these
configuration
options
for
different
state
and
pops
up
very
easily.
Similarly
with
logic,
apps
spring
boot,
asp.net,
core
and
others
all
right.
I
think
at
this
point:
let's
go
into
demo.
B
So
what
I'm
gonna
do
is
I'm
gonna
start
with
a
actually?
No,
let's
do
a
slight.
I'm
gonna
walk
you
very
quickly
through
the
demo,
so
we
know
where
we
are
we're
going
to
do
way
over
engineer
application,
there's
probably
way
simpler
way
to
doing,
but
to
show
kind
of
the
capability.
I
will.
I
will
show
the
three
or
four
different
components
inside
of
dapper.
B
Then
we're
gonna
add
a
sentiment
analysis
api
as
an
another
doppler
service.
That's
going
to
be
using
service
to
service
invocation
to
score
each
one
of
those
tweets
sentiment,
so
we're
going
to
find
if
they're,
negative,
positive
or
neutral
or
mixed
sometimes,
and
when
we
score
those.
The
the
tweet
processor
will
also
publish
them
onto
a
topic
and
eventually
we'll
bring
a
ui
application
that
will
show
those
tweets
in
a
ui.
Don't
get
excited.
My
ui
foo
is
super
weak.
B
So
it's
going
to
be
very
rudimentary
application,
but
it
will
allow
you
kind
of
see
how
we
can
subscribe
to
events
and
stream
them
in
this
case
over
web
sockets
to
the
ui
all
right.
So
let's
now
go
to
the
application
so
couple
things
I
want
to
show
here
and
obviously
there's
a
lot
of
moving
parts,
but
the
first
thing
is
we're
going
to
show
the
component
for
twitter.
B
You
see
that
even
though
I'm
running
on
a
local
machine,
I'm
using
secrets-
and
it's
because
in
this
case
I'm
using
a
one
of
those
developer
friendly,
quick
and
dirty
kind
of
secret
stores,
which
is
a
file
store.
So
in
this
case
my
secret
store
for
dapper
is
defined
as
a
file
that
I'm
hosting
in
my
machine.
B
The
other
thing
we're
gonna
do
is
we're
gonna
define
a
state
in
this
case,
I'm
gonna
use
use
redis
for
state
as
well
as
for
pops
up,
so
that
nothing
changes
there
super
easy
for
your
local
development
and
we're
going
to
run
that
these
other
applications.
The
other
thing
to
kind
of
point
out
here
is
I'm
actually
using
the
dapper
sdk.
This
is
for
go.
The
very
same
principle
would
apply
for
every
single
other
language
out
there.
B
I
just
can't
write
anything
pretty
much
but
go,
and
even
that
is
pretty
weak,
but
you
will
see
that
I'm
creating
a
service.
The
the
part
I
want
to
focus
on
is
the
odd
of
creating
a
subscription
to
a
kind
of
binding
handler
is
as
simple
as
it's
a
method
on
the
client.
So
you
say
I
want
to
subscribe
to
the
tweets.
B
Remember
we
define
tweets
as
the
component
name
and
and
then
just
handle,
and
the
handler
is
super
simple,
doesn't
do
anything
other
than
just
publishing
it
to
a
to
a
topic
that
it's
configured
again
through
configuration,
so
this
is
as
exciting
as
yaml
gonna
get.
Let's
go
to
go
so
first.
What
I'm
gonna
do
is
I'm
gonna
launch
locally.
The
viewer
you
will
see
the
dapper
went
through
its
logging
processing
here
started
the
application.
B
B
What
we're
going
to
do
in
here
we're
going
to
actually
start
a
grpc
application
on
a
specific
port.
This
is
going
to
be
the
sentiment
scoring
application
and
we're
going
to
point
to
where
the
configurations
are
again.
I'm
just
using
go
itself
directly,
similar,
I'm
on
a
mac.
So
mac
asked
me
to
make
sure
that
I
allowed
that
to
happen
and
and
exactly
same
thing
for
the
tweet
processor.
B
There
are
some
old
tweets
in
here
and
we're
gonna
start
the
tweet
provider,
and
what's
going
to
happen
in
here
is
this
is
an
http
one.
You
see
the
same
thing
and
I
use
the
term
football
and
for
reasons
that
we
are
recording
this
tweet,
I'm
actually
not
going
to
open
the
ui,
because
I'm
embarrassed
what
could
be
out
there,
but
I'm
gonna
open
one
for
for
dapper
that
for
term
dapper
that
I'm
actually
already
running
on
a
server.
B
This
is
deployed
on
kubernetes
and
I'm
gonna
come
back
later.
Show
you
how
I've
done
that
you
will
see
a
number
of
of
tweets
and
if
you
act,
if
you're
going
to
tweet-
and
please
be
nice,
don't
say
something
that
will
embarrass
me
and
so,
if
you
tweet
something
will
automatically
come
in
here.
But
what
for
each
one
of
those
we
can
see,
for
example,
that
I
was
very
excited
about
the
spiffy
support
and
oppa.
B
B
Maybe
they
were
retweeting,
so
it's
hard
to
tell
if
they
were
excited
about
it
or
not.
But
the
sentiment
is
there
it's
kind
of
not
the
function
of
the
application.
The
one
thing
I
want
to
show
you
is
that
in
the
entire
code
there
was
no
mention
of
any
tracing
right.
Our
code
was
very
simplistic,
but
what
we
were
able
to
do
is
within
your
application.
It
actually
created
the
map
of
these.
So
for
each
one
of
the
services
we
can
drill
down,
identify
what
was
happening.
We
can
switch
to
logs.
B
B
Are
we
almost
out
of
time,
so
I'm
going
to
switch
quickly
to
this?
Actually,
let's
see
if
somebody
posted
something
okay,
nobody
did
all
right,
oh
brandon,
so
let's,
let's
go
back.
The
entire
demo
is
100
reproducible
and
it
walks
you
through
each
one
of
those
steps.
You
can
go
to
this
short
link
or
just
scan
the
the
barcode,
the
qr
code.
B
It
will
walk
you
through
the
creation
of
the
cluster
and
and
if
you
don't
have
one,
as
well
as
configuring,
of
the
different
components
and
deploying
of
the
application,
the
let's
talk
about
for
integration
very
quickly
or
skip
that
even
a
couple
of
things
that
the
project
is
doing
right
now
with
a
stable
set
of
apis
with
this
new
release,
which
kind
of
made
some
changes
in
api.
So
at
this
point
the
state
the
api
is
stable.
We've
delivered
access
control
and
service
identity,
like
was
already
talking
about.
B
B
We
have
also
announced
a
project
transition
to
an
open
source
governance
to
a
vendor
mutual
kind
of
way
of
looking
at
this
project,
making
sure
that
this
is
sustainable
over
time.
So,
what's
next
kind
of
by
by
the
end
of
the
year,
are
we
looking
to
release
a
release?
Candidates
of
the
1.0?
This
is
based
on
the
feedback.
We've
got
from
customers
and
you
people
or
users
using
this
in
the
real
world
there's
we
want
to
definitely
start
focusing
more
on
addressing
the
friction
from
the
real
world
use
cases.
B
So,
as
people
kind
of
more
and
more
are
taking
this
to
a
to
production
deployment,
they
feed
us
information
and
we
kind
of
making
sure
that
this
is
the
highest
priority
to
make
sure
that
this
deployments
are
successful.
There
is
a
fair
amount
of
infrastructure
work
going
on
behind
the
project.
If
you're
going
to
be
sustainable
as
an
open
source
project,
you
need
to
make
sure
that
you
have
a
good
performance
and
performance
automation.
B
The
focus
has
been
definitely
on
the
on
the
developer.
So
far,
all
right
in
closing
dapper
io
is
a
good
starting
point
for
pretty
much
anything
on
dapper.
The
project
itself,
like
I
said,
is
hosted
on
on
github,
so
github.com
forward,
slash
docker.
There
is
a
chat
on
getter
as
well
as
twitter
kind
of
monitoring
going
on.
So
looking
forward
to
hear
you
there's
a
few
videos
about
dapper
that
I've
kind
of
collected
into
a
playlist
that
you
can
access
if
you
can't
find
anything
else.
B
A
Cool
awesome.
Thank
you
for
that
great
presentation.
We
now
have
some
time
for
questions.
If
you
have
a
question
that
you'd
like
to
ask
reminder
to,
please
drop
it
in
the
q,
a
tab
on
the
bottom
of
your
screen
and
we
will
get
through
as
many
as
we
can
so
right
now.
There
are
a
few
questions.
The
first
one
is,
is
dapper
production
ready,
if
not
any
idea,
when
it
can
reach
production,
ready
stages.
We
have
a
project
starting
this
month
and
we're
thinking
of
using
dapper,
for
it.
B
Yeah
so
like
with
any
open
source
project,
you're,
you're,
you're
kind
of
working
on
the
zero
dot,
dot
releases,
right
and-
and
it's
kind
of
assumed,
I
think
that
that's
probably
not
production
grade,
but
what
happens?
Customers
actually
deploy
this
in
production,
so
we
have
a
a
few
customers
that
went
with
dapper
to
production.
B
I
I
would
say,
depending
on
the
use
case,
if
you're
going
to
be
running
monitoring
system
for
nuclear
power
station,
I
would
probably
wait
a
little
longer,
but
if
you're
looking
for
some
kind
of
monitoring
application
with
ability
to
reprocess
the
data,
if
we
find
something
that
definitely
ready
for
that
so
yeah,
I
think
we're
getting
very
close
there.
I
think
rc
one
definitely
is
intended
to
be
a
production
group.
B
B
B
Oh,
I
would
like
to
know
more
about
this,
so
the
service
invocation
in
a
cluster
can
give
you
some
guarantees
of
transactions
depending
on
what
you
do,
but
I
think
I
would
want
to
probably
understand
a
little
more
what
that
looks
like
if,
if
we
talk
talking
about
like
a
secondary
tertiary
service
invocation
and
having
some
guarantees
around
that,
I
think
right
now.
That's
not
that's
not
supported
or
that's
not
an
option.
B
A
A
All
right:
well,
let's
go
ahead
and
wrap
that
up.
Thank
you
mark
for
a
great
presentation
and
q,
a
that
is
all
the
time.
That
is
all
the
time
we
have
for
questions
today
and
thank
you.
Everyone
for
joining
us,
the
webinar,
recording
and
slides,
will
be
online
later
today
and
we
are
looking
forward
to
seeing
you
at
a
future.
Cncf
webinar
have
a
great
day
thanks.