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:
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:
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.