2 ms·
When you are developing an information system but don't want to pay for SQS in development or in production; for running tests with SQLite instead of MySQL/Post
by westurner 2y ago
When you are developing an information system but don't want to pay for SQS in development or in production; for running tests with SQLite instead of MySQL/Postgres though.
SQS and heavier ESBs are overkill for some applications, and underkill for others where an HA configuration for the MQ / task queue is necessary.
- chromanoid 2y agoTests might be a valid use case, but doesn't seem to be the goal here and there are some solutions out there if you dont want to start a lightweight broker in a container. Why would you want to use the SQS protocol in production without targeting the SQS "broker" as well? The timing and the AWS imposed quotas are bound to be different. There are plenty brokers that fit different needs. I don't see the SQS protocol especially with security and so on in mind as a good fit in this case.
- westurner 2y agoThe switching cost from local almost-SQS to expensive HA SQS for scale and/or the client. SQS is not a reliable exactly-once messaging protocol like AMQP, and it doesn't do task-level accounting or result storage (which SQLite also solves for). Apache Kafka > See also: https://en.wikipedia.org/wiki/Apache_Kafka https://en.wikipedia.org/wiki/Apache_Kafka
- chromanoid 2y agoSQS is not particularly expensive. I don't know where you are getting at. I work on a project with SQS and I worked with RabbitMQ, ArtemisMQ and other MOM technologies as well. At least once delivery is something you can achieve easily. This would be the common ground that SQS can also provide. The same is true for Kafka.