6 ms·

Not sure about the goal of providing a hosted service cheaper than SQS. SQS is already one of the cheapest services on Earth. It's pretty hard to spend more tha

Not sure about the goal of providing a hosted service cheaper than SQS. SQS is already one of the cheapest services on Earth. It's pretty hard to spend more than a few bucks a month, even if you really try!

memset 2y ago
That is fair. Two things to validate from a biz perspective: 1. Is there some threshold where this would make sense financially (n billions of messages.) 2. Are the extra developer features (ie, larger message sizes, observability, DAGs) worth it for people to switch? Would love your thoughts - what, if anything, would make you even entertain moving to a different queue system?
- GordonS 2y ago
  Not the GP, but I also think you'll struggle to compete in the hosted service space. Maybe you could add a web admin GUI as a paid add on?
- threecheese 2y ago
  What is your target market? Cloud-native is, like the commenter said, going to be difficult to differentiate based on cost. I can see this being useful for hybrid cloud (onprem instances), functional or local testing, “localfirst” workloads, enthusiasts etc.
  - memset 2y ago
    Now you sound like an investor :) My own vision is to take a queue that is relatively dumb and make it smarter. I want it to be able to, for example, allow you to rate limit workers without needing to implement this client side. And so on for all of the other bits that one needs to implement in the course of distributed processing. I’m still figuring out the market. Very large firms spending thousands of queues? Or developers who want a one stop solution built on familiar tech? Or hosting companies who want to offer their own queue as a service?
    - mlhpdx 2y ago
      I've heard this use case come up in hybrid new/legacy products where there is a chasm between legacy scalability (probably a monolith in the compute or storage layer, or both). The "new" side needs to be able to self-regulate and if you can put that into the service-side it would it would be a helpful transition enabler (and, let's face it, given these transitions often never finish your product would be effectively sticky). I don't think the cost of queues is a problem anywhere (I'm sure it is somewhere, but not a market's worth). The problems created by queues, on the other hand, are myriad and expensive.
deleted 2y ago
[deleted]
PanMan 2y ago
This depends on your definition of few.. but SQS costs us more than the servers handling the messages… It’s cheap until you do billions of messages…

memset 2y ago

That is fair. Two things to validate from a biz perspective: 1. Is there some threshold where this would make sense financially (n billions of messages.) 2. Are the extra developer features (ie, larger message sizes, observability, DAGs) worth it for people to switch? Would love your thoughts - what, if anything, would make you even entertain moving to a different queue system?

GordonS 2y ago
Not the GP, but I also think you'll struggle to compete in the hosted service space. Maybe you could add a web admin GUI as a paid add on?
threecheese 2y ago
What is your target market? Cloud-native is, like the commenter said, going to be difficult to differentiate based on cost. I can see this being useful for hybrid cloud (onprem instances), functional or local testing, “localfirst” workloads, enthusiasts etc.
- memset 2y ago
  Now you sound like an investor :) My own vision is to take a queue that is relatively dumb and make it smarter. I want it to be able to, for example, allow you to rate limit workers without needing to implement this client side. And so on for all of the other bits that one needs to implement in the course of distributed processing. I’m still figuring out the market. Very large firms spending thousands of queues? Or developers who want a one stop solution built on familiar tech? Or hosting companies who want to offer their own queue as a service?
  - mlhpdx 2y ago
    I've heard this use case come up in hybrid new/legacy products where there is a chasm between legacy scalability (probably a monolith in the compute or storage layer, or both). The "new" side needs to be able to self-regulate and if you can put that into the service-side it would it would be a helpful transition enabler (and, let's face it, given these transitions often never finish your product would be effectively sticky). I don't think the cost of queues is a problem anywhere (I'm sure it is somewhere, but not a market's worth). The problems created by queues, on the other hand, are myriad and expensive.

deleted 2y ago

[deleted]

PanMan 2y ago

This depends on your definition of few.. but SQS costs us more than the servers handling the messages… It’s cheap until you do billions of messages…