Amazon Simple Queue Service (SQS) vs. Azure Service Bus

While we use AmazonSimple Queue Service (SQS) in our serverless applications, it would be a great option to handle queue management for any internet-connect application. It provides the most benefit in situations where your application or service must maintain mission-critical queue of messages or jobs. If you're already using other AWS services you will find the greatest benefit.

Incentivized

If you need a cloud-based service bus or a simple to use queue/topic/routing/pub-sub service, then Azure Service Bus is a very good choice at a reasonable price and performance. Typically on-premise we'd use RabbitMQ because it "just works", but if you're building a "cloud-first" application, then this is the one to go with. It's especially easy to integrate with if you're already embedded in the Microsoft ecosystem.

Incentivized

• SQS is reliable and fully managed. Our engineers do not have to worry about running RabbitMQ.
• SQS is very inexpensive.
• SQS allows data to be encrypted in transit, which may be required for compliance in some products.
• FIFO queues provide exactly-once processing.

Incentivized

• Acting as a basic queuing service it works very well.
• One of the best parts is that Azure Service Bus can work over HTTPS which helps in strict firewall situations. There is a performance hit if you choose to use HTTPS.
• The routing capabilities are quite good when using topics and subscriptions. You can apply filters using a pseudo-SQL-like language though the correlation filters are quick and easy options.
• Costs are very reasonable at low-ish volumes. If you're processing 10's of millions of messages a month... it may be a different story.

Incentivized

• More frequest polling will be expensive
• No detailed monitoring of queues, just current data and regular monitoring is present
• No way to fetch messages back from the queue

• The SqlFilter could be a little easier to use, but it's not terrible.
• The performance while using HTTPS for the connection is a little slow compared to direct connections using AMQP ports.
• There is a size limit to the message - unlike RMQ for instance, Azure Service Bus caps messages to 256kb on the standard tier.

Incentivized

Online blogging and documentation for SQS is great. There are many examples of implementing it and if you look hard enough, more than likely there are examples that meet the exact case with which you are working

Incentivized

To be blunt: Amazon SQS was the simplest to implement given our requirements. Other services in this space work just as well, and SQS does not have any benefits outside of being the easiest to implement when using an otherwise fully AWS stack. AWS itself even has other solutions that would work just as well, however, SQS had the most reasonable pricing model for our given situation. That will certainly not always be the case, but in several of the instances where we are using it, it just made the most sense.

Incentivized

RabbitMQ is simple and awesome... but so is Azure Service Bus. Both accomplish the same thing but in different environments. If you're building a cloud-native application - especially one that is serverless by design - Azure Service Bus is the only real choice in Azure. It works well, it's performance, and it's reasonably priced in the Standard tier. From our testing, RMQ is more performant, but it's hard to compare service-based implementations vs RMQ installed on VMs.

Incentivized

• Under the AWS Echo system, it provides great operating power to the application.
• The cost is much less for messages, and it also supports a multi-user option.
• Not for us, but for a larger organization, low throughput might become an issue for a standard queue type.

Incentivized

• Compared to open-source free software like RMQ, Azure Service Bus does have some costs to it. But the cost is reasonable.
• Also unlike RMQ, Azure Service Bus doesn't require you to stand up any hardware - so it's very easy to use and saves time/money from that perspective.

Incentivized