Chatops: Where Automation, Collaboration and DevOps Culture Meet

Originally posted on thenewstack.

Fostering a collaborative cloud native environment is about transparency into your tech stack to give developers gentle onramps into complicated technical challenges.

If DevOps was meant to encourage transparency and collaboration, Kubernetes often becomes a convenient excuse for organizations who haven’t yet fully embraced the culture. If the Kubernetes cluster manages all the operations so well on its own — with declarative configuration and self-healing — organizations start to ask, “Why should developers need to know anything about operations anymore?”

Kubernetes, like most cloud native technologies, hides complexity behind a few layers of abstraction. Because of the simplicity and best practices they bring to the operations side of a technology stack, it’s tempting to use them as an excuse to take a step back from the DevOps culture and rebuild some of the walls.

Frontend developers worry about implementing the design system and dealing with APIs. Operations teams worry about keeping the cluster online and scheduling pods.

But from my perspective, adopting and migrating cloud native technologies is the perfect time to resist that temptation and ensure application developers have the right kind of access to your infrastructure. With the most appropriate and user-friendly tools, they should be able to monitor, debug and run checks against their applications in development, staging and production clusters.

With the right kind of access. We’re not talking about giving every developer the keys to your Kubernetes kingdom. We’re talking read-only, giving them the collaborative platform and knowledge they need to do their jobs as best as they can through automation.

Where Automation and Collaboration Meet

When I talk about automation, I’m not just talking about performing actions without human intervention. That certainly comes in handy at certain points of developing and operating a Kubernetes cluster, but just as important is the process of simplifying complex processes through waypoints, or “bumpers,” that guide developers toward getting things done.

You want developers solving business problems, not going down rabbit holes into how kubectl works. Or, worse, negatively affecting the health or performance of your cloud native deployments.

At the same time, fostering a collaborative cloud native environment is about delivering transparency to the way your tech stack works at its more granular levels — giving developers gentle onramps into complicated technical challenges.

Why should your organization create collaboration through automation?

  • You provide safe, read-only access to developers who aren’t (yet) fluent in cloud native technology. You can’t expect to successfully shift left every aspect of software development without giving your developers a bit of a tutorial first.
  • You help application developers identify potential issues without editing the state of your cluster. When the time comes to file a bug report or a Jira ticket to escalate the issue, they can provide informed descriptions or potential solutions, shortening the feedback loop.
  • Your organization starts using a single tool, language and messaging platform for sharing insights about infrastructure health.
  • You widen and diversify the use of monitoring and debugging tools. Because those are also read-only and informational in scope, you’re constantly educating your developers while improving the DevOps culture.

Bringing Automation and Collaboration to Kubectl

Botkube is all about giving your DevOps, site reliability engineering (SRE) and developer teams simple and secure (hint: read-only) access to your clusters directly from the platforms they use all day anyway: chat apps.

Whether your organization uses Slack, Mattermost, Discord, Microsoft Teams or others, application developers can now use the same tool to chat with their peers, collaborate on ongoing projects or issues and run kubectl interactively — and read-only — to help peel back those layers of abstraction.

With v0.15.0, Botkube now offers an interactive tool for building kubectl commands within Slack, which means developers don’t even need to spend time learning complicated syntax to start exploring why a deployment might not be running correctly.

From your organization’s Slack, run @botkube kubectl to select the verb, a namespace and an object, then apply a filter to find only the resources relevant to your search. You’ll get a block of log output directly in the app without having to rely on consoles or pulling favors from friends in operations.

You can also start responding to events directly from Slack. Let’s say a developer recently merged a pull request, and the new code is making its way through your organization’s CI/CD pipeline. As the cluster starts to spin up new pods with updated code — a crash. In this scenario, you can click Run command and select relevant options from a dropdown.

Best of all, Botkube’s automation is entirely contextual, only delivering options that make sense given the circumstances and that are filtered based on what the developer has access to run against your clusters.

With Botkube acting at the intersection of collaboration and automation, developers get comfortable bumpers that help them seek answers safely, without wasting time looking up kubectl reference docs or asking questions on Slack.

What’s Next for Automating Your Kubernetes Cluster with ChatOps?

We’re just getting started with automation and building a collaborative environment through the chat apps your organization already uses. In v0.15.0, released in October, we added the interactivity, events and filtering-based features we’ve already mentioned.

We also just released v0.16.0, which introduces actions, another key element of transparency and optimization. You can configure Botkube to automatically take action on specific events, using kubectl, every time a matching event occurs within your cluster.

Automation on monitoring events gets us one step closer to Botkube becoming the control center for your cluster — a single application that takes predefined actions based on specific errors or alerts to simplify cloud native infrastructure for everyone. We plan to add more extensibility for additional alerts and executors in the near future, letting you automatically validate a new manifest against your security policy.

Get started with Botkube in just a few minutes to start receiving alerts and running commands directly from Slack, Mattermost, Discord, Microsoft Teams or even a different service of your choosing thanks to outgoing webhooks. And, once you’re ChatOps-enabled, we’d love to hear from you in our active Slack channel, where we’re not only chatting about even better collaboration for cloud native infrastructure, but also designing the future of Kubernetes automation.

Source: thenewstack