ChatOps is one of those curious mysteries. Or, more specifically, the term “ChatOps”. Today, if I picked a few random junior engineers out of any arbitrary tech company, there’s a fair chance that they wouldn’t even be familiar with the term ChatOps. And there’s a fair chance that you aren’t familiar with the term ChatOps.
But seven years ago, “ChatOps” was a significantly more recognizable phrase.
Number of instances of mentions of ChatOps on Hacker News courtesy of awk
You might be asking, "So what? Tech trends come and go all the time (cough, NFTs, cough)." However, while the term "ChatOps" may have disappeared, the practice of ChatOps remains more popular than ever. While some ChatOps workflows (such as automations) aren’t as popular as were initially forecasted, many have flourished.
The “dictionary definition” of ChatOps is quite enterprise-y. ChatOps is (clears throat) the practice of using business chat to facilitate software development and software operational tasks. In more layman’s terms, ChatOps is doing cool engineering stuff in Slack.
ChatOps is an opinionated type of DevOps. DevOps is a vague term used to describe anything that augments the engineering process. DevOps includes CI/CD, MergeQueues, automated unit testing, etc. By extension, ChatOps is about using chat—think Slack or Microsoft Teams—as the primary interface for orchestrating certain DevOps workflows.
For instance, ChatOps would have approvals to access a database table happen in chat. ChatOps dictates that scaling a cluster size should happen in chat. ChatOps dictates that deployment summaries should happen in—you guessed it—chat.
Of course, ChatOps isn’t some preachy employee training praying for better team communication. ChatOps happens when DevOps software integrates with chat applications and uses that integration in a non-trivial way.
Back in 2013, when the term ChatOps was popular, there were a few topics that were commonly pitched examples of ChatOps.
In reality, these are popular practices today. Error reporting being dispatched to Slack is common practice among Sentry or LogRocket users. Github and Atlassian both have integrations to dispatch repository events to Slack. And Intercom tickets are routinely sent to Slack.
ChatOps advocates typically focused on three benefits of ChatOps: (a) it gave developers instant context in a shared place, (b) enabled team scaling by letting junior engineers learn by observing more tenured engineers, and (c) enabled developers to tag-team on issues because all reports and actions transparently remain in chat. Today, all three of these remain priorities for most organizations.
Here’s the conundrum: ChatOps’s advocate’s hopes and dreams came true. So how come nobody uses the term ChatOps today? Time for some history.
To understand why the term ChatOps disappeared, we need to walk through a particular sliver of history. Specifically, we need to revisit an old corporate duel between HipChat and Slack.
HipChat was a startup founded in 2009. From its onset, HipChat was a chat application designed with engineers in mind. HipChat organized chat through channels (similar to Slack) and prided itself on its API that enabled integrations to Github, Jira, and other developer applications. At the time, HipChat was replacing email and SMS as a centralized place for teams to converse. It was successful, too; for a small startup, HipChat was booming, with over 1,000 companies using it within the first four months of launch.
HipChat was eventually acquired by Atlassian (woohoo!) and continued to grow popular. HipChat became the center of the ChatOps conversation; its extensible API made it a prime mascot for the space—HipChat integrated with big SaaS applications, like Atlassian, Github, Statuspage, Mailgun, etc! Almost any decade-old talk on Youtube about ChatOps uses HipChat as the chat application.
HipChat was often used with Hubot, a GitHub-led project that served as a framework for building custom bots. While Hubot led to a lot of silly projects, it enabled companies to build custom bots that carried out bespoke workflows. Hubots integrated cleanly with Hipchat, and together, they led the ChatOps charge. In fact, Jesse Newland coined the term ChatOps while giving a talk on Hubot.
But eventually, HipChat started to lose market dominance to a new kid on the block: Slack.
There was a lot to love about Slack from day one. Slack was a beautiful application, with nice pastel colors and airy quotes to welcome users. More importantly, Slack was free for unlimited users (while HipChat triggered a paid tier after 5 users). In short, Slack wasn’t concerned with short-term revenue, but instead exceptional customer usage.
Companies migrated to Slack in droves. Over 8,000 companies signed up for Slack within 24 hours of its public launch. One of the biggest reasons was Slack’s lofty pitch. Unlike HipChat, Slack was designed for the entire company, boasting integrations with SaaS tools popular among Marketing and Sales. Quickly, companies realized that having a separate Slack and HipChat instance was impractical, especially when Slack also offered similar integrations to HipChat’s.
While HipChat retained a sliver of the “engineering-first companies” market for a while, it was eventually sold to Slack by Atlassian in 2018 and discontinued shortly after. Slack had won the war, and HipChat was officially a relic of the past.
Don’t get me wrong—Slack’s executives weren’t sitting around a table and cackling at the demise of ChatOps. In reality, Slack loves ChatOps (that is, ChatOps in practice). But Slack wasn’t an application designed for engineers; it was an application that united the entire company.
And, arguably, the term ChatOps was bound to HipChat. HipChat was the “engineering chat app”. Once HipChat was swallowed whole, Slack replaced ChatOps with the more bland “Slack Integrations”, a nowadays ubiquitous feature in almost any SaaS application.
However, there is a difference between the average ChatOps integration and the average Slack integration, and it’s not just the target user. While ChatOps did have some silly integrations—like Hubot-powered bots that shared cat photos—ChatOps integrations were seen as mission-critical workflows that powered the engineering team. Conversely, Slack integrations are often accessory features available in every other SaaS app; many are “nice-to-haves”, not core value props.
In short, Slack Integrations diluted the importance of ChatOps, and while ChatOps remains a common practice, the term lost meaning.
Microsoft Teams is growing incredibly fast. While Slack is still popular amongst startups, more and more companies with massive employee counts are switching to Microsoft Teams. Today, over 270M users actively use Microsoft Teams on a daily basis (compared to only 2M users who used the product in 2017). In comparison, Slack only has … 18M users.
Because Microsoft bundles Teams with Office 365 and Azure packages, it is popular among enterprise companies.
What does this mean for ChatOps? Well, Microsoft Teams is harder to build integrations for. teams is part of a bigger Office 365 ecosystem; accordingly, documentation is complex and heavy-handed. That alone might explain why most ChatOps software is biased toward Slack. (Granted, most of Slack’s users are younger companies, and any early software projects, included those tackling ChatOps, tend to first build camaraderie among smaller fish).
But the fact remains—Teams is unquestionably massive, and if any ChatOps project wants to scale to an enterprise, integrating with Teams will matter. Hopefully one day Microsoft Teams will simplify the integration process. Either that or ChatOps projects need to get their hands dirty with Microsoft Teams’ tricky documentation.
Okay, back to the original point: ChatOps as a term is fading away. So what? ChatOps is still an integral piece of today’s engineering workflows, and even if Slack Integrations are seen as accessories on average, that doesn’t mean that ChatOps isn’t a core part of today’s engineering process.
In particular, ChatOps falls into three categories: notifications, automations, and gating.
Many ChatOps products are notifications. Sentry and LogRocket dispatch error notifications to teams. Intercom dispatches customer feedback. Many CI/CD dispatches deployment notifications. Github dispatch pull request notifications.
The benefit of notifications going to chat, as opposed to email, is that applications like Slack support threads, and threads enable developers to centrally discuss a certain event with all the context readily available. That is significantly better than email threads, sprawling URLs, and switching tabs.
The other common ChatOps use case is gating (typically for security). Gating is where a certain resource or action is blocked by a person or rule. Sym is one of these tools—we enable AWS resources to be gated programmatically, using Slack as a place to file requests and grant access.
The benefit of using Slack (as opposed to a third-party tool) is that Slack (a) is where developers already are active and (b) doesn’t require developers to learn another interface. And, thankfully, Slack’s interactive modals provide ChatOps app builders (like us) to collect actual text inputs to enable workflows.
Another category for ChatOps is automations, where users can initiate a workflow through chat. The big benefit of funneling automations through chat is that other team members can both observe and learn from ChatOps activities. However, this category of ChatOps has always struggled.
An example of a ChatOps automation tool is AWS ChatBot. With AWS ChatBot, engineers can run AWS workflows directly from inside chat. Yet I have never met a single engineer that uses AWS ChatBot albeit using AWS for Cloud Infrastructure. And, curiously, most ChatOps automation projects aren’t too active. A very comprehensive ChatOps meta-repository, Awesome ChatOps, isn’t actively updated anymore. BotKit, and OpsDroid are frameworks for building bots that both look promising. But based on their activity and GitHub stars, there appears to be a gap between the ChatOps hype from a few years ago and the adoption of tools like these.
One issue with Automation ChatOps is that it deviates from the original chat paradigm. Notifications are inherently conversation starters and are very "chat-like" in nature. For instance, "The site is down!" is something that would immediately go to Slack even without a ChatOps integration; the integration just makes things easier. For gated content, asking permission and bothering higher-ups are also activities that typically occur in chat; ChatOps just streamlines the process. Automation ChatOps meanwhile adds a feature that typically doesn't happen in chat. Since engineers don’t think of Slack when performing automation, that could contribute to poor adoption and usage.
A separate headwind that Automation ChatOps face is poor feedback. When you run an automation in Slack, the command disappears after the automation executes. That’s not what happens in the command line, and while the command line doesn’t communicate what’s happening with the team, it does communicate much better with the engineer.
One of the weird, quirky new possibilities of where ChatOps is headed is LLM / AI assisted code. At this stage, most of tech Twitter has seen how ChatGPT and its cousins can write code derived from English instructions. Given that ChatGPT is … well, chat … is that technically ChatOps?
In my book: yes on paper, no in practice. Using an LLM / AI to write code is technically using chat to assist an engineering process. The difference, however, is that ChatOps was fundamentally about using chat for DevOps workflows that foster collaboration between teammates, not any wildcard developer function.
Frankly, it’s a pity that ChatOps declined as a term. The ideas that its advocates preached have mostly become reality. Regardless, even if its mascot company HipChat was absorbed by Slack (or Salesforce, technically), the heart of ChatOps remains alive and furiously beating today. Chat remains one of the best places for engineering teams to get work done, collaborate, and collectively freak out over app crashes. I remain confident that ChatOps in practice isn’t going away anytime soon.
