Why ChatOps?

Alec Cunningham
ChatOps
Published in
3 min readFeb 3, 2018

ChatOps? Aren’t we still getting used to seeing DevOp Engineer job listings? Yes. You might remember the term from a series of blog posts and projects between 2013 ~ 2016:

But it never seemed to gain the traction it needed to spur a community to form around its development. 2018 may just be the year that this occurs.

Definition: The use of trained bots for traditional DevOp and Operations related tasks, allowing custom extensions and enabling natural language communication between the bot and user.

Why Now?

In the last few years, a wide selection of chat bots have been released in nearly every language, providing support for nearly every chat service. The most obvious example, and arguably the most popular bot, would be hubot; The coffeescript open source chat bot that responds to events — its only limit is your imagination.

2016–2018’s most popular evolutions in tech could arguably be described as the following:

  • Development of mature cloud services (AWS, GCP)
  • Huge achievements in machine learning
  • A trend towards untraditional hosting and decouple infrastructure (virtualization, docker, kubernetes)
  • API driven development
  • The DevOps movement, blending the line between software and operations engineer

Of those five, four can be recognized as improvements that enable chat bots to move past slash commands, strict input validation and allow advanced integration paired with rich, interactive responses.

DialogFlow

The rapid advancement of managed services offered by Google and Amazon have enabled smaller businesses to take advantage of services previously only attainable at corporate size levels. They also continue to improve and introduce tools to make developing easier — with cloudless functions and machine learning looking to be the leaders in cloud computing in 2018.

DialogFlow Dashboard, listing an agents intents

DialogFlow, acquired by Google, allows for custom agents to be built via a simple GUI, with support for required questions, entities, intents, training via datasets, and one click integration with over a dozen chat services (Facebook, Slack, Telegram).

API Driven Development

Another common trend among developers in the recent past is a larger and larger focus on the API of a project, as the client and server have become so decoupled in development that a single API could be handling requests from mobile devices, laptops, gaming consoles, and raspberry pi’s without device compatibility issues (as long as the client is written correctly!).

Github WebHook payload

With a focus on creating robust API’s, specifically resource based design (defined by developers working on Google Cloud Platform), there has never been so many well written API’s to work with. Pairing this with webhooks and events triggered from chat rooms, you can wire up nearly anything that has an API that can be configured to talk to a HTTP server.

Below is an example of a DialogFlow’s fufillment request, which hits the ChatOps router.

Configure a webhook to post response payloads in DialogFlow

Routing

Due to the nature of DialogFlow, triggered payloads can only hit a single webhook — therefore, it needs to be one of which can handle the metadata tied to the payload, route it to the correct handler, and execute the task. The standard router is currently being developed on Github as of Feb ’18. Constructing an interface for plugins allows for quick, easy development of new plugins.

Getting Involved

The chatops.ai project hosts all of its code and agents on Github. Specifically, chatops-ai/proposals allows for anyone to create a pull request with a feature idea or request. You will also find official plugins and example agents.

Join us on slack at https://chatops-ai.slack.com !

We look forward to creating bots together 😊

--

--

Alec Cunningham
ChatOps
Editor for

DevOps Engineer; GCP Cloud Architect and University Student 🤸