Amazon recently announced a new service called Simple Notification Service.
It provides a cheap publish/subscribe messaging system in the cloud. You can learn how to use it by visiting http://docs.amazonwebservices.com/sns/latest/gsg/
I played with it and found that the service is really easy to use, very robust and very extensible. It basically makes a publish/subscribe messaging service similar to JMS available in the cloud. Having a cheap, robust publish/subscribe messaging system can serve many purposes in the cloud. In an auto scaled environment servers go up and down depending upon traffic. Here are some of the usages I can think of in our environment:
Discover members of a cluster
We use JMX to switch on/off various services in our java webapp. JManage allows us to configure a cluster and call a method remotely on the entire cluster. That is how we flush caches, switch on/off services etc. JManage is not sufficient by itself in an autoscaled environment as it does not detect new nodes automatically. When a new node comes up, somebody needs to configure the node in the JManage cluster. You can create a topic and publish a message to it with the external dns name of the newly born server in it. This message can be then consumed by a piece of code that can add the new node in the JManage Cluster. It’s also possible to similarly remove a node by publishing a message when the instance is terminated by auto scaling.
Discovering members of a cluster is very useful in a cloud environment especially in an auto scaled environment. As Http is supported as a protocol, it’s possible call a servlet (or similar concept in other platforms) url. This opens up a lot of possibilities. You can pretty much execute anything you want.
Send email alerts without having to configure a SMTP server
Simply put, you can use SNS to send simple emails. All the email addresses need to be the subscribers of the topic, but that’s a trivial one time activity. No need to configure and maintain any SMTP server!
Some nice to haves features
There is one particular thing I find annoying about SNS. Let’s say you subscribed to a topic using the email protocol. You will get a long string identifier called subscription arn. When you want to unsubscribe this email, you cannot supply the email address and the topic, you must supply the subscription arn. That’s not a good idea. It forces applications to store the subscription arn. To me an email and a topic combination is unique enough for them to determine the subscription. It will be much easier for applications if they change the unsubscribe api to accept the topic and the email address you want to unsubscribe. I can understand that they probably want their api to be protocol agnostic, but it will be a nice to have feature.
Furthermore, you cannot set the subject of the notification email. That means, if I am using multiple notifications in application, all the notifications will have the same standard subject line – AWS Notification Message.
It would also be nice to have twitter as a protocol. We use twitter heavily for notification. Twitter allows us to get notifications via text messages. Pingdom got us into it.
