The Brief History of ChatOps at StackStorm (and How We Got Here)

February 25, 2016
by Evan Powell

These days ChatOps has become all the rage. In this blog I’ll talk a little bit about how we came to be here – in a leading position when it comes to ChatOps adoption for operations. And I’ll point you to some resources from users and our own engineers to learn more.

The history lesson will be brief, I promise.

We started StackStorm after observing that existing solutions in the devops universe were generally point solutions, often evolved from scripts and other projects that DevOps engineers wrote to make their own lives easier. And that’s a great way to build a solution that appeals at least to those types of users for those specific use cases.

What we saw was that while there were leaders within certain segments amongst those tools, there was no clearly adopted pattern for the wiring that tied all these tools together. Moreover, with our backgrounds in enterprises we knew that wiring together extremely heterogeneous environments is always a challenge. The enterprise is more a brownfield than a greenfield.

A quick shout out to teams at Facebook and at WebEx Spark and all those other early interviewees that taught us so much about event driven automation. And if you want to join a non commercial Bay Area meet-up about the subject and hear speakers from organizations like Facebook and LinkedIn and Netflix, please join here:
http://www.meetup.com/Auto-Remediation-and-Event-Driven-Automation/ 

So – where does ChatOps join the story?

ChatOps is a huge movement in DevOps – and crossing into the enterprise. An analyst recently told me that 2016 is a the year of ChatOps and I tend to believe him.

To get going ChatOps experimenters are tying together one or two or three systems either directly into Slack or via Hubot, Lita, Err or another fairly friendly bot. And by doing so they are starting to experience the power of ChatOps.

It is what happens next, when they then try to tie together most of their environment, that they run into barriers. These barriers include:
Tying oneself too closely to a single chat vendor
Needing a little more smarts in processing what is happening before alerting, and often interrupting, the humans
Spending significant effort to integrate and then update integrations with underlying systems
Requiring human sign off and wanting that sign off to address an entire workflow, as opposed to a single step action.

In short – the reason that StackStorm is getting rapid adoption for ChatOps is that underneath your ChatOps – you need an event driven automation platform.

Here are some useful resources from StackStorm and other engineers about ChatOps:

• The promise and peril of direct to chat or bot centric ChatOps (from our CTO Dmitri Zimine)
• Bringing the humans into the loop via approvals (from StackStorm user Igor Cherkaev)
• Perspectives on ChatOps from the real world – James White, Sally Lehman, and StackStorm alumni James Fryman
• Can Microsoft’s Yammer work with StackStorm chatops (from StackStorm engineer Edward Medvedev)
• Giving your StackStorm powered bot some intelligence via rules and alias capabilities (also from StackStorm engineer Edward Medvedev)
• Using StackStorm based ChatOps to manage content in StackStorm (from StackStorm user Jon Middleton):
• Patterns of chatops adoption – how ChatOps can help you see and refactor your automations (from StackStorm user Joe Topjian):
• ChatOps bit by bit (by StackStorm alumni James Fryman):

As you can see, there are a lot of resources on the adoption of ChatOps including various patterns and considerations available on the StackStorm blog.

Thanks for reading. Please provide feedback. And if you have an idea for an interesting blog about your experience with StackStorm or ChatOps or event driven automation more broadly, please ping me directly @epowell101 or via the ST2 Slack community.

Evan