No problems here understanding his English. Thanks to both of you for the presentation. After seeing the video some questions that come up are: How Dapr Actor compares to Akka.Net Does Dapr pub/sub help handling cases like message ordering guarantee, acknowledgments, retries, idempotency Is it production ready ... I guess for most of them I will be able to find answers online and in the docs.
I am building a .net agent that runs locally on a pc and talks to IoTHub. I don't want to use Docker or Edge. Does Dapr offer any advantages for this scenario? If so, how should dapr be deployed with the application?
I have never come across any example of calling a secured webapi from an mvc app using dapr .netsdk. Why has security been overlooked so far in dapr development?
Why in the world do you need docker to use the Actors in Dapr??? Really bad design decisions there, as we know MS has other Actor solutions that don't require docker. An all docker solution is fine as well, but a mostly .net core solution is needed as well.
Dapr provides the actor framework to developers in any language as core functionality of actor framework is in the Dapr runtime. Docker is not a requirement to run Actors. Dapr runs a placement service which distributes actor instances across your app instances. Please see github.com/dapr/docs/tree/master/concepts/actors#actor-placement-service
If you don't want to use the Dapr abstraction of the Actor system you are free to just use your own (i.e. Service Fabric, Orleans or Akka.Net) and still use other Dapr building blocks. The Dapr building blocks are opt-in. Also Dapr itself doesn't require Docker if you run everything in self hosted mode. Instead of the sidecar container in a k8s pod, Dapr will use a sidecar process when you run it in a self hosted manner. There is also some discussion going around hosting Dapr on top of Service Fabric as well. Long story short, Dapr is just an abstraction of an actor runtime. The actual implementation is done via Pub/Sub and State components which make up the Actor building block. You are free to choose the Pub/Sub and State components for your system. Much like Lego blocks.
![Digital Circus Episode 4 [TRAILER]](http://i.ytimg.com/vi/abZtsmMUbJo/mqdefault.jpg)
No problems here understanding his English. Thanks to both of you for the presentation.
After seeing the video some questions that come up are:
How Dapr Actor compares to Akka.Net
Does Dapr pub/sub help handling cases like message ordering guarantee, acknowledgments, retries, idempotency
Is it production ready
... I guess for most of them I will be able to find answers online and in the docs.
Does Dapr integrate well with RedHat OpenShift ?
Not to be a jerk or anything but Closed Captions in English (not the auto generated ones) would have been real helpful here.
Agree, his English isn't terrible, but it's pretty hard to follow at times.
The auto generated ones are from youtube and not by the channel, too bad Google's algo can't understand and transcribe correctly :)
I am building a .net agent that runs locally on a pc and talks to IoTHub. I don't want to use Docker or Edge. Does Dapr offer any advantages for this scenario? If so, how should dapr be deployed with the application?
I have never come across any example of calling a secured webapi from an mvc app using dapr .netsdk. Why has security been overlooked so far in dapr development?
Why in the world do you need docker to use the Actors in Dapr??? Really bad design decisions there, as we know MS has other Actor solutions that don't require docker.
An all docker solution is fine as well, but a mostly .net core solution is needed as well.
Dapr provides the actor framework to developers in any language as core functionality of actor framework is in the Dapr runtime. Docker is not a requirement to run Actors. Dapr runs a placement service which distributes actor instances across your app instances. Please see github.com/dapr/docs/tree/master/concepts/actors#actor-placement-service
If you don't want to use the Dapr abstraction of the Actor system you are free to just use your own (i.e. Service Fabric, Orleans or Akka.Net) and still use other Dapr building blocks. The Dapr building blocks are opt-in. Also Dapr itself doesn't require Docker if you run everything in self hosted mode. Instead of the sidecar container in a k8s pod, Dapr will use a sidecar process when you run it in a self hosted manner. There is also some discussion going around hosting Dapr on top of Service Fabric as well.
Long story short, Dapr is just an abstraction of an actor runtime. The actual implementation is done via Pub/Sub and State components which make up the Actor building block. You are free to choose the Pub/Sub and State components for your system. Much like Lego blocks.