>> Hey friends. Do you know that Dapr is
a portable event-driven serverless runtime
that makes it easier for you to build resilient,
stateless, and stateful microservice
applications that run on the Cloud and the Edge?
Even better, you can use it with
your favorite languages and your favorite frameworks.
Aman and Yaron are here to introduce
this new distributed application runtime today on Azure Friday.
[MUSIC]
>> Hey folks, it's Azure Friday. I'm Scott Hanselman.
I'm here with Ammon and Rauner and we're going to talk about dapr,
D-A-P-R. What does that stand for?
>> Distributed application runtime.
>> Okay. There's a lot of distributed applications.
There's a lot of runtimes.
There's a lot of things out there that make
my distributed application building better.
What does this add to me?
>> So dapr runs alongside
your application either as a sidecar process or container.
It gives you these capabilities like
state management, pub/sub, service discovery,
things that developers are looking for
when they're building their distributed applications,
and because it communicates over HTTP or gRPC ,
it's basically friendly to any language on there.
>> So HTTP, gRPC, it's agnostic.
>> Yes.
>> Any framework, any language,
but there are other frameworks that helped me do
these distributed things like Steeltoe and Spring Boot,
and I can list out
a half dozen different things that are prescriptions.
How opinionated is this and doesn't
mean that I have to stop using something I'm already using?
>> Definitely not. Dapr is really friendly to
all these frameworks because it's really lightweight,
and it runs next to your application that can just
run with your Spring Boot application.
You can take as many features as you want from dapr.
It doesn't need to be all or nothing.
So if you just want pub/sub or if you just want state management,
you only take these,
and these can enrich the frame that you're using,
or you [inaudible] any other.
>> That's cool. Because if you think about things
from a microservice's perspective,
it's all about the single responsibility principle.
If I make a shopping cart service or I make a product service,
I go, I really need to state repository. I should write that.
Well, but I'm a store?
It's not my job. It's not my responsibility.
Then you're saying, I could go to dapr and I
can like a cafeteria or buffet,
pick the ones that I want, and you'll handle it for me.
>> Yeah. You can use state management,
pub/sub binding, or electric availabilities,
whatever you want from it.
>> Using one of them doesn't mean I have to use them all.
>> Yeah. Correct.
>> Very cool. I see you have two laptops and two people here.
So that must mean you have an amazing demo to show.
>> Yeah. We can do that.
>> Let's go.
>> Okay. So I'll be starting.
>> So we're starting on the Mac.
>> Yeah. So here,
I have a node.js application.
Let's say, I'm node.js developer.
I want to get an event from,
let say Event Hubs and then push that event to storage.
So if I just started my application without dapr,
I would need to look up the Event Hubs SDK,
pulling into my code, test it,
see how to use it, and then the same for
whatever storage I want to use.
But with dapr, I basically only need to have
an HTTP endpoint listening on something called
Event Hubs to receive event from Event Hubs.
When I push the data that I receive to storage,
the only thing I need to do is just to
return this JSON response saying,
hey, from the Event Hubs request to that storage entity here.
These two entities are defined here.
So this is our Event Hubs component.
This is dapr file that basically
ties this component into our code.
So notice the name Event Hubs here and
the name Event Hubs on the application post.
I have my connection string here.
I'm not going to expand it because it contains the secret.
But when we're running on Kubernetes, for example,
you can Kubernetes secrets and even Azure Key Vault.
So we have secrets doors as pluggable components as well.
>> So in this case here, you're assuming that you're
running this container within the context of Kubernetes,
but I assume that any container [inaudible] system.
It's agnostic in that respect.
>> Yes. This is the Blob Storage.
So it's named storage.
So if we go back into my JavaScript application,
I'm getting events from Event Hubs
and then pushing enough to storage.
Now, this can also be AWS S3.
It can be Google Cloud Storage.
So I can basically put bindings in place and then replace them,
and then I'll just start sending off data to
other systems without actually
changing my application or even needing to restart it.
>> Yes. So it's platform agnostic in language neutral,
vendor-neutral work and use.
>> So let's see short demo.
So I'm just going to do dapr run here.
This is the dapr/cli.
So I'm going to run this thing locally.
Basically, I'm telling dapr that
my application is listed on port 3000,
and then I'm just going to launch the app here.
So this gives me a really nice experience because
both the application logs and
dapr logos are showing on the same terminal.
So I can see my application logs and the dapr logs and
the only thing that's left to do now is just to
send a message to Event Hubs.
So I have this typescript thing here,
just going to send off message.
Message sent. We'll go back here.
We can see that we got the message.
Here, we're pushing enough to Azure blob storage.
So if I go to the Azure portal,
let me just refresh that.
>> So node application is one of
the microservices is talking over to dapr,
or just any other Virtual Desktop,
and it's pushed that out there and it doesn't
know that it's talking to Azure Storage.
It's just talking to the dapr.
>> Yeah. It's talking to a very generic thing storage.
>> A very generic thing, that was quite simple.
>> Yes. Then operators can come in and switch
these bindings with the storage,
or a queue, or a message about component of their choice.
>> So we can see the file here.
So that's how we trigger bind an application,
and again, because this is all done via HTTP,
you can use any language.
This is also achievable via gRPC like we said.
>> Very cool.
>> Yeah.
>> All right. So that was on the Mac.
Why do we have a PC here?
>> So on the PC, I'm going to show you
the ASP.NET Core integration.
Like we said, it can be integrated with any platform.
So I'm going to show the ASP.NET Core integration.
>> All right. Let's do it.
>> So this is showing
a very simple not so secure banking application,
and which you have a controller,
you can get account balance using thing get route.
Then you can deposit money,
and then you can withdraw money.
There's a withdrawal method there.
>> Pretty straightforward. Typical REST API using ASP.NET Core.
>> Yes.
>> Then since a dapr provides pops up capabilities, also,
you can subscribe to a particular topic
and in response to even published to that topic,
this controller method would be
executed or triggered for you automatically.
Then it also shows the state capabilities of dapr.
You're interacting with your schedule on
the StateClient which is injected for you in the DIController.
>> That's a really nice thing just
for an idiomatic C# perspective.
Even though you've made a generic thing,
the way you've integrated here with ASP.NET with
the state client as a parameter attribute is really nice,
you're just saying, from services and I respect you for that,
because if you were being more lazy,
there would have been a line of code
where you'd go and have to right.
You get? By doing like that,
as an ASP.NET programmer,
that feels very natural.
>> Yeah.
>> So it sounds like this dapr product feels
natural to everyone on their language and it's very lightweight.
>> We wanted to be framework friendly and do
the most natural thing for that particular framework.
>> That's really cool.
>> Yeah. So this is showing
the state management capabilities you are getting this state,
and like I mentioned,
a state can be stored in
any underlying state provider configured by dapr.
It could be Redis, it could be Cosmos DB,
or it could be AWS Storage.
It can be stored anywhere.
So I'm going to just run this using the dapr/cli.
Since our dapr/cli is also class platform,
we want to develop as where they are,
whether it's Mac Windows or Linux, it works everywhere.
So you can develop your applications wherever you want to do that.
So this is running the ASP.
NET Core application,
and I'm going to make some client calls to it.
Since these are just curl calls,
that means you can spin into our application and
your other microservice could be
in any other language making cost to it.
So this is first call making,
call to get the state.
Basically, it got the balance information from there.
Now, I'm going to send another publish command to it.
Basically, it's publishing your message to withdraw topic,
which is going to invoke our controller,
and which is going to execute
that method and withdraw their money from it.
So I make that call.
It has executed, and if I credit it again,
you will see that the balance has been determined from that.
>> It's so interesting to see really
clever orchestrations like this working so smoothly,
because somehow Hello World in the past
this stuff would take
huge amounts of effort, huge amounts of work,
huge amounts of computer science,
and you basically compartmentalized all of
those services such that
we're standing on the shoulders of giants,
and I mean like computer science giants.
>> Definetely. Yeah.
>> Cool. So how do I get this and how do I start using this?
>> So it's available as
an open source framework on
GitHub and then you can download it from
there if you can go and research from there.
>> GitHub.com/dapr/dapr.
>> Okay. So D-A-P-R.
>> D-A-P-R.
>> The organization and the project is D-A-P-R and he says 1.0,
is it an active development? What's the plans?
>> It's currently experimental like most of
open source projects or when they get released.
We really want to take
community feedback and hear what other people have to
say before we announce some 1.0 links.
So we're currently at at 0.1 links.
>> So we have added solved the building blocks that we
taught they were important like pub/sub,
binding is triggering actors state management,
If a community wants to add more building blocks,
it's freely open and we can add more components to it.
>> That's cool. I'm glad that you brought it here first.
Fantastic. I am learning all about
dapr here on Azure Friday and you are to make
sure that you go to github.com/dapr/dapr.
Get involved, check it out,
provide them with feedback because this is your opportunity
to help shape the roadmap,
the future roadmap and get them to 1.0.
Today on Azure Friday.
[MUSIC]