Azure Service Bus vs. Red Hat JBoss Enterprise Application Platform

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

JBoss EAP is subscription based/open source platform. It's very reliable and great for deploying high transaction Java based enterprise applications. It integrates well with third party components like mod_cluster and supports popular Java EE web-based frameworks such as Spring, Angular JS, jQuery Mobile, and Google Web Toolkit.

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

• MOD_CLUSTER integration. JBoss EAP integrates pretty well with mod_cluster. This is an intelligent load balancer especially useful in highly clustered environments.
• Supports enterprise-grade features such as high availability clustering, distributed caching, messaging etc.
• Supports deployment in on-premise, virtual and hybrid cloud environments.

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

• Difficult to replicate configuration outside of a container environment
• Still requires quite a bit of knowledge of the CLI
• Integration with deployment tools requires CLI knowledge

Incentivized

We are planning to migrate away from Jboss to Tomcat as Jboss has shown not interest in supporting OSGi which is heavily used at our shop

Incentivized

JBoss overall is easy to use. The installation and deployment of applications are quick. Documentations and support are also readily available.

Incentivized

JBoss EAP is lightweight and doesn't really consumes much physical resources. It's high performing and suites well for high transaction Java enterprise applications. The out of box performance settings are not really great and you will have to configure the settings to suite your environment to leverage it's full benefits.

Incentivized

Fast response.

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

We selected JBoss because of compatibility with EJB's. We currently are trying to reduce our footprint and will highly consider using Tomcat.

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

• Jboss EAP is easy to deploy and configure. This lead to lower cost and faster delivery.
• Even though we have large number of machines running JBoss, we have only two Jboss Administrators. It doesn't requires too much administration and maintenance on daily basis and reduces number of administrators required for large implementations.

Incentivized