[yaronsc]

Hey e12e, Dapr is meant for both small or large setups. It's designed to handle your scale as it grows and be highly performant.

Dapr itself is a sidecar - it can be easily autoscaled by external autoscalers like Kubernetes offers, KEDA and others.

[e12e]

Hm. So there is some magic to avoid all roc calls and pub/subs going through dapr?

Eg: if I have a thousand users subscribed to a channel - only setup would involve dapr, and the rest would be dependent on my pub/sub queue manager (eg: plain redis, or rabbitmq) keeping up?

But from the [ed: dapr api microservice component] consumer viewpoint it's just "ask dapr for subscription", "ask dapper to broadcast a message" - and you're off to the races?

[yaronsc]

Having the calls go through Dapr is actually a pretty powerful feature: Dapr will handle retries and handle failures and guarantee an at-least-once delivery. For high-throughput scenarios we have a gRPC client which can see a much higher throughput than regular HTTP.

Yes, you are right: from the consumer's viewpoint, it's "ask to subscribe, ask to publish a message" and you're off.

[e12e]

So it would be fair to say that dapr scales to "fairly big" throughput - but not the right tool if your goal is in the ballpark of saturating a 10gps network with messages?

(mind, I have no such ambissions presently, just trying to get my head around what dapr is - and is not)

[SideburnsOfDoom]

> but not the right tool if your goal is in the ballpark of saturating a 10gps network with messages

If that's in any danger of happening, then you scale out not scale up. e.g. run 100 worker instances to process the messages. each one gets 0.1 gps of messages.

Microservices are good at scaling out as needed. I mean, not completely painless, but better than the alternatives.

[e12e]

Right, I know the example is somewhat hyperbolic - but one could argue that it's quite possible to build a micro service architecture around zeromq or rabbitmq - and those systems should (in theory) allow you to max out your modern hardware.

So in the sense that you might not really need micro service architecture for your regular "new thing" (ie you can run it on a modern server with 128 threads and it fits in half a terabyte of ram or some such "medium" size workload) - it's interesting to see how dapr affects you if you do need to scale.

If you struggle with N to M messaging, you might not want to multiply N and M with Y dapr nodes-because that might make your solution more difficult to scale.

That said I think there's a valid case to be made that it can be valuable to suffer a micro service architecture and the possibly massive signaling overhead - not to "scale", but to gain resiliency and stability. Failover, easier deployment of new code etc.

Basically anything that can give you "works like big iron" on whatever scraps of commodity hardware you're able to rent.

[SideburnsOfDoom]

> you might not want to multiply N and M with Y dapr nodes

That would be bad, but my understanding of the "sidecar" is that there would be M dapper nodes, each attached to a main consumer in a container. (and probably add N dapper nodes as well, if the N senders are also containerised and managed this way)

[zubairq]

So dapr reminds me of Istio here

[time0ut]

I am intrigued. Regarding pub/sub messaging, the docs are thin to say the least. It seems the user brings their own pub/sub broker. Is that correct?