Show HN: Your DevOps Control Plane, in Slack

https://cto.ai/blog/slack-control-plane-for-devops-workflows/

by slajax • 6 years ago

75 35 6 years ago

dvohro3• 6 years ago

How does this compare to GitHub Actions for Slack?

stevehiehn3• 6 years ago

full disclosure: I work for CTO.ai. It is a similar concept really, but the Ops Platform has a built in interop layer for communicating between the containers & slack channels.

dvohro3• 6 years ago

what do you mean by containers? a company's dockerized infra?

I watched the video, you guys are centralizing all the team's scripts inside Slack. I can see a lot of Slack addicts loving this!

markandrewj• 6 years ago

Maybe I am misunderstanding what CTO.ai does. GitHub actions are for CI/CD pipelines. Where as CTO is a bot for interfacing with webhooks over chat. The broader term would be ChatOps. Something more comparable in the Github world would Hubot. Jesse Newland has some good lectures about why you would want to do this. Many of the examples come down to visibility of work in remote teams, and creating cleaner interfaces to useful products. There are a number of tools, many people use day to day because they are useful, that have terrible interfaces. You also see some organizations consolidating things like knowledge bases. Apologies if I have generalized CTO.ai in a way that is incorrect.

eslamsalem• 6 years ago

Very interesting. Can I set permission for every slack member? What resources he can control ?

slajax13• 6 years ago

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.

deeblering42• 6 years ago

Doesn’t this give slack employees root on your infrastructure?

slajax13• 6 years ago

Founder here - 100% not. We've build a specialized PaaS that ensures your credentials and workflows are encrypted and there is no additional security vector here. Also Slack is one of our investors and they have worked with us a great deal to make sure that the security is handled properly!

throwaway29102• 6 years ago

It’s going to take a lot more detail than that to convince me to let this anywhere near infrastructure I care about.

Care to elaborate for the skeptics reading this?

Investment <> Secure

deeblering42• 6 years ago

What prevents a slack employee from issuing chat commands as an authorized user? Similar to what we saw in the recent twitter hack.

slajax13• 6 years ago

Founder here - We created CTO.ai to help foster accessible developer experiences by lowering the cost of leveraging Slack in your developer workflows.

The key idea is that you build a CLI using our SDK (it's a container) and then we make it instantly accessible to your whole team in Slack, while also providing 12 factor principals such as Secrets, Configs, Logs, Events and Metrics.

We are early on but have a very vibrant and growing Slack community of developers who want to build their own Cloud PaaS using AWS, GCP, Azure etc but want an easy to use DX so they can distribute there knowledge and process to others and save themselves tons of time and context switching.

Please AMA, we'd love to hear your thoughts.

jasonpeacock• 6 years ago

What happens when Slack is down? Does DevOps also stop, or is there a way to do the same commands/workflows outside of Slack?

You don't want two separate run books, as they'll never stay in sync. It'll already be enough of an efficiency hit just switching to an alternative interface when Slack is down, let along switching to different tools/processes.

slajax13• 6 years ago

Founder here - great question.

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.

ruxandrafediuc2• 6 years ago

Hey Jason, Ruxandra here from the CTO.ai team!

You have the freedom to build your DevOps workflows as you please, by leveraging our SDKs to interact with the tools and platform you use daily for DevOps. The Slack interface allows you to customize the inputs and trigger these workflows as you desire, but--once triggered--you will not necessarily depend on Slack being up. Hope that makes sense!

Also, the workflows you automate using our platform work in the CLI as well. So you build once, you get a containerized automation which you can use either locally in your CLI, or in Slack. For running these locally, you have to install our `ops` CLI on your machine (more on this here: https://cto.ai/docs/start-building-ops).

Let me know if that helps clarify your questions or if you have any other questions. Thanks!

jacksonpollock• 6 years ago

@slajax - what are some of your favorite use cases for the platform?

stevehiehn3• 6 years ago

(cto.ai employee here) The obvious ones are any basic CICD operation that you might want to trigger from Slack, i.e: pull code, build code, deploy code. The second use case that comes to mind is treating the platform as a very quick way to build an all purpose SlackBot.

leosantana• 6 years ago

Why in my conscious mind would I ever wanna do something like this?

Especially that lately Slack has proven to be so unstable (lots of intermittent downtime). Meaning I would just lock my infra automation code in CTO.ai servers for... what?

ruxandrafediuc2• 6 years ago

Ruxandra here from the engineering team at CTO.ai. Thought I'd jump in and say we have some cool examples in our registry, covering automations with various products offered by the popular cloud providers, as well as workflows around creating, managing and destroying Kubernetes clusters, and so much more: https://cto.ai/registry.

I certainly have a soft spot for the K8s ones especially as I helped build them :-)

jmlimit• 6 years ago

I am very interested to see where this thread goes...

gman2121• 6 years ago

What are some of your most common workflows??

mistedissetanti2• 6 years ago

Slack as a "control plane" is quite the concept, giving operational power to more people around the company through Slack can be a two-edged sword though.

Now, aside from the implicit risk that this might offer, if Slack acts as the "Control plane" for DevOps, what's the platform's "Data plane"?

Is it right to assume that in order to be independent from Slack we'd need to rely on CTO.ai's own infrastructure and resources? I.e. the data plane where DevOps "effectively happens"

slajax13• 6 years ago

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!

schoolornot• 6 years ago

Chatops has failed at every single company I've worked at. This is an extremely noisy and unnatural way of managing resources and it gets old after the first week. A sprinkle of Hubot here and a Slack web hook there but no one is going all-in on this.

slajax13• 6 years ago

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!

Thanks for your feedback! We'll keep iterating!

kaseyluckk• 6 years ago

Looks cool! Can you share some case studies / coolest use cases?

slajax13• 6 years ago

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!

Show HN: Your DevOps Control Plane, in Slack

Related Stories