A Common Language for DevOps
Is DevOps short for “building a bridge over shark infested waters while juggling on a unicycle?” No, no, of course not. That’s SecOps.
In the time I’ve worked at Splunk, observing the DevOps relationship has been somewhat like watching two tribes learn a common language. Communication begins with a hurried knowledge transfer session just as an application is pushed into production. It might include a short list of error codes and their descriptions or a page posted to an internal wiki with log locations. It might end as an awkward dance of hand gestures, contorted facial expressions and primitive grunting noises.
Imagine my surprise and excitement to encounter a DevOps relationship where both parties spoke the same language. Last month, it was my distinct pleasure to work with Sudip and Adam, who both work for a forward-thinking company which creates software so you can collaborate easily. Sudip and Adam presented their DevOps story and regaled us with their success using Splunk as common ground.
In between volleyball bouts, Sudip was completing development of a web service to manage a critical backbone system for all applications which rely on their core collaboration technology company-wide. The web service provides insight into server state, membership status, health and load metrics via an API. What it didn’t provide was an interactive interface for presenting this rich information to the Operations team responsible for managing it in production. Adam requested Splunk assets from Sudip before the web service could be transitioned to the Operations Applications team for care and feeding.
For Adam, life without Splunk would mean screenscraping an HTML page using adhoc scripts. The scripts would then validate and convert data back into HTML reports. This data collection and verification process alone could easily consume 10-20 minutes per outage. It also meant exhaustive documentation for every web service update. And good luck getting any historical trending. Sans Splunk, here’s what Adam would have been waist deep in:
Sudip accepted the challenge. In just 2-3 weeks, while balancing a full-time job, he downloaded a trial version of Splunk, learned how to build Splunk Apps leveraging Splunk Docs and Splunk Answers, and produced not just one, but two Splunk Apps. He designed one App for data collection with scripted inputs and the other with reports and dashboards, even integrating drill-down and form searches. How’s this for closing the gap between Development and Operations?
In the process of deploying these Apps, Sudip and Adam hammered out a standard process with their stellar Splunk Admin for building and deploying future Apps. They now have a repository for checking in Splunk Apps and defined steps for staging and validation before promotion to the Splunk production cluster. How’s that for trailblazing?
Splunk is a language for turning data into intelligence, but it was truly awesome to see Splunk as the language for turning DevOps into a true partnership. A curtsey to Sudip and Adam!

















