Amazon Web Services offers the Amazon Simple Notification Service (SNS) which provides pub/sub messaging and push notifications to iOS and Android devices. It is meant to operate in a microservices architecture and which can support event-driven contingencies and support the decoupling of applications.
$0.01
per 1 million
Apache Pulsar
Score 9.3 out of 10
N/A
Apache Pulsar is a cloud-native, distributed messaging and streaming platform originally created at Yahoo! and now an Apache Software Foundation project. It is free and open source, available under the Apache License, version 2.0.
N/A
RabbitMQ
Score 9.3 out of 10
N/A
RabbitMQ, an open source message broker, is part of Pivotal Software, a VMware company acquired in 2019, and supports message queue, multiple messaging protocols, and more.
RabbitMQ is available open source, however VMware also offers a range of commercial services for RabbitMQ; these are available as part of the Pivotal App Suite.
Amazon Simple Notification Service (SNS) is well integrated in AWS and has been there since the early days of public cloud. It is a cost effective and very inexpensive solution to meet the needs of event notifications and custom messaging. Wish to share that there is …
I worked with Adobe campaign 2 years ago and comparatively, SNS is way better and easier to integrate with. There's a lack of latency with SNS and better customer support. Easier to group with subscriptions and easier to work from the command line with the use of the SDK. All …
SNS helps in integrating with other AWS components which are used in development such as Lambda, APIGW, S3 and DynamoDb easily. If used with third party software like PagerDuty, it makes the development and integration more complex. It is used mostly for publishing and …
Amazon Simple Notification Service and PagerDuty have been used by various organizations. Amazon SNS is ideal if you're within an AWS environment. PagerDuty is used when we are working outside of Amazon Web Services. Though PagerDuty is more expensive than Amazon SNS they do …
We have looked at other service providers, including the local service providers as well, but Amazon SNS stood ahead of all in terms of service availability across the globe and cost-effective plans per notification SMS. Moreover, we can also use Amazon SNS along with other AWS …
Common confusion between SNS and SQS. SNS directs information to its subscribers without any effort on the subscribers or individuals' end. SQS gathers the information and then the individual has to almost go find it. They do similar things but in a space where information can …
We have opted ultimately for AWS SNS once configuration was set topics and subscriptions setup. Site 24 and US Monitor are considerations to this product, but incur cost outside of Amazon, so not best for starting up for our needs.
The main reason we chose Amazon SNS is for easy integration with all the workflows in AWS. The other alternatives can be (and really are) best in specific points, but the main strength of SNS is that is one service of AWS, so we don't need to complicate things in our …
Our company prioritizes using AWS offerings unless there is a strong use case for using something within Azure. SQS is a similar service that solves different problems and we are using it in conjunction with SNS.
We use EC2 instances to train ML model against a heavy volume of data. When the model is trained (i.e. loss reduces to a certain level), we push notification to all the stakeholders to notify them the new model is available. To achieve it, SNS is the most simple and cost …
Many products, including PagerDuty, can be used to notify stakeholders when alarms are triggered. SNS is only suitable for non-emergency email alerts, and integration with CloudWatch is its only advantage. If you want to be notified of an issue by email, SNS can be configured …
SNS is much more customizable compared to SES and allows for many more delivery methods. While it is better for email-based notification services, not being able to send notifications via SMS limits your app functionality considerably. Being able to switch message delivery …
As I mentioned previously, I wish we had gone with a different service such as a Mixpanel or OneSignal as they are reputable in the space and are known for their strong support and documentation. AWS SNS was the way to go for us at the time we chose it due to the fact that we …
RabbitMQ has a few advantages over Azure Service Bus 1) RMQ handles substantially larger files - ASB tops out at 100MB, we use RabbitMQfor files over 200MB 2) RabbitMQ can be easily setup on prem - Azure Service Bus is cloud only
It is very easy to use as it has a simple function to connect and use RabbitMQ. It is having Fast Learning curve, Any newbies can learn it in a week or month. It is having proper documentation, we are able to find all the details about its functionality and usage of it. The …
I have not used other products other than a roll-your-own solution. The Selection of RabbitMQ was made before I began working on the project but I was able to leverage it well without making major changes to the existing apps. This was particularly helpful in lowering risks. I …
For basic use cases, SQS is way easy to deploy and maintain compared to RabbitMQ. RabbitMQ can cover a lot more use-cases but actually, we did not face specific scenarios that make it necessary to come back to RabbitMQ.
It is just better documented and seems a better fit given that is done using erlang. PubSub+ low level approach seems unsafe. They work with custom hardware whereas Pivotal RabbitMQ seem a better fit for generic hardware (cloud).
Honestly, though we're still trying out Kafka and Pulsar, I'd go with them for message broker and as traffic buffers. We are only still using RabbitMQ because it's hard to transition off after writing tons of code custom-built for RabbitMQ. Kafka is better because it's way more …
None of the options in the list are really similar products. We use Apache Camel in conjunction with RabbitMQ and we also use Oracle Integration Cloud and WSO2 for messaging. Integration Cloud is SaaS-based and low code, so it's drastically different in that regard. WS02 is …
Using SNS for any notification use case where available is the default and defacto solution. It directly integrates with SES to configure both incoming email and email delivery responses.
Additionally, any notifications, such as CloudWatch alarms, are a good use case for SNS topics and allow us to fan out delivery as needed (pagerduty, email, etc)
If you are looking for a message broker, RabbitMQ is pretty good. Its API lets you create tons of queues on demand and publish to all of them at once, while you can have 10+ consumers on each queue. It also does a good job of absorbing bursts of traffic. We've seen our queues get backed up to 3 million messages with no problem. In the modern era of GDPR, you may run into problems with keeping messages encrypted out of the box in-flight and at-rest with RabbitMQ. Not saying it's impossible, but it's tough to set up and you have to pay a high overload.
What RabbitMQ does well is what it's advertised to do. It is good at providing lots of high volume, high availability queue. We've seen it handle upwards of 10 million messages in its queues, spread out over 200 queues before its publish/consume rates dipped. So yeah, it can definitely handle a lot of messages and a lot of queues. Depending on the size of the machine RabbitMQ is running on, I'm sure it can handle more.
Decent number of plugins! Want a plugin that gives you an interface to view all the queues and see their publish/consume rates? Yes, there's one for that. Want a plugin to "shovel" messages from one queue to another in an emergency? Check. Want a plugin that does extra logging for all the messages received? Got you covered!
Lots of configuration possibilities. We've tuned over 100 settings over the past year to get the performance and reliability just right. This could be a downside though--it's pretty confusing and some settings were hard to understand.
At times you receive access denied errors which are annoying.
Rarely do you receive internal failure errors where you can't access the information. It is rare but it does happen.
You are required to add an MWS Authentication Token every so often. I wish it would pull that information automatically for you so you don't have to go searching for it.
It breaks communication if we don't acknowledge early. In some cases our work items are time consuming that will take a time and in that scenario we are getting errors that RabbitMQ broke the channel. It will be good if RabbitMQ provides two acknowledgements, one is for that it has been received at client side and second ack is client is completed the processing part.
It is useful for applications developed using event driven architecture. It helps in tracking and logging the events in a very timely and efficient manner. The dashboards are a little difficult to implement. But overall it is very easy to integrate with other AWS services like Lambda, API GW, S3 and DynamoDB. The permissions to access should be resolved before using it.
RabbitMQ is very easy to configure for all supported languages (Python, Java, etc.). I have personally used it on Raspberry Pi devices via a Flask Python API as well as in Java applications. I was able to learn it quickly and now have full mastery of it. I highly recommend it for any IoT project.
The AWS documentation is well maintained and has lots of information which makes it easier for developers to refer to and develop applications in a fast efficient manner. It is well documented with examples which is easy to understand and implement. You can also get help by posting into forums from like-minded developers.
I gave it a 10 but we do not have a support contract with any company for RabbitMQ so there is no official support in that regard. However, there is a community and questions asked on StackOverflow or any other major question and answer site will usually get a response.
Amazon Simple Notification Service (SNS) is well integrated in AWS and has been there since the early days of public cloud. It is a cost effective and very inexpensive solution to meet the needs of event notifications and custom messaging. Wish to share that there is considerable number of developers who can easily build solutions using AWS SNS. So, training costs are minimal. Other solutions are emerging and we are seeing a great usage especially of Firebase notifications because of its very neat integration with open source cross platform hybrid app frameworks like ionic, xamarin. SNS needs to become better and should have plugin support for the mobile application developers using low code/no code tools too.
It is very easy to use as it has a simple function to connect and use RabbitMQ. It is having Fast Learning curve, Any newbies can learn it in a week or month. It is having proper documentation, we are able to find all the details about its functionality and usage of it. The Features of RabbitMQ are providing are matching with our business requirements.
Cost of alert calls to the different stakeholders across different geographies have gone down since using Amazon SNS.
Amazon SNS has saved a lot of time for the employees that they used to spend to call multiple stakeholders so they can now focus more on productive tasks.
Amazon SNS usage needs prior knowledge of programming.
Earlier we had a problem with missing work items with our own implementation but later using RabbitMQ is solved a problem. Now our job processing mechanism is highly reliable.
We also had a problem with scaling, processing 1k work items per second. RabbitMQ helped us to scale well with increasing work items.