Operable.io, a company that builds DevOps collaboration tools, announced Cog, a ChatOps platform that provides access control, Unix-like pipelining of commands and audit logging. ChatOps is a collaboration model that ties together conversations, tools and processes for teams including QA, dev and operations.
Cog comes with an access control framework that allows permission management with groups, users and roles. Cog has fine-grained permissions. For example, in addition to being able to say "this group of users can run this command", Cog allows for things like "this group of users can run this command when these options and arguments are included in the command line".
GitHub created the first ChatOps bot. Errbot, written in Python, and Lita, written in Ruby are two other examples. InfoQ asked Mark Imbriaco, Co-founder & CEO, Operable.io, what makes Cog different:
The first goal for our initial release was to remove barriers to the adoption of ChatOps. These are primarily around security and compliance. Secondly, we wanted to build a shared command line that is as adaptable as a Unix command line.
Most ChatOps software exposes a command line interface that lets team members do operations like display a graph of a specific metric or promote a Git branch to master.
DevOps adoption is usually slower in traditional enterprise environments. In such setups, pushing a build to production from a chat room might not be acceptable. Enterprises also have concerns about permissions and reliability. Imbriaco says that enterprise interest in DevOps is increasing but that the existing tools were not built with the requirements that enterprises have.
Cog’s architecture is build around Relays, which are execution environments for commands. It uses a PostgreSQL database for persistence and command line tools for interacting with the system. An MQTT based message bus glues the other components together. MQTT is a lightweight protocol over TCP/IP designed for connections with limited network bandwidth. It’s based on the publish-subscribe model and thus requires a broker to distribute the messages to the subscribers.
Once a team adopts a ChatOps software, it can become dependent on it for routine tasks, so it is important that the software be reliable. GitHub's recent outage report mentions that their ChatOps servers were unavailable for a while leading to slower responses from the Ops team. A Cog setup has multiple Relay instances for parallelization and high-availability, however, the PostgreSQL database is still a single point of failure. Imbriaco says that there is more work to be done to make Cog more reliable. Specifically for PostgreSQL, he recommends:
That users follow best practices around building highly available Postgres clusters. There's a lot of prior art in this area. An example is the WAL-e continuous archival tooling that Heroku uses to build their very nice PostgreSQL failover support.
Cog supports pipelining of commands in the same way that Unix-like systems do. The Unix philosophy of having each command “do one thing and do it well” and then chaining them together to perform sequential processing has been adopted in Cog, “while maintaining access control and audit”, says Imbriaco.
Cog also has integration with Slack and HipChat. The software is still in alpha and the source code is available on GitHub.
