Azure Service Bus vs. Google Cloud Pub/Sub

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

If you want to stream high volumes of data, be it for ETL streaming or event sourcing, Google Cloud Pub/Sub is your go-to tool. It's easy to learn, easy to observe its metrics and scales with ease without additional configuration so if you have more producers of consumers, all you need to do is to deploy on k8s your solutions so that you can perform autoscaling on your pods to adjust to the data volume. The DLQ is also very transparent and easy to configure. Your code will have no logic whatsoever regarding orchestrating pubsub, you just plug and play. However, if you are not in the Google Cloud Pub/Sub environment, you might have trouble or be most likely unable to use it since I think it's a product of Google Cloud.

• 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

• With a pub/sub architecture the consumer is decoupled in time from the publisher i.e. if the consumer goes down, it can replay any events that occurred during its downtime.
• It also allows consumer to throttle and batch incoming data providing much needed flexibility while working with multiple types of data sources
• A simple and easy to use UI on cloud console for setup and debugging
• It enables event-driven architectures and asynchronous parallel processing, while improving performance, reliability and scalability

Incentivized

• 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

• Would be nice if the queue could be extended beyond 7 days.
• We found it a bit tricky replay unacknowledged messages when needed.

Incentivized

It serves all of our purposes in the most transparent way I can imagine, after seeing other message queueing providers, I can only attest to its quality.

It has many libraries in many languages, google provides either good guides or they're AI generated code libraries that are easy to understand. It has very good observability too.

I have never faced a single problem in 4 years.

It's very fast, can be even better if you use protobuf.

They have decent documentation, but you need to pay for support. We weren't able to answer all our questions with the documentation and didn't have time to setup support before we needed it so I can't give it a higher rating but I think it tends to be a bit slow unless you're a GCP enterprise support customer.

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

Having used Amazon Web Services SNS & SQS I can say that even if the latter may offer more features, Google Cloud Pub/Sub is easier to use. On the other hand, usage of SNS & SQS as well as documentation and troubleshooting is easier with the AWS solution. Since we are not using GCP only for Pub/Sub the choice depends on other variables.

Incentivized

You can just plug in consumers at will and it will respond, there's no need for further configuration or introducing new concepts. You have a queue, if it's slow, you plug in more consumers to process more messages: simple as that.

• 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

• Increased Efficiency with reliable and Google managed services up all the time wit Disaster Recovery in place as well
• Definitely Lower costs being a cloud based solution and easier to setup
• Faster Project delivery and go to market plan for the business use cases basis this technology at the back end

Incentivized