Using Twitter as a Notification Vehicle

Tweeting… it seems that everyone is doing it these days.  But, what are we tweeting about?  Is it really useful, serving a valuable purpose or does it just add to the noise of the social arena within the Internet?  Does it really change another’s life or perspective knowing that their friend is “sitting on his back porch”?

Recently, I was in a discussion with a colleague exploring the impact of mobile devices as a means of monitoring system operational health and activity.  We cited the merits of having a smart-phone and being able to check on the status of a back-end system’s activity.  We thought about the content that would most interest system managers: resource status, hung processes and Service-Level Agreement (SLA) compliance.

Soon, we realized that we were thinking too conventionally.  While monitoring these indicators can be mission-critical, due to financial penalties incurred by downtime (loss of business, vendor inconvenience, customer inconvenient), wouldn’t it be far more effective if the system could “phone home” and alert us of a problem?  We could do this with an email, but that seemed too heavy.  Most remote email systems require polling of a POP server, and it’s a heavier message exchange pattern to choose when checking for frequent updates. We simply want to receive a notification – pushed to us – as a small amount of text in a light-weight message, similar to SMS. Using text pagers would be viable but the downside is that it’s another device to carry, manage and charge.

My colleague suggested “How about a tweet?”.  At first, I dismissed the idea, thinking about the implications of running our mission-critical system and using a congested social network to handle important operational notifications.  But, then I started to think about it from a more abstract perspective, and realized that he was on to something.

Tweets are really nothing more than SMS messages over a publish/subscribe channel (of course, I’d sway this blog to an Integration Pattern!).  That is very useful, especially when more than one person could/should/would receive the message.  The value in using something like Twitter for messages is that it de-couples the integration, eliminating the source system from “knowing” who should receive the messages (read: having to maintain a notification list).  The interested parties could simply subscribe, via Twitter.

So, let’s think about what works and what doesn’t.  We can publish to Twitter via a public API.  We can remotely subscribe to the message channel and get information pushed to us.  That’s cool.  Hold it…. can everyone else who has a Twitter account also get our information?  It appears that they can.  That’s not good!  Fortunately, we could create a Twitter group and moderate access to the group.  That would solve the immediate issue of “lurkers” scoping our messages.

We still have to address the issue that the messages are sent over clear-text.  That’s going to be a limitation that we probably can’t get around.  We only have 140 characters to work with and generic twitter clients expect clear text.  After digging around, I could not find anything regarding encryption of tweets.  If we need things to be secure, we’d have to write our own Twitter client app or find another way.

To get around the “content security” issue, let’s look at what we would “tweet”; system status info.  As long as we keep the messages generic enough (don’t show IP addresses, security access information or any identifying names/info/ids), we could still make use of this technology.

I could envision messages containing references such as “FTP process to {named resource} has failed”.  That’s enough to inform an operations person of a problem, without giving up valuable information such as account ids, system addresses etc.  Another example could be “Failed to find an endpoint for process 93838”.  Without direct access to the system, a lurker would not understand the context of process “93838”, but an operations person could log in to the system and review the log history for that process.  There are ways to provide valuable information without giving out identifying details.

In retrospect, it’s not a perfect solution and could easily be compared to an SMS implementation.  The convenience aspect is that Twitter would handle the subscription to the message queue for us.  That alone could be worth considering this type of implementation.  It’s just a novel idea using a contemporary technology, but it’s not for everyone or every situation.

Leave a Reply

Your email address will not be published. Required fields are marked *


*