4 ms·

Speaking of this has anyone had much experience with Dapr (https://dapr.io/ https://dapr.io/) before? I always thought this was a particularly interesting appr

by mdhb 3y ago

Speaking of this has anyone had much experience with Dapr (https://dapr.io/ https://dapr.io/) before? I always thought this was a particularly interesting approach from Microsoft where they use this pattern to essentially take the complexity of micro services and instead try and keep it as simple as a normal .NET application but (and I think this is the clever part) in both a vendor and language neutral way. But all of a sudden it means you can start removing all kinds of cruft and random SDKs from your codebase and push almost all of your interactions with the outside world into something like this .

jiggawatts 3y ago
I saw that Dapr was a side-car instead of an SDK, so I've avoided it for now. For comparison, most other microservices frameworks such as Service Fabric or Azure Functions generally ship as an in-process SDK. The problem with having Dapr being a separate thing that my code has to communicate with over the network is that this basically triples the number of hops in an environment that already has too many network hops. As a former game developer used to replacing divisions by multiplications with a reciprocal to save precious clocks, the design of Dapr makes me... itchy.
- valzam 3y ago
  The difference between Game (engine) dev and modern microservice development is pretty staggering. It actually cuts both ways. As a webdev when I dabbled with some OpenGL programming it actually felt amazing how much stuff you can cram into 1/60th of a second when it's all in-process or at worse has to be shuffled between CPU and GPU. When you are used to anything useful taking 10-100 seconds due to network hops and/or having to access a RDBMS it's very reassuring to know that actually, computers are really fast.
- lijok 3y ago
  You wouldn't use dapr for game dev. You would use it in systems where the added latency (very little by the way) does not matter.
  - jiggawatts 3y ago
    Microservices are surprisingly common in game server platforms. Also, I would argue that latency almost always matters. Those microseconds add up faster than you think. You have to factor in things like TCP slow start, congestion issues, buffering, the extra CPU spent encoding/decoding, etc… Not to mention that it rapidly becomes impossible or impractical to do things like process requests in a streaming fashion, so for large requests you can’t overlap the stages of a pipeline. You can easily bloat out a “1 second task” into minutes without ever knowing where you went wrong. “We’re following best practices!” you say. “Oh, is that why I’ve been waiting ten seconds for the little spinner while the site is processing a 1 KB transaction using 5 GHz CPUs?”
    - lijok 3y ago
      > Microservices are surprisingly common in game server platforms. Yes, but you wouldn't use dapr for game dev. > Also, I would argue that latency almost always matters. Strongly disagree there. For every interesting business out there, there's 99 boring ones for whom sub-second added latency absolutely does not matter (not that dapr would add that much latency).

by mdhb 3y ago

jiggawatts 3y ago

I saw that Dapr was a side-car instead of an SDK, so I've avoided it for now. For comparison, most other microservices frameworks such as Service Fabric or Azure Functions generally ship as an in-process SDK. The problem with having Dapr being a separate thing that my code has to communicate with over the network is that this basically triples the number of hops in an environment that already has too many network hops. As a former game developer used to replacing divisions by multiplications with a reciprocal to save precious clocks, the design of Dapr makes me... itchy.

valzam 3y ago
The difference between Game (engine) dev and modern microservice development is pretty staggering. It actually cuts both ways. As a webdev when I dabbled with some OpenGL programming it actually felt amazing how much stuff you can cram into 1/60th of a second when it's all in-process or at worse has to be shuffled between CPU and GPU. When you are used to anything useful taking 10-100 seconds due to network hops and/or having to access a RDBMS it's very reassuring to know that actually, computers are really fast.
lijok 3y ago
You wouldn't use dapr for game dev. You would use it in systems where the added latency (very little by the way) does not matter.
- jiggawatts 3y ago
  Microservices are surprisingly common in game server platforms. Also, I would argue that latency almost always matters. Those microseconds add up faster than you think. You have to factor in things like TCP slow start, congestion issues, buffering, the extra CPU spent encoding/decoding, etc… Not to mention that it rapidly becomes impossible or impractical to do things like process requests in a streaming fashion, so for large requests you can’t overlap the stages of a pipeline. You can easily bloat out a “1 second task” into minutes without ever knowing where you went wrong. “We’re following best practices!” you say. “Oh, is that why I’ve been waiting ten seconds for the little spinner while the site is processing a 1 KB transaction using 5 GHz CPUs?”
  - lijok 3y ago
    > Microservices are surprisingly common in game server platforms. Yes, but you wouldn't use dapr for game dev. > Also, I would argue that latency almost always matters. Strongly disagree there. For every interesting business out there, there's 99 boring ones for whom sub-second added latency absolutely does not matter (not that dapr would add that much latency).