The Rise of the Helpful Operational Bots: ChatOps

ChatOps: Chat as the primary communication and workflow medium [for operations]

– Jimmy Cuadra, author of Lita Chat Bot

Over the last number of years, the idea of a conversational interface to technology has entered the mainstream conscience. As is often the case, many of the ideas that get neatly packaged up into consumer facing technology have been knocking around for a long time, and conversational interfaces are no different. For the rise of conversational bots, we need to step back a little and think about bots in general, and in particular their most common manifestation in technology teams – that of ChatOps.

While some of the concepts surrounding ChatOps has been around for a long time, it is fair to say that the idea only really began to get traction within technical communities when Jesse Newland gave a talk on ChatOps at Github during  PuppetConf 2012. Since 2012 we have seen a growth in interest in the new use of bots within operations.

Now it is important to say that we view ChatOps as a logical extension of DevOps. As always people are getting the opportunity to build on the work of those that have gone before.

The Business Value of ChatOps

On a purely commercial level, rolling ChatOps out in an organisation has the potential to provide a large number of benefits. In most of the conversations we have that touch on ChatOps people highlight the social and technical benefits. As Jason Hand points out in his ChatOps book, teams see increased collaboration, sharing of knowledge, visibility, learning and empathy on the social side. Jason also notes that on the technical side benefits include increased automation, security and communications.

These are all welcome and laudable benefits, and, as noted already, are very much in keeping with any reasonably mature DevOps approach.

However, there is an underlying business value that will, in the long run, bring about a shift towards ChatOps in the enterprise that will be even more pronounced than what we are already seeing with general DevOps approaches.

We live in an era in which systems are becoming increasingly more complex. Such complexity makes understanding decisions such as the reasoning behind, timing and sign off of a technical change ever more important. In many companies this process, even now, still relies on a technical change board, mainly driven by a very traditional IT function. At the same time the pressures on business units to innovate faster are continuously rising. While DevOps has gone a long way to addressing these pressures, it is still not uncommon to hear concerns about increased risk due to additional automation being raised by some in more traditional IT functions. While we would argue that going faster not only reduces risk, it its beneficial overall, to those who have spent their entire careers focused on risk mitigation speed has always been a concern. There is a larger cultural question in terms of how such an organisation views its employees and its attitude towards the management of risk, which in reality is the first problem they need to solve.

Finally, we have ever increasing regulatory requirements and the respective compliance issues that such regulations will raise. The complexity of these requirements is only going to increase as the ramifications of ongoing political turbulence such as Brexit begin to work their way through legislatures around the world.

In all of these cases the core question is that of visibility and transparency on the how and why a decision has been made and a set of technologies used. ChatOps has the potential to give levels of visibility that auditors could previously only dream of, and the kind of self service capabilities that CIOs have yearned for years. You can combine full grained auditing, access controls and visibility with complete transparency and a shared experience for all users. While, in the main, people are still using a role your own approach to developing bots, we are seeing companies such as Operable and StackStorm (now part of Brocade) emerging to address many of the wider enterprise needs.

Popular Frameworks & Tools

For the purposes of this analysis it is important to differentiate between ChatOps, as being chatbots used predominantly by people within technology companies (e.g. DevOps teams, pure dev teams etc.) who may wish to create custom tooling as opposed to consumer focused chatbots.  Given this distinction we limited our scope to looking at frameworks which met two criteria – they supported one of, or both, Slack and HipChat and have source code available under an opensource license.

It will come as no surprise that Hubot is by far the most popular bot framework out there. The pull and kudos that comes from being githubs tool, combined with the attention Hubot has gotten over the last few years ensures this.

Looking closer at the remaining frameworks we see Botkit, Lita, Errbot, st2 and Cog emerging as the next tier. Botkit is somewhat of an anomaly here as it is the preferred framework from Slack, and has a wider developer base because of this. It is mentioned, but does not come up a lot in ChatOps conversations. Of the remainder Lita, Errbot, st2 (StackStorm) and Cog are all steadily growing small but strong communities.

Conclusion

ChatOps is still in its very early stages, and in general the wider enterprise is quite unaware of the potential power. We do expect to see ChatOps growing in popularity over the coming eighteen to twenty-four months, and more commercial offerings to emerge as the CIOs and compliance groups realise the wider business benefits of the approach, and DevOps teams add another set of useful tooling to help make everyone more efficient.

Disclosures: Operable (makers of Cog), Brocade (who acquired StackStorm) and Atlassian are RedMonk clients. Robot Image from PixelBay