Founder here. AMA. Our goal was to build a serverless experience on top of k8s that felt like a PaaS but still provided the flexibility for teams to grow into their own private cloud k8s environment, as they scale. We're big fans of Cloud Native and k8s so we're hoping to ease adoption of these tools for smaller teams who don't have as much DevOps available on day 1 or larger teams who want to give their developers a really agile delivery flow on top of their private k8s infra. We've also done some interesting things with measuring workflow events to automatically calculate Delivery Insights (using DORA) to help provide stakeholder viability into operational cadence and stability. Happy to answer any questions or hear feedback! Be gentle!
Absolutely. We have about 5 that are currently in the works that cover many different use case from our community. We’ll be sharing soon on our blog so please keep an eye out for them!
Founder here - we agree. ChatOps has traditionally required you to build out a specific solution for Chat, which failed the cost of ownership equation, after you consider the cost of setting up servers, code and chat specific logic to run your workflows. Hubot is a good example but we've taking it way further and rethought DevOps from a Slack first perspective.
With CTO.ai your existing CLI "just works" in Slack and you have none of the additional overhead but get all of the benefits of chat such as distribution, transparency and collaboration as well. It's a big paradigm shift.
Many of our users are going all in because of this!
Founder here - for our users, the initial value proposition of being able to deploy a Slack bot in less than 5 minutes without servers, is usually the starting point.
After that they start digging into our team features for Secrets, Configs, Logs and Events which along with our public registry gives them a significant feature set to work against!
Founder here - We recognize that Slack certainly isn't for everyone which is why everything also works in our CLI and also soon by public API. Slack have a great uptime and regularly stay above 99.9% uptime according to their status pages - that said, if you wanted to bypass Slack and still run cloud native workflows using CTO.ai, serverless-ly, we allow you to also do that via CLI or API. This means you could build your own client and just leverage us for inexpensive compute.
Founder here - can you clarify what you mean by "data plane"?
We let you aggregate events and process metrics, should you want to use our platform as the way you aggregate event driven workflows or calculate delivery metrics.
You can run your entire workload on our serverless environment or you can push your workloads to your existing CI/CD + cloud computes - it's really up to you!
The way this works is that you first build a CLI, which is a container and then you publish it to us so that it also runs in Slack. It's shared code that runs in both environments.
So if Slack is ever down, you still have the CLI.
The big benefit here is that you build once and it runs in both places which means don't need a separate runbook or even infra to make your CLI run in Slack - it's 100% serverless.
For our users the Ops engineers obviously prefer the CLI, but the Dev's really love Slack - this creates a nice balance in the DX that works on both sides, on top of existing CI/CD.
Founder here - Thanks! Yes that's the general idea.
We're making it so you can port your existing scripts and allow them to easily run in Slack so that they are more discoverable and intuitive for all experiences.
Founder here - Since a workflow in the context of CTO.ai is just a container, which executes your code, you can build out as robust permissions as you need to by leveraging our vault integration, configs and teams.
Currently, our teams are a basic ACL that lets you manage who in Slack can run the workflow, but we also allow you to associate any of your teams to private channels, so you can more granularly control access using Slack's user membership.
We're looking at more RBAC on top of this for enterprise but for most smaller teams, this covers the majority of their use cases. They often create a team for ops and a team for dev and then associate these teams to members + channels as needed.
