41–50 of 144 posts
What do people recommend? Especially for low levels of load, that doesn't require that the dispatcher and consumer are written in the same language.
Also give a shoutout to Beanstalkd (https://beanstalkd.github.io/)
Earlier quoted context omitted.
Why is that an anti-pattern? Databases have added `SKIP LOCKED` and `SELECT FOR UPDATE` to handle these use cases. What are the downsides?
as with everything, it depends on how you're processing the queue. eg we built a system at my last company to process 150 million objects / hour, and we modeled this using a postgres-backed queue with multiple processes pulling from the queue. we observed that, whenever there were a lot of locked rows (ie lots of work being done), Postgres would correctly SKIP these rows, but having to iterate over and skip that many…
Earlier quoted context omitted.
If you're using .NET I have to plug https://particular.net/ Nservicebus from particular.net. It's great at abstracting away the underlying message broker and provides an opinionated way to build a distributed system.
.Net SRE here, please no. Take 5 minutes to learn your messaging bus SDK and messaging system instead of yoloing some library that you don't understand. It's really not that hard. Also, ServiceControl, ServiceInsight and ServicePulse are inventions of developers who are clearly WinAdmins who don't know what modern DevOps is. If you want to use that, you are bad and should feel bad. (Sorry, I have absolute rage around…
It's on the friendlier end of the spectrum among the tooling I help manage, at least compared to Microsoft crap.
Either way I'm feeling quite validated by your rage, so thanks for sharing. I feel like we could be good friends.
Kafka for small message volumes is one of those distinct resume-padding architectural vibes.
Earlier quoted context omitted.
Why is that an anti-pattern? Databases have added `SKIP LOCKED` and `SELECT FOR UPDATE` to handle these use cases. What are the downsides?
as with everything, it depends on how you're processing the queue. eg we built a system at my last company to process 150 million objects / hour, and we modeled this using a postgres-backed queue with multiple processes pulling from the queue. we observed that, whenever there were a lot of locked rows (ie lots of work being done), Postgres would correctly SKIP these rows, but having to iterate over and skip that many…
Is not a low volume unless this could be done in batches of hundreds.
Kafka for small message volumes is one of those distinct resume-padding architectural vibes.
You haven't seen the worst of it. We had to implement a whole kafka module for a SCADA system because Target already had unrelated kafka infrastructure. Instead of REST API or anything else sane (which was available), ultra low volume messaging is now done by JSON objects wrapped in kafka. Peak incompetence.
Mostly people that ruminate on naive choices like REST/HTTP2/MQTT will have zero clue how the problems of multiple distributed telemetry sources scale. These kids are generally at another firm by the time their designs hit the service capacity of a few hundred concurrent streams per node, and their fragile reverse-proxy load-balancer CISCO rhetoric starts to catch fire.
Note, I've seen AMQP nodes hit well over 14000 concurrent users per IP without issue, as RabbitMQ/OTP acts like a traffic shock-absorber at the cost of latency. Some engineers get pissy when they can't hammer these systems back into the monad laden state-machines they were trained on, but those people tend to get fired eventually.
Note SCADA systems were mostly designed by engineers, and are about as robust as a vehicular bridge built by a JavaScript programmer.
Anecdotally, I think of Java as being a deprecated student language (one reason to avoid Kafka in new stacks), but it is still a solid choice in many use-cases. Sounds like you might be too smart to work with any team. =3
Earlier quoted context omitted.
NATS https://docs.nats.io/nats-concepts/overview/compare-nats
NATS/WebSockets are good for 1 publisher -> many consumer (pubsub) RabbitMQ is good for 1 producer -> 1 consumer with ack/nack Right?
RabbitMQ/Erlang on OTP is probably one of the most solid solutions I've deployed over the years (low service cycle demands.) Highly recommended with the AMQP SSL credential certs, and GUID approach to application layer load-balancing. Cut our operational costs around 37 times lower than traditional load-balancer approaches. =3
Earlier quoted context omitted.
Cloud Tasks is one of the most undervalued tools in the GCP ecosystem, but mostly because PubSub gets all the attention. I've been using it since it was baked in the AppEngine and love it for 1-to-1 queues or delayed job handling.
how do you recommend working with Cloud Tasks? raw dogging gcloud? Terraform? or something more manageable? I've been curious for one of my smaller projects, but I am worried about adopting more GCPisms.
gcloud beta resource-config bulk-export --resource-format=terraformKafka for small message volumes is one of those distinct resume-padding architectural vibes.
Earlier quoted context omitted.
Cloud Tasks is one of the most undervalued tools in the GCP ecosystem, but mostly because PubSub gets all the attention. I've been using it since it was baked in the AppEngine and love it for 1-to-1 queues or delayed job handling.
how do you recommend working with Cloud Tasks? raw dogging gcloud? Terraform? or something more manageable? I've been curious for one of my smaller projects, but I am worried about adopting more GCPisms.
Now that I'm mostly on AWS... I still use the same system. I have a thin little project that deploys to GAE and has a queue.yaml file. It sets up the cloud tasks queues. They hit my EB endpoints just like they used to hit my GAE endpoints.
As a bonus, my thin little GAE app also has a cron.yaml that it proxies to my AWS app. Appengine's cron is also better than Amazon's overcomplicated eventbridge system.
It's great.