In the first blog post of this ChatOps series, we talked about the sprawl of tools, technologies and platforms that teams are currently facing as illustrated by the below image from Cloud Native Landscape. We also discussed how a combination of bots and native chat integrations can solve some of these needs.
The arrows in the image below are examples of the integrations between a variety of systems. This sets up an ideal DevOps maturity model of automation standards. Which means, it is not feasible to only rely on one-to-one integrations.
Below are some common DevOps use cases that do not always seem to be automated to the extent that they should be.
Usage of public cloud infrastructures are pervasive. Plus, manually provisioning is far from being ideal. There are excellent tools like Terraform that provide declarative ways to automate the provisioning process. However, it is best to make the process self service via ChatOps. For example, being able to provision via a command from the team's group chat room. Ideally, the same stack of technologies providing the orchestration for ChatOps, can also be triggered by a REST API. This will cause it to also be integrated into existing ticketing and approval systems. One form of this is when a JIRA ticket is approved, it can trigger the infrastructure's provisioning which in turn, will run Terraform and Ansible.
Tech giants like Facebook have talked about the idea of self-healing and auto-remediation in their hardware and software stack. However, the concept of event based triggers that can attempt to self-recover from service and infrastructure failure, can be a very powerful way of improving MTTR and manual intervention. At Addteq, we use this concept for automated disaster recovery. Monitoring is being triggered to detect inter and intra Cloud and/or regional failures to initiate the entire process. All of this without requiring human operators to be present. Many IT teams are currently overburdened by taking too much of their workday being tied up with many failures that could have been tackled with self-healing and auto remediation.
Building custom ChatOps integrations can be done with Bots, like we discussed in the previous blog posts. Some of the use cases described above can be implemented using Hubot and other chatbot frameworks, but that is not recommended. Some of the automation workflows can run for a lengthy period of time and it is possible to scale these without issues in adoption of series. The idea is not to replace Hubot as the bridge and interface of the chat tool but rather augmenting it by integrating with an automation engine/platform, that can do all of the heavy lifting. It is also ideal to be able to leverage existing open source and community contributions, rather than having to write everything from scratch. There are currently tons of open source contributions on this.
Enterprise ChatOps adoption has some pre-requisites that include things like LDAP authentication, role based access controls and audit trails. It is best to choose a ChatOps solution that can satisfy the needs of your teams. No matter if the size ranges from small to enterprise sized teams.
In the final blog of this ChatOps series, we will go over how Addteq and other organizations, find Stackstorm to be the most powerful and flexible open source automation platform. Coincedently, Stackstorm also has excellent ChatOps enablement via a Hubot integration.