DEV Community: Paweł Kosiec

How we designed a DevOps Co-pilot to help DevOps and SREs reduce context switching

Paweł Kosiec — Mon, 07 Oct 2024 17:08:36 +0000

Introduction

In today’s fast-paced world, DevOps, SRE, and platform engineers constantly juggle multiple tasks—from navigating through various layers of a project while implementing new functionalities to answering developer questions and troubleshooting infrastructure issues. This constant context switching often leads to inefficiencies and burnout.

In this blog post, we’ll dive into the journey of building Botkube Fuse, a tool designed to address these challenges. We’ll explore the problems it solves, the design process, and how it can help streamline workflows for platform engineers.

The Inspiration Behind Fuse

The design process for Fuse was born out of necessity and shaped by user feedback. As we engaged with platform engineers, SREs, and DevOps practitioners in our community, it became clear that their biggest challenge was the sheer volume of tasks they had to handle simultaneously. Our team began by identifying the most common sources of frustration, such as switching between multiple browser tabs for project documentation, constantly checking CI/CD alerts, and answering repetitive infrastructure questions. These scenarios are just examples of a larger problem: context switching.

Tackling the Core Pain Point: Context Switching

Context switching is one of the most significant challenges platform engineers face in their daily work. Whether it’s responding to alerts from CI pipelines, troubleshooting deployment issues, or answering developer queries, they are often pulled in multiple directions at once. This fragmented focus leads to inefficiencies and can significantly slow down productivity. In many cases, engineers spend more time switching between tasks than actually solving problems.

That’s not all. Context switching can also result from a lack of proper staffing and support. Many organizations expect Platform Engineers, DevOps, and SRE practitioners to cover an extremely wide range of responsibilities (“EverythingOps”) without adequate resources. Additionally, these teams are sometimes treated like a help desk for developers or are expected to architect systems without sufficient backing from engineering leadership, further worsening the problem.

(GIF source: tenor.com)

From Idea to Reality: Crafting the Perfect Solution

Once we understood the pain point we wanted to solve, the next step was designing a solution. The terminal is the natural choice for most DevOps or platform engineers we engaged with, so we decided to use it as the foundation for our design. We opted to build a CLI tool that combines multiple different tools and knowledge sources into a single, unified experience.

Now, we can’t forget the hardest part of the design process: naming.

The name “Fuse” was chosen to represent the core idea of unifying and streamlining tasks for platform engineers. It stems from the concept of “fusion”, symbolizing the merging of multiple tools, tasks, and workflows into a single, cohesive solution. We wanted a name that was easy to remember and reflected the tool’s purpose of reducing fragmentation caused by context switching. Fuse brings together the enhanced power of Botkube’s AI capabilities with a simplified workflow, helping engineers focus on what matters most. The name perfectly encapsulates the tool’s mission to “fuse” everything into a seamless experience.

Meet Fuse: Your New DevOps Companion

After two months of design, planning, and development, we launched the first public Fuse release.

Fuse is a terminal tool powered by our most advanced AI assistant, designed to answer your questions and tackle challenges in your day-to-day work. Unlike some other tools on the market (including Botkube), it’s just a single CLI binary without an agent. You just simply install Fuse and type fuse 'your prompt here...', or run fuse to enter interactive mode and start chatting.

Unlocking Fuse’s Power: How It Works

Fuse builds on existing Botkube technology, including our AI assistant and cloud infrastructure, and takes it to the next level.

Fuse uses the powerful GPT-4o model from OpenAI to get things done. We integrated a variety of tools to assist you with Kubernetes, Google Cloud Platform, GitHub, Git, and local filesystem operations. It can even generate and execute Python code on your behalf!

“Whoa, that’s pretty dangerous,” you might say. “I don’t trust the code executed by AI.” Good point! That’s why Fuse requires user confirmation for each potentially dangerous operation (such as filesystem writes or code execution) to ensure you are in full control of what’s happening on your machine.

Why Fuse Stands Out

While there are similar tools in the AI space, we wanted to build something different—and better. That’s why we established two bold principles.

A Holistic View of Your Infrastructure

Firstly, we aim to integrate your data from different sources and make the Fuse AI assistant aware of connections between them. Imagine a smart assistant who understands your infrastructure: from your Terraform modules, ArgoCD app manifests in your git repository, through your GitHub Actions pipelines, Google Cloud Platform resources current state, to actual business-critical services deployed in Kubernetes. That's what we have in mind while building Fuse. Magic, eh?

(GIF source: tenor.com)

We introduced the fuse init command which currently introspects your Google Cloud Platform project, your GKE clusters and other resources, to help with your complex scenarios on the edge of Kubernetes and GCP. But that's just a glimpse of what we want to build. Stay tuned!

Focused Solutions for Real Problems

We aim to solve real user problems, which often arise at the intersection of different parts of the infrastructure—hence the need for the end-to-end infrastructure knowledge we described earlier.

However, even with such knowledge, we do believe that even the most powerful AI assistants out there still require some guidance. Someone needs to do the “prompt engineering” work. That’s why we introduced AI assistant guidance for different user scenarios. Currently, we focused on:

GitHub Actions secret management
GitHub Actions pipeline run analysis
GKE troubleshooting with IAM permission errors
Local environment operations and debugging

How does it work? The Fuse AI assistant categorizes your question first, and then if it’s close to our predefined scenarios, it uses our custom instruction for guidance to do the work. Of course users can still customize the behavior with customized prompts but we want to make sure it follows the right path by default.

While more scenarios will definitely ship soon, we also do believe that users should be able to write custom instructions and reuse them automatically in a given context. Expect some updates around that in the following weeks - and if you have any suggestions for improvements or new scenarios, please let us know on Slack or by getting in touch.

Wrapping Up

Launching Fuse is a significant milestone, but we view it as the foundation for something much bigger. We're eager to learn from your experiences, gather feedback, and iterate on Fuse to make it even more powerful and intuitive. This is just the beginning, and we're excited to see where we can go from here.

To recap, Botkube Fuse is designed to help platform engineers, DevOps, and SREs reduce inefficiencies caused by constant context switching. By unifying multiple tools into a single, terminal-based CLI powered by AI, Fuse simplifies complex workflows and automates repetitive tasks. With features like GKE troubleshooting, GitHub Actions analysis, and more, it’s built to solve real-world challenges.

Best of all, Fuse is free to try—so give it a try and see how it can streamline your day-to-day work. We’d love to hear your feedback—reach out to us via Slack or our social media channels!

Microsoft Teams Integration for Botkube: A Technical Journey

Paweł Kosiec — Wed, 13 Dec 2023 13:20:45 +0000

Introduction

If you are already familiar with Botkube, then you know that it's a collaborative tool to help you monitor and troubleshoot Kubernetes clusters. Botkube integrates the most popular communication platforms, and Microsoft Teams is one of them.

The initial version of our integration debuted in February 2020, marking a significant milestone in our journey. Since then, we've been continuously evolving and improving. In this release cycle, we've identified and acknowledged its limitations in the user-experience and ease of set up.

Fortunately, these times are over now! We've been working hard on a brand-new Microsoft Teams integration, which we introduced as a part of Botkube 1.6 release.

Now, let's talk about how we got here.

Inspiration from the Field

During our conversations with users at events like KubeCon and Civo Navigate, we found out that many IT companies rely on Microsoft Teams for their communication. It's not surprising, considering that Microsoft Teams is one of the most popular communication platforms in the world. It is used by over 1 million organizations and 320 million users (source).

Through discussions with various users and organizations, a common problem surfaced--many faced challenges due to the requirement for a public endpoint on their Kubernetes clusters and difficult configuration steps. Also, the integration lacked some of the core features that were available in other platforms like Slack. This was usually a blocker for them.

Right after the Botkube Cloud launch, we focused on building the seamless multi-cluster Slack integration, as it was without doubt the most popular communication platform among our users. However, we knew that we had to do something about the Microsoft Teams integration as well. Because of the way the Microsoft Teams API works, the only way we could fix this problem properly was a dedicated infrastructure for handling the communication between Botkube and Microsoft Teams.

That was the time we were approached by a large enterprise company that was using Microsoft Teams as their main communication tool. They were interested in a proper multi-cluster solution for their customer's Kubernetes clusters. After a series of interviews and discussions, we used their feedback to start developing a new Microsoft Teams integration.

Source: tenor.com

Technical journey

Investigation and research

The very first stage was to investigate various aspects of the Microsoft Teams communication platform and its API. We wanted to understand the limitations and challenges we would face during the development process. We also wanted to make sure that we could deliver the features that were missing in the previous version of the integration.

This phase consisted of multiple different steps, including:

Research around Microsoft Teams Bot Framework and Graph API capabilities.
Multi-tenancy architecture design with a proof of concept application (covering security, multi-cluster support, and scalability).
App distribution, installation and permission granting process.
Interactivity support for the Microsoft Teams messages.

Every single step was crucial to the success of the feature and had it own challenges. During the investigation stage, we quickly realized that this solution will be slightly different from the multi-cluster Slack integration we've built before.

Architecture design

After our set of investigations, we had a clear picture what we're going to build. We established the following architecture:

Let me go through the diagram.

Until our Microsoft Teams app is approved by Microsoft and listed in the Microsoft Teams apps catalog, we distribute a ZIP file for manual sideloading by a Microsoft Teams organization administrator.

After installing the app, to use Microsoft API for fetching team and channel information, we need to grant the app permissions to access the Microsoft Teams API. This is done by the organization administrator only once for the whole organization.

Same as for Slack integration, in Botkube Cloud we use a message broker internally, to ensure scalability, and reliability. Every Botkube Agent connects via gRPC to Botkube Cloud to receive events from Microsoft Teams.

Because of the way the Microsoft Teams API works, and to ensure proper tenant separation, both source notifications and executor commands are routed via Botkube Cloud. This is different from the Slack integration, where we could use the Slack API directly from the Botkube instance for handling incoming notifications. However, Botkube Cloud is used simply as a proxy, without storing any event data.

Interactivity support

Interactivity support for the Microsoft Teams messages was one of the challenging parts of the development process. We wanted to make sure that the user experience is as good as possible, and close to the Slack integration. Fortunately, Microsoft Teams uses Microsoft's Adaptive Cards format, which is a flexible way to present interactive content in Microsoft Teams messages. Moreover, in-place message updates are supported, to ensure the content is always up-to-date. But, of course, technical details were different from the Slack integration, so we needed to render the messages differently.

After a while we were able to achieve similar feeling to the users familiar with our multi-cluster Slack solution. Here's a quick comparison:

Development and testing

Thanks to the Microsoft Teams proof of concept application, we were able to quickly start the development process. The fact that we built the multi-cluster Slack integration before also helped tremendously. We were able to reuse some of the concepts like gRPC communication between Botkube Agent and Botkube Cloud, and the message broker infrastructure.

After busy weeks full of development and testing, we were able to deliver the first version of the new Microsoft Teams integration. While it's not yet perfect, it's a huge step forward. We are working on adding more features and improving the existing ones, continuously refining the integration based on user feedback, including the one from the company that came to us with the initial request.

New Microsoft Teams integration: Key Features

So what the first version of the new Microsoft Teams integration brings to the table? Let's take a look at the key features:

Multi-cluster support.
Enhanced per-channel plugin configuration including RBAC policy.
Interactive messages.
Actionable notifications.

While some features known from Slack, such as the Kubectl command builder, are not yet available in the new Microsoft Teams integration, we are working on adding them in the future releases.
Still, every single item listed above weren't available in the previous version of the Microsoft Teams integration. And, what's the most important, we simplified the configuration process. It still isn't perfect, but we think that it's a huge step forward.

As the previous integration was so painful to set up, we decided to deprecate it. Worry not, though! The new Microsoft Teams integration is now available to all users as a part of the Botkube Cloud offering--both Free and Team plans.

Your reaction after trying out the new Microsoft Teams integration (hopefully!).
Source: tenor.com

Setting Up and Configuration

Interested in trying out the brand-new Microsoft Teams integration in Botkube? To get started, create a free Botkube Cloud account and follow the Microsoft Teams instruction. To see the multi-cluster support in action, enable the free Botkube Cloud trial and connect as many Botkube installations as you want!

What do you think? Let us know!

We are constantly working on improving Botkube and its new Microsoft Teams integration. Our roadmap is driven by user feedback and community contributions. Let us know what you think about the new integration and how we can make it better. You can reach out to us on the Botkube Community Slack workspace, or simply create an issue on our GitHub repository.

Building Botkube ChatGPT Plugin: From Ideation to Implementation

Paweł Kosiec — Fri, 28 Jul 2023 10:43:43 +0000

Introduction

The Botkube team is a group of dedicated individuals with a common focus on developing innovative solutions in the technology landscape. With AI getting more and more widely used, the team saw an opportunity to explore the potential of AI-powered chatbots in the DevOps space.

A significant event that played a crucial role in shaping the trajectory of the ChatGPT plugin was the company-wide hackathon organized by Kubeshop. The hackathon was a great opportunity for the team to brainstorm ideas and collaborate on projects that would help people make Kubernetes life easier, simpler and faster.

This blog post aims to document the entire process involved in the creation of the ChatGPT plugin for Botkube open-source project. From the initial spark of the idea during the hackathon to the final stages of implementation, we'll take you on a behind-the-scenes journey. Expect insights into the challenges, breakthroughs, and collaborative efforts that went into making this vision a reality.

‍

Ideation Phase: The Company-Wide Hackathon

It all started with the internal Kubeshop hackathon. During this intense and collaborative event, team members from diverse backgrounds came together to brainstorm, experiment, and find novel solutions to challenges in the Kubernetes space, as a part of the existing projects in Kubeshop portfolio. The hackathon's theme was to help Developers, Testers, DevOps, SRE’s or their managers with making Kubernetes life easier, simpler, and faster. In 48 hours, the teams had to come up with an idea, build a prototype, and present their proof-of-concept solution to the judges.

The Botkube team came up with 14 different ideas. As the hackathon time was limited, the team had to filter out the ideas we should focus on. After several discussions and internal voting, we decided to improve the Botkube onboarding experience. This consisted of 4 different parts:

Botkube Cloud Migration Tool, to seamlessly migrate existing Botkube installation to Botkube Cloud.
Botkube Cloud Instance Builder, a convenient drag-and-drop UI tool to configure Botkube instance.
Exec plugin, to install and run any CLI application directly from chat platform, without any hassle.
ChatGPT executor plugin, which is the main topic of this blog post.

The ChatGPT plugin was the most voted idea internally, as we all saw the potential to bring significant value to the users. The team, guided by the goal of selecting an idea with the highest impact, set specific criteria to evaluate each proposal. We considered factors such as feasibility, market demand, and alignment with the Botkube's long-term vision. The ChatGPT plugin idea ticked all the boxes, showing promise to address real customer needs and aligning perfectly with the Botkube's mission.

‍

Planning and Conceptualization

Once the ChatGPT executor plugin was selected as a part of our hackathon topic, the team started working on the project. The first step was to define the goals and objectives of the plugin.

The main goal was to lower the barrier of entry for new Botkube users. Sometimes it is hard to understand and troubleshoot the Kubernetes errors and their meaning, especially for beginners. That's why the idea was to introduce "Get help" button under incoming error events.

The button would pass the error data to the ChatGPT plugin, which would use return an AI-generated response with actionable buttons. The user would be able to click on the buttons to execute specific commands, such as kubectl describe pod or kubectl logs pod. This would help the user to troubleshoot the issue without the need to search for the solution on the Internet.

Another use case we considered is answering human questions directly from the chat. The user would be able to ask questions like "How to create a Pod?" or "How to troubleshoot non-working Service?" and get an AI-generated response. This would be useful for new users who are not familiar with Kubernetes concepts and terminology.

The final part of this phase was to come up with a name for the plugin. This was one of the hardest challenges.

There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton

We decided to call it "Doctor", as it would help users to diagnose and fix Kubernetes issues.

‍

Development Process

The enthusiasm and dedication displayed by the team during the ideation phase laid a strong foundation for the development of the ChatGPT plugin. As we already knew what we wanted to develop, we had to decide on the specific technologies and tools to use.

Choosing plugin language was the first step. Botkube plugin API uses Hashicorp's go-plugin gRPC interface. While it has cross-language support, we decided to stick to Go as it is the primary language used in Botkube. We also wanted to leverage the existing Go SDK and pipelines we set up for the Botkube Go codebase.

The next step was a bit more challenging: choosing the right AI model. We wanted to use a pre-trained model to avoid the need for training data and the time-consuming training process. The most important thing was to be able to answer Kubernetes-related questions efficiently. After careful consideration, we decided to use OpenAI's GPT-3 (text-davinci-003) model for the chatbot.

While ChatGPT integration is very straightforward, another little challenge was to construct a prompt that produces predictable results and to parse the response from the model, so that we could render interactive output for a user. After a little bit of testing and experimenting, we achieved the desired result.

The last part was to integrate the ChatGPT plugin into Kubernetes source plugin, which watches for Kubernetes events and sends notifications to the chat interface. We extended the Kubernetes plugin with extraButtons configuration property, which accepts command templates and renders them as interactive buttons as a part of each notification:

This way, we were able to render the "Get help" button under each error event. As the implementation is generic, users can also benefit from it and configure virtually any command button under specific types of events.

‍

Result

In 48 hours, Botkube team was able to deliver a fully-working ChatGPT plugin called "Doctor". The plugin is able to help troubleshooting Kubernetes cluster issues based on incoming events. It's best used in combination with Slack integration, as it provides interactive buttons to help users navigate through the troubleshooting process. No typing required!

‍
It also exposes ChatGPT prompt, so you can ask some arbitrary, not necessarily Kubernetes-related questions:
‍

The team was very happy with the result, and we decided to ship it to all users in Botkube 1.2 release! 🎉

How to get started, you ask? Install Botkube, if you haven't already, and enable Doctor plugin following the Configuration document. Then, learn how to use it by reading the Usage document.

‍

Conclusion

The journey from the hackathon ideation to the final ChatGPT plugin has been nothing short of remarkable. It all began with the internal Kubeshop hackathon, where the Botkube team collaborated intensely and passionately to brainstorm ideas for making Kubernetes life easier, simpler, and faster. After carefully evaluating various proposals, the ChatGPT plugin emerged as the most promising idea, driven by its potential to revolutionize the Botkube onboarding experience and provide users with an unparalleled DevOps tool.

This would not have been possible without the spirit of cross-team collaboration and innovation that thrives within the company. The hackathon served as a platform for team members from diverse backgrounds to unite, share their expertise, and collectively explore innovative solutions. This collaborative approach fostered a culture of creativity and knowledge-sharing that continues to inspire future projects.

The Doctor plugin was just the beginning of our journey. We plan to continually enhance its functionality, leveraging user feedback and insights to make it more versatile and user-friendly. That's why your feedback is very important to us.

Let us know what do you think about the ChatGPT-based Doctor plugin! We are always open to feedback and suggestions. If you have any questions, feel free to reach out to us on Slack or Twitter.

PS If you haven’t already, don’t forget to star Botkube repository on GitHub!

Introducing Capact, your new way to manage applications and infrastructure

Paweł Kosiec — Tue, 21 Sep 2021 12:55:17 +0000

Managing the lifecycle of infrastructure, applications, and processes in modern IT is problematic. There are a variety of tools and best practices, which are ever-changing. It's a struggle to stay up-to-date with these practices, and not everyone is an expert at everything. Technical debt is inevitable.

We are ultimately all alone. We are siloed within the context of team, department, or company, locked-in in a particular ecosystem of tooling. To deliver end-to-end capabilities, we build them from scratch in a vacuum. We consume API calls, transform data, build and manage infrastructure and applications. Don't we spend too much time solving the same problems as others have?

Sharing expertise is something that already happens—we have plenty of libraries and frameworks out there. But what if we went a step further and have a way to create, use and share building blocks that are language-agnostic abstracted capabilities?

For example, if you're not a cloud expert, all you need to know is that you want a managed PostgreSQL database on AWS. Let the subject-matter experts take care of it, and simply focus on your business logic. Likewise, if you need any Kubernetes cluster—by saying "I want any Kubernetes cluster" and letting the magic happen, you could cover both local development and production scenarios…

What if I told you… now this is all possible?

Introducing Capact, crowdsourced expertise. Learn once, use everywhere.

What is Capact?

Capact is a new way to manage applications and infrastructure and run arbitrary workflows.

source: tenor.com

Yes, we get it. You already know plenty of different tools for that. But Capact is different. How is it different?

Capact comes with a truly unique feature—interchangeability of dependencies. If you know the concept of interfaces from a variety of programming languages, you get the idea. Think about Capact as a way of executing workflows with steps, which are described with interfaces. An implementation for a given interface is resolved dynamically at runtime, according to your preferences. Also, these dynamic workflow steps are building blocks, which can be reused by others (or even nested within other workflows).

Initially, we focused on day-one and day-two operations for managing applications and infrastructure. However, Capact is built with universal concepts in mind, so you can run any arbitrary workflow you want. For example, you can do data processing, machine learning workloads, system configuration, cluster benchmarking, auditing, running serverless workloads—the possibilities are virtually endless.

The best thing is that Capact is fully open-source under the Apache 2.0 license. How cool is that? 😎

Capact concept in one minute

The whole concept sounds confusing? Let's see that in action.

Let's take Mattermost installation as an example. Mattermost is an open-source alternative for Slack.

Mattermost is a Go server application, which uses a PostgreSQL database. If we want to install Mattermost, this how the workflow would look like:

We need a PostgreSQL database first to run a Mattermost server. It's pretty simple.

Now, what if we make the PostgreSQL database installation abstract? Think about that as an empty slot, where you can put a puzzle with a specific shape.

Assuming there are many puzzles pieces out there, you see that only a few of them fit in the slot:

In the case of PostgreSQL installation, four puzzle pieces fit:

Install PostgreSQL Helm chart on a Kubernetes cluster
Provision GCP CloudSQL for PostgreSQL database
Provision AWS RDS for PostgreSQL database
Reuse existing PostgreSQL database

By default, for a workflow run, Capact picks the first puzzle piece that fits. However, by applying Policy, you are in complete control of which puzzle piece will be chosen. Moreover, you can select a different one for a specific scenario, such as local setup, CI/CD, stage, and production cluster.

What's great is that Mattermost installation itself is also a larger puzzle piece, which others can use! Maybe as a part of productivity stack installation, which could consist of Mattermost, GitLab and Jitsi Meet? 🤔

And that's Capact. You can build your own workflows with existing puzzles, which are available inside Capact Hub. You can also create your own puzzles. Share them with the community and enable DRY at a global scale, together!

How does Capact differ from other tools?

Capact doesn't compete with tools you might already be familiar with, but it integrates them instead. Whether you are a Helm or Terraform user, you can still use your favorite tools. Mix and match your tooling or API of choice. For example, chain Terraform, Helm, and Slack API.

If you are familiar with Kubevela, Crossplane, and Open Application Model, you can see many similarities between the solution and Capact. Here are the main differences:

Capact has unique built-in feature—interchangeable dependencies, which reduces the amount of duplicated code.
Capact is a process / workflow-based solution, which gives you more flexibility. Unlike Kubevela and Crossplane, Capact is not limited to just infrastructure and application deployment. You can use it for virtually everything.

To read a detailed comparison between Capact and other tools, see our FAQ.

Get started with Capact

Interested in trying out Capact? Awesome! The easiest way to do so is by installing it locally and trying out one of our examples to understand Capact basic concepts.

Here are other things to do:

⭐ Star our GitHub repository: If you like the idea, show your interest in the project and give us a GitHub star! You can also subscribe for new Capact releases. Thank you for your support!

👉 Follow us: Interesting in Capact updates? Follow us on Twitter! Also, check out our LinkedIn page and YouTube channel.

📖 Read our documentation: If you want to get familiar with other installation options, examples, content development, or contribution guides, check out the Capact documentation.

🤔 Get support: If you need any help, or you have a question for us, join our Slack channel on the CNCF workspace and post a message—we'll do our best to get you sorted!

Currently, Capact is at an experimental stage. We open-sourced Capact as early as possible to get early feedback and build Capact together with the community.

Wait, there's more!

In a series of future blog posts, we will highlight Capact features and cover various topics for all!

Also, as of September 20th 2021, a brand-new release, Capact 0.5.0, is here. We were working really hard to bring many UX improvements, both for Capact users and content developers. The list includes:

Complete Action input validation and more advanced, concurrent Capact manifests validation with optional server-side checks,
Experimental content development tools for Helm and Terraform-based (AWS and GCP) manifest generation,
Policy syntax and behavior changes for improving consistency and usability,
Verbose output for Capact CLI,
Dependency updates, including migration to Argo 3,
Air-gapped Capact installation,
k3d support,
and much, much, more!

To see the full list of features, read the release notes.

Are you ready to start playing around with Capact?

source: tenor.com

Originally published at https://capact.io on September 7, 2021 and updated on September 20th, 2021 to highlight that the Capact 0.5.0 release is publicly available.