HPE’s ChatOps Aims to Replace Dev Collaboration Platforms with Slack – InApps Technology 2022

Do developers really need another collaboration and communications platform, over and above what they’re already using today?  In one of the more startling responses you may expect to find from a company in the business of pushing software, Hewlett Packard Enterprise has effectively said, no.

In fact, the service that became the sleeper hit of the last HPE Discover conference in Las Vegas — HPE’s ChatOps — is actually an open-source implementation of the company’s existing automation and incident management tools, integrated with Slack, the messaging tool that appears to have finally tipped the balance in the market battle over chat tools in the workplace.

At Discover, a trio of HPE software architects gave InApps Technology a demo of ChatOps in action. What we did not see was a centralized platform with a big “ChatOps” banner and some cartoon icon, giving users yet another stream of real-time comments supplemented with happy faces and fickle fingers. Instead, we saw Slack being leveraged as a common stream of communication between developers in a project; DevOps professionals involved in maintaining software in production; and several lightweight “bots” performing individual tasks, mostly centered around sending data automatically to and from Slack. Using Slack’s existing automation, some of that data was used to trigger automated processes, some of which would be remedial in the case of a real software incident.

“Enterprise customers are looking at how they can use their existing assets and HPE products, and be able to leverage this new practice,” explained Ke Ke Qi, one of HPE’s chief architects in the content management space [pictured above].

Incident Report

“Within your help desk ticketing systems, you get logged a ‘severe’ defect, and your application’s down,” HPE’s Will Zuill asked us to suppose.  “It will automatically create a war room within your Slack chat room, and start inviting critical people there.  It will then post information about that particular defect; it will take information from your help desk and ticketing systems, for example, and post them into the room.”

At no point in the remediation process does anyone have to leave Slack and enter some separate application with its own GUI.  Mind you, HPE actually does have such a program — specifically, an infrastructure automation tool [PDF] called Operations Manager i (OMi, with a small “i” like in “iPhone,” except as a suffix), and it does have the requisite performance heuristics with the circles and arrows and the summary dashboards.

But ChatOps actually engages OMi in an automated fashion. While someone in DevOps may be using the OMi dashboard full-time, developers only need to engage with the data by posting commands in Slack to a ChatOps hubot. That’s a conversational tool of a style created by Slack, very much like the kind created decades ago when all network monitoring and administration took place on a command line.

The script for a bot for Slack’s Hubot is written in CoffeeScript, a streamlined language that compiles down into JavaScript. Variables in CoffeeScript may be dynamically invoked without being declared first; the CoffeeScript compiler, on the server side, recognizes that fact and adds the JavaScript declarations itself. Hubot is itself written in CoffeeScript and packaged using Node’s npm. The process of attaching a new bot to Hubot has already been automated, as a Yeoman workflow. So once an admin has retrieved the bot’s npm packages and placed them in the appropriate directory, she can run Yeoman’s yo command to automate the build process, which is – like everything else in Slack – conversational.

The Hubot code, with the custom CoffeeScript (now compiled as JavaScript) attached, becomes a single Node package. Deploying it on the Slack server becomes a matter of using npm to deploy the package, and amending the JSON file with the package’s title.

One Less Platform

For the most part, ChatOps is an adaptation of tools that both developers and DevOps are already using, at least in organizations where deployments are being packaged, and workflows are already pipelined. Which is entirely the point here: HPE is, by its own admission, answering the call from its customers to please refrain from injecting entirely new platforms into their workflow (and, by extension, new licenses), when just a few lightweight links may be all that’s required. Qi is looking at the prospect of using this more conversational methodology as a way of automating access to a variety of HPE’s other tools.

On the OMi side of the bridge, however, there may be a little more adaptation that an enterprise customer would have to undertake. OMi was designed to be one of those “single pane of glass” applications that mash together charts and performance metrics into a single screen. It can spit out data by way of API calls, but up until now, the use of APIs has been treated as an afterthought – the very last item on the list of things an admin would need to know, to become certified by HPE in the use of OMi.

Qi’s solution to that problem is to assemble the brain trust of knowledgeable API users into an online community, which publishes bot integration packages for admins to integrate with Slack for themselves. This way, they don’t have to undergo the certification process so that they can interpret the messages they’re getting back from their hubots.

“Now, there is some work that needs to be done here,” Zuill continued.  “We need to put some security in there… but the middleware is effectively this, which is a community-driven, open source kind of thing. That’s why, not only can you hook into this, but if you’re using different ticketing systems — for example, ServiceNow rather than [HPE] Service Anywhere — then they are supporting that particular process. So across these industries, these enterprise-level softwares, if they’re going to support ChatOps in some way, they need some representation in that hubot process… But at the end of the day, we’ve got APIs that are exposed, and this is just an interface into those APIs.”

A majority of HPE customers, Zuill believes, are already well invested in the use of APIs, because they are actively searching for ways to integrate their existing software with their processes. Thus ChatOps for them becomes not really a platform but a methodology.

HPE is a sponsor of InApps Technology.