Botkube — Building Bridges across the CNCF Landscape
It’s Day 1 at your new job as the first DevOps or platform engineer. You fill out a bunch of HR forms, sign into Slack and get your GitHub account connected to your organization. You chat with new colleagues and explore the infrastructure you’re now responsible for operating and maintaining. You quickly realize how little consistency there is in how developers deploy to Kubernetes.
There are different tools, processes and configuration styles/standards, and way too much manually running
kubectl apply or
helm install to get the job done.
Your highest priority quickly becomes designing and implementing a “paved road” or “golden path” for your organization — a suite of tools, as small as possible while remaining effective, that aligns development teams on a single process, abstracts away complexity, prevents reinventing the wheel and safely automates deployments.
Between recognizing that first challenge and the eventual rollout, you can’t help but wonder: Will there be any way to unify these tools into one place, maybe even where all the inter-office chat and collaboration happens already, so that people will want to use this beautifully paved road?
The Challenges and Opportunities of the CNCF Landscape
As of writing, the Cloud Native Computing Foundation (CNCF) landscape contains 1,178 tools and projects in a handful of wide-ranging categories, like provisioning, runtime, orchestration and management, app definition and development, platform, observability and analysis, and more. Even if you filter down to only open source projects, you’re looking at more than 500 choices — an enormous task for a busy DevOps or platform engineer who’s always creating more “glue” between milestones in the software development life cycle to remove complexity or need for manual input.
You’re constantly asking yourself tough questions, like:
- Are these tools best-in-class at solving a particular technical problem, like secrets management or CI/CD pipelines?
- What metrics, like community engagement or release velocity, signal quality when the cloud native community has not congregated around established or “certified” routes for the Kubernetes life cycle?
- Do they communicate with one another using open protocols/standards or already-developed integrations?
- What gaps might still exist in the software development life cycle even after designing and implementing the paved road?
- Does this paved road, as a full experience, keep developers from reinventing the wheel and instead help them deploy high-quality applications to production?
- Is there any way to make a paved road that toolchain developers and engineers love to use?
You’re also aware of the cultural headwinds you’ll likely face when rolling this paved road out to your organization — crotchety tech old-timers who resist change and love their ClickOps-ing ways of the past or leadership who demand to know why you’re so focused on co-workers, not customers.
Many others in this position have gotten locked into a state of tool choice fatigue, afraid of wrangling the sheer complexity of the CNCF landscape or that tools they eventually choose won’t communicate well together.
At Botkube, we like to take a different perspective. The scope of the CNCF landscape is viscerally visual proof of the sheer value of the cloud native community. Instead of worrying over whether tools will sync up well in day-to-day operations, it’s time to focus on how you can reliably build bridges between them with the tool all your peers already use for chatting and collaborating every day.
Building Bridges with Botkube and Plugins
That’s exactly what we’re building with Botkube — ChatOps for everyone who deals with Kubernetes clusters, whether they’re DevOps or platform engineers, site reliability engineers or application developers eager to understand how their code performs in staging or production. With Botkube, they get fast, simple and secure access to their clusters directly from the chat and collaboration platform they’re already using day in and day out, like Slack.
But long ago, we realized that ChatOps for Kubernetes, in isolation, doesn’t solve any of these problems around building paved roads and the necessary bridges between your tools of choice.
To meet DevOps and platform engineers, we’ve started building Botkube into an API automation engine, starting with a modular plugin system, released in v0.17.0, that allows our ChatOps platform to listen to events from any source and automatically respond through an executor, all while reporting in to the Slack channels your teams already use.
Sources are events or notifications from any cloud native tool, including asynchronous streaming data, which Botkube can now ingest, format and send to your communication channels. For example, Botkube has always supported native Kubernetes events as a source, but we’ve now extended that functionality, so anyone can develop custom plugin business logic in Go, build binaries and pass multiple configurations based on your use cases through source bindings.
When you build a plugin for Botkube to gather data from another cloud native tool, you’re bridging details — which would have otherwise been siloed in a different interface, platform or logfile accessible only with complex CLI tooling — into your organization’s Slack channels for immediate visibility.
Executors are Botkube’s workhorses, allowing you to run specific commands on these external cloud native tools directly from Slack or another communication platform. The output from that command is returned directly to the channel. Like with sources, anyone can leverage our Go-based plugin system, which already features a quick-start repository with templates to help you jump right in.
Our Helm plugin, which we also released in v0.17.0 is a rich example of the simplicity and visibility that comes with building bridges via ChatOps. Now, when an application developer merges a pull request to update their configuration only for the deployment to fail in the CI/CD pipeline, everyone sees an alert in Slack. From this shared platform, they can start to view pod logs, check out the Helm release status, chat with one another about what went wrong and the best course of action, then run
@botkube helm rollback <release> to bring the cluster’s state back to working order.
You can even extend plugins with actions, introduced in v0.16.0, which automate the bridge between alerts and responses, even across cloud native tools. You can, for example, take an alert straight from Prometheus/Alertmanager, informing you that a specific pod’s CPU usage has suddenly spiked dangerously close to its
resources.limits.cpu value resulting in degraded performance, and automatically query your cluster for the latest logs from that pod. With this bridge fully automated, you can start your troubleshooting process with full context.
You not only save time and remove the complexity of running
kubectl commands manually but also ensure your entire team operates from the same source of truth.
Time to Bring Botkube onto Your Paved Road
To start building bridges across the CNCF landscape, check out our installation guide, which includes details for each integration we support, like Slack, Mattermost, Teams, Discord, ElasticSearch and generic webhooks. That will get you set up with the app, bot and backend service in your cluster.
Then hop over to our plugin quick-start guide, plus the example templates you can build from, to route events from your team’s favorite cloud native tools directly into your chat.
Whether you’re a ChatOps enthusiast or are just trying it out for the first time with Botkube, our Slack community is here to collaborate, share ideas and help. We’d love to hear about your use cases, check out the plugin sources/executors you’re developing, and give you a peek into the future of ChatOps and API automation with more resources to help you do more on Kubernetes with less tool choice, less context switching and a smooth platform experience for your entire organization.