>> Hey friends. In a previous video,
we talked about Dapper.
It's a portable event-driven serverless runtime for building
distributed applications across the Cloud in the Edge.
In this next video on Azure Friday,
I'm going to learn all about the actor capabilities
of the Dapper runtime on Azure Friday.
[MUSIC]
>> Hey folks. I'm Scott Hanselman,
and it's Azure Friday.
We're going to talk about Dapper a little bit more.
In the previous video, you should make sure that you check it out,
we talked about an overview of
this great new portable
open-source event-driven serverless runtime.
Here, we're going to spend a little bit more time
talking about the Actor Model.
Help me understand this because not everyone
necessarily is familiar with this Actor Model,
and other people might be familiar with it,
with other providers that give a perspective
on designing systems with Actors.
>> So Actor Model is a computational model in which,
it's an isolated unit of the computer instead,
and then only one method call is being processed at a time.
Actor Model within the Dapper runtime follows
the Virtual Electron Model based on
which our needs and several reliable Actor were written.
The benefit of using Actor runtime
from Dapper is that now you can write
your Actors in any language because you
communicate with the Dapper runtime
or what I should keep your GRPC.
As the core functionalities of
the Actor runtime like turn-based can come in and say,
remind as time was activation,
deactivation is all handled by the Dapper runtime.
So your actor service can be in any language.
>> So you've democratized it such that
any interaction is going to happen over GRPC and HTTP,
so that it's completely platform and language-agnostic.
>> That's true.
>> Cool. So you've got a demo of this in Kubernetes?
>> Yeah. So this is my C# factor,
and we can see that we have two methods here.
Processed data and GetData,
and this is really familiar to Service Fabric actor is developers,
because it follows pretty much the same API's.
So here in process data,
we're studying the state with
some key and then returning success and with GetData,
we're just pulling the data back.
So we have the actor deployed already
to my Kubernetes cluster and this is
a irregular communities deployment.
The only thing to note here are these notations which tell
the damper control plane to inject
the deeper side car next to the app,
and this is how the C# factor communicates with a Dapper runtime.
I have here a Python application pretty simple one.
It has a loop and a counter and with each iteration,
it's getting the state, and if there is a state,
we're assigning it to the counter then
incrementing the counter and saving it,
and here we're invoking the Dapper runtime.
So we're going to actors,
and we're evoking a demo actor with
an idea of actor 7 with these specific methods.
So really the C# factor gets its own instance of
the Dapper runtime and then the client gets his
own and they can communicate locally via local host,
and then Dapper takes care of
the distributed communications between them.
So if I go here and I take a look at my Kubernetes cluster,
I can see that they have the actor already running,
and the only thing that's left to do is just deploy
the actor client that Python application.
So I'm going to do k apply actor_client,
and we'll wait a couple of seconds until this is up and running.
>> The client starting to show up there container creating.
>> Yeah. If we take a look at the logs,
we can see that there is a counter and it's actually going,
and what I'm going to do now is just kill off the actor instance.
So I'm going to take the pod,
and I'm going to delete it.
>> We're simulating a failure?
>> Yeah. We'll wait until it gets back up,
and so already running pretty quick,
and now it can take a look.
>> So it [inaudible] itself.
>> Yeah. This is done by Kubernetes.
>> Right.
>> I can take a look at the logs,
and we can see that the counter picked up where it left because
the Dapper runtime handled the retry mechanisms,
and the resiliency and retrying and state was saved.
In this case, it was saved running.
>> So then that would be a reliable actor?
>> Yes, it's a reliable actor.
>> Dapper runtime takes care of distributing actor in
the instances that cause CR multiple service instances,
because it takes good of repartitioning.
Let's say you have five instances off-field service running,
then you act doesn't have Z distributed cross
new instances as they come up.
>> Pretty cool. This is something that is in this context we use
Kubernetes is this specific to
this container orchestrator in Dapper runtime.
>> No it can run in DC/OS,
it can run Docker Swarm,
it can run anywhere where you can orchestrate containers.
>> So you've got a reliable virtual actor model
that runs on any container orchestrator,
and it doesn't care about what language that you use?
>> Correct.
>> Yeah.
>> That's pretty cool. So this
is something that is just getting started.
You start at 0.1 version up
on github.com/daper and you want to hear from the community.
>> Sure.
>> So if you think this is as cool as we
do here on Azure Friday, go and check out.
Github.com/Dapper, talk to the team,
you're looking at part of the team right here and help them
get to 1.0 with this really exciting new technology.
We're learning all about it today on Azure Friday.
[MUSIC]