If everyone is thinking the same, someone isn't thinking

Lori MacVittie

Subscribe to Lori MacVittie: eMailAlertsEmail Alerts
Get Lori MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Cloud Computing, Virtualization Magazine, SOA & WOA Magazine, Java Developer Magazine, F5 Networks, DevOps Journal

DevOpsJournal: Blog Feed Post

JSON Activity Streams and the Other Consumerization of IT

The JSON Activity Stream specification could allow the consumerization of IT to make its way into the data center

The JSON Activity Stream specification could allow the (other and oh so soon forgotten side of) consumerization of IT to make its way into the data center.

Remember when I posited that the Next-Generation Management of Data Centers Should be Modeled on Social Networking and introduced the concept of “Infrabook” – a somewhat silly-but-serious-at-the-time idea that infrastructure should get “social”?

The recent publication of JSON Activity Streams – in addition to being very exciting from an infrastructure architecture perspective – may be exactly what is needed to bring this concept to life.


Infrastructure already knows how to “speak” a variety of management languages such as SNMP and even XML, so why not adopt a simple HTTP + JSON approach to share real-time updates and notifications in the data center regarding the operational status of the infrastructure as well as the applications its designed to deliver?



For those not familiar with Activity Streams (or JSON, for that matter) let’s take a quick look at it through a fresh lens.

JSON – Javascript Object Notation – is an unstructured  data format that is (more and more) commonly used to exchange data between applications using REST APIs as well as between the client (typically a browser) and an application. It’s actually a lot like XML, minus all the really hairy nesting and schematic constraints imposed on XML. While at first used primarily to enable real-time updating of clients a la AJAX, it is more and more frequently being used on the server side of architectures and thus as a means of integration, as well. It’s fairly simple to parse and manipulate and unlike its XML predecessor is far more human-readable. JSON primarily uses a name-value mechanism for serializing data and any old-skool object-oriented programmer will see similarities in its serialization with other, past and present object-oriented serialization techniques.

A simple example of a JSON message might be:

{"person": {
  "name": "Lori",
  "gender": "Female",
  "age": "None of your business", 
  "location": "Earth", 
Pretty simple, right? I’d argue it’s far simpler than SNMP, which is often still the primary means of communicating events and alerts across a unified center management system.
Now, Activity Streams 1.0 basically says “here’s a standardized JSON format for exchanging activity data”. It includes an actor and associated information about the actor, a verb that describes what the activity comprised – with information regarding links to the activity when appropriate – and a target, i.e. where should the action take place. An activity describing the process of publishing this post, for example, would declare me the “actor”,  the URL of this post as the object to “post” (the verb) with a target encapsulating DevCentral and its blogging system. image


Now, embracing that concept – actor, verb, object and target – you can probably see how easy it would be to extend that to infrastructure and the events and notifications typically reported on in the data center. Components become actors, for example, with verbs perhaps comprising “report, notify or alert”. Objects become URLs back into logs or the system itself while targets may be specific people, systems or applications.
Consider then that instead of writing to a SYSLOG server, you’re writing an “Activity Stream” to an Infrabook server, essentially a database of activities from across the data center that can be correlated using mechanisms provided by the specification.
The JSON Activity Stream 1.0 specification allows for extensions, stating: “Other specifications MAY define new object types and verbs for use with the concepts and serializations defined in this specification. To be clear, new extension properties can be added anywhere in the JSON serialization of an object or activity.”
Given such extensibility options, it would be relatively simple to define a set of “verbs” that related to management of infrastructure. For example, we could define such activities as similar to those already commonly used for logging purposes on infrastructure today:
  • AUDIT An activity indicating a message regarding changes to the object on component actor with the target being a specific audit log, e.g. security, network, application or ops.
  • ALERT An activity indicating a message about a situation requiring attention regarding object on component actor with the target being a group or individual or system.
  • DEBUG An activity indicating a debugging (troubleshooting) message regarding object on component actor with the target being a group or individual or system.

We could also extend those common categories and come up with a few new ones that might help us better identify and prioritize messaging in Infrabook itself, such as:

  • ATTACK An activity indicating an object layer attack is occurring on component actor with the target being a group or individual or system.

For now, it’s not necessary to dive into specifics, we need only recognize that there are many ways we could slice and dice the kinds of activities occurring on infrastructure of which we want to be notified. For now it’s merely important to see how something as developer oriented – JSON – and social networking oriented – Activity Streams – could be applied to infrastructure and the data center in general. That’s the other side of devops; the side we rarely see but need to take more interest in if we’re going to evolve devops and Infrastructure 2.0 past scripts and service-enabled SDKs.


JSON Activity Streams 1.0 is an excellent example of taking developer and application-oriented technology and applying it to operations in a way that would evolve management to better fit the way in which we, as human beings, today interact online. The next generation is comfortable with the social networking paradigm and that, as much as iPads and mobile phones and always-on mentality, is the essence of consumerization of IT – the use of Web 2.0 and beyond application technology in the organization.

Remember these predictions, back in the day when Web 2.0 was the buzzword of the day?


Technologies used to power popular consumer-oriented applications will eventually saturate the corporate market.

This is leading to the "consumerization" of the enterprise market, said Gartner analysts today at the formal opening of the Gartner Symposium ITxpo 2006 here.

Technologies such as AJAX, REST and RSS  form the technical underpinnings of Web 2.0, the term used to characterize the next generation of Web applications.

-- Web 2.0: The 'Consumerization' of The Enterprise, October 2006

Applications have already adopted many Web 2.0 and social networking concepts – Salesforce.com Chatter anyone? – so it seems logical that at some point we, as in data center infrastructure folks, are also going to have to belly up to the bar of social networking and consider how to adapt its concepts to improve and evolve data center management and collaboration.

Consumerization isn’t merely having to deal with gadgets and devices penetrating the organization from consumer land, it’s adopting those technologies where and when it makes sense to do so. In the case of Web 2.0, we have yet to see that really happen in IT. But we need to if we’re going to enable the dynamic, integrated and collaborative infrastructure necessary to support an on-demand paradigm replete with hyper-connected users, applications and systems.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.