Using Google Cloud Pub/Sub will mainly depend on the cloud platform used. Our client didn't choose GCP for Google Cloud Pub/Sub, if we went with AWS we would be using SNS/SQS (obviously). However, Google Cloud Pub/Sub is a better solution in the GCP services compared to self-managed solutions such as RabbitMQ for instance (it is managed by GCP and integrates with GCP solutions).
It is perfectly suited if some heavy operation needs to be automated where jobs can be queued up. Scalable app which is required to develop in a lesser time frame. Good for when users should be able to change rules more frequently without any downtime, like promotions. The server is well proven in the market. BizTalk server is the best fit if all other integration adapters are developed using Microsoft applications and if all applications are meant to be processed on a Windows environment.
BizTalk uses Microsoft Visual Studio as the IDE (integrated development environment) tool, and it's very easy to use.
The orchestration engine of BizTalk addresses resource issue very well for long-running business processes by dehydrating and rehydrating orchestration instances.
BizTalk is very easy to integrate if the development is mainly on the Microsoft software family.
It is limited to work with the same platform but with different datasets at the same time, you must request a prior security authentication.
It can sometimes lead to unexpected charges, as Pub/Sub will automatically keep on retrying messages continuously, even if failures are due to permanent code-level issues.
Message re-deliveries don't apply for ingested services like with Python based client. Push messages tried to be delivered immediately and if your service is busy dealing with some other task, it won't be done OR goes into a queue
BizTalk needs to be better at tracking down errors after the fact. Input files by default get deleted after processing successfully, unless you specifically specify that they don't. This can be an issue where you need to see what the input file contained, since you may have errors showing up in your target platform, in our case this was SAP.
BizTalk logging needs improved. It needs to be able to log the content of the messages it sends and receives. It would be good if the log had a link to the input and output files.
BizTalk needs to allow a simple way to preserve the input and output files for debugging purposes. A master setting on the orchestration would be helpful for this.
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.
Microsoft BizTalk is not an intuitive product. It requires many hours of looking through the settings to achieve what you need. Using 3rd party DLLs is a nightmare as you are forced to register them in the GAC of the server and this process is quite cumbersome just to use a DLL.
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.
BizTalk Server has been supported for more than 15 years. It is well proven in the market. Microsoft has provided excellent support with technical issues.
We did look at Jitterbit dataloader from Salesforce.com. Jitterbit seems like a pretty decent solution if you are doing a lot of uploads into Salesforce.com. However, its not nearly as flexible as Microsoft Biztalk is. Biztalk allows you to create any type of custom solution you wish, whereas Jitterbit is much more limited.
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.
