DevOps, ChatOps, Conversation Platforms, Apps and Bots Oh Boy — RigD

DevOps has taken the application and operations community by storm. The unification of application development and application operations has already shown profound effects on the application lifecycle of service/product ideation, architecture, build, test, deploy, configure and operate. Where traditionally application development was owned by the business, or lines of business, operations was typically owned by the IT department (heck they owned the data center, servers, network and everything that one needed to stand up infrastructure for the application to run on). These two silos oftentimes did not work together and finger pointing was commonplace. Common scenarios where software worked in unit test and integration test, but failed miserably at scale operating in the wild of real customers in real data centers. Small changes in infrastructure can cause catastrophic problems with applications. It was the era when applications were developed for the specific infrastructure it was going to run on and the binding was indeed brittle.

With the advent of cloud computing, we start to see the beginning of loose coupling of applications and their infrastructure. This is not to say that the finger pointing between the development teams coding and testing their applications and the IT operations team deploying, configuring and operating the software/applications ended, the pressure only increased with the velocity of innovation. DevOps and the culture and processes underpinning it enabled intense collaboration between application development and application operations.

DevOps & Automation

DevOps is synonymous with automation and monitoring at all steps in the process, aiming toward reduced cycle times, increased deployment velocity, reduced work and better involvement and dare we say alignment with the business. Increasing systems thinking, taking work out of the system, increasing experimentation and feedback causes what we experienced in past years where we were pointed by errors and mistakes and slow cycle times, resulting in mammoth releases once a year. If you own the business and have to increase user counts and revenue quicker than you think possible, then you need a completely different model, right from the first day your business and the software architecture is visioned. Key to this increased innovation flow is the concept of executing a pipeline of tasks and automating them.

ChatOps

Fast forward a few years and an auxiliary concept arose called ChatOps. It is billed as one the best was to implement DevOps. With the advent again of technologies (based upon simple instant messaging and chat room concepts) that increased collaboration and persist conversations. ChatOps is a model where people, tools, process and automation are connected in a transparent flow. It also helps collaborate and control process pipelines in one window.

There are many examples of ChatOps placing key developer or operations tools into the conversation between developers and testing Q/A. Beyond Joe talking to Jane about a new use case or defect in the code and getting a fix into production for active testing, ChatOps places a key tool into the conversation like JIRA for bug tracking or Loggly for sending operational alerts into a slack channel. Let’s say you are a high performing team doing a ton of development in a microservices architecture and you have many moving parts. The good news is that you are using containers or even Serverless architectures so you don’t have to worry about infrastructure, but the complexity has moved up the stack into all of those microservices and how they work together. Monitoring a code change as it moves through your pipeline is made very easy with ChatOps as you see all the notification and alerts from your build and test system in your slack channel and your team can comment and collaborate directly in that channel. You even can see the operational alerts coming in as your application goes live. All good things happen to the DevOps model when ChatOps are being used.

Conversational Platforms

Conversational paradigms are a key aspect of ChatOps. Examples such as Slack or HipChat or any number of niche players fit into the Chat apps category. You install an App in the chat platform and then you have a Bot. The Bot can be built from any technology and involve anything from a simple conversational interface to set configurations for the bot. For example, GLANCE can be set to retrieve any number of social media metrics and routinely put them in the channel of your choice. Generally Bots are used to watch developer build/test/deployment automation results or operational metrics in a channel along with you chatting with your colleagues in context to a particular issue. This is critical to collaboration on issues that face pipelines, deployments or operational issues that arise after release to products.

The following graphic shows the construct of ChatOps.

Apps for those Platforms

Besides chatting with people (which is interesting in and of it self), apps on these platforms extend the human conversation paradigm to include a variety of functions. Take Slack and Hipchat for example. There are (at the time this was written) 202 Apps for Hipchat of which 24 are Bots.

Slack has a greater number of apps and even segments the apps into categories:

There are hundreds of Slack Apps that are considered Bots. As you can see these Slack or Hipchat Apps or Bots run the gamut in functionality from personal productivity, to analytics to integrations. We have multiple bots for example in Slack at RigD that are both home grown and commercially available (more on this topic in a later blog).

From Web Crawlers to Bots

Bots generally are associated with autonomous automated actions. From web crawlers indexing the early internet to simple older Bots running actions or scripts over the internet to now what is AI based functions that take input, process and then output relevant information. Bots can take on everything under the sun, after all it is software. But let’s get specific to DevOps for a second. By and large the biggest use case is the good ole notification and alerting service. Letting the team know the status of a build or results from automation testing or failures in our CI/CD process are critical when the we use these conversation channels for communication. Typically one Bot is in one channel although multiple Bots can “live” in one channel, but there are complications to that. Another use of Bots in DevOps is to perform actions or activities. Simple things like kicking up external automation (trigger) or even help users augment their actions through the day. Those use cases are generally pretty specific to the technology stack in play (more on this topic in a later blog).

Parting Shots

Over the past few years there have been a number of blogs challenging the norm and saying that Bots will replace the apps on our smart phones and even web apps in browsers. While we do not anticipate that outcome in the next decade, we will increasingly see Bots and Apps morph and Bots with the power of a supercomputer tethered to the internet will begin to augment out work life, including key DevOps conversations. Augmented automation embedded in context will drive DevOps to a place it needs to go.

Check out RigD’s videos and guides here.

Originally published at www.rigd.io on July 11, 2018.