Amazon Web Services (AWS) Provides the Amazon Simple Queue Service (SQS), a managed message queue service which supports the safe decoupling and distribution of different components in a cloud infrastructure and cloud applications.
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.
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.
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.
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.
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
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.
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.
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.
