
Show HN: Your DevOps Control Plane, in Slack - slajax
https://cto.ai/blog/slack-control-plane-for-devops-workflows/
======
slajax
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.

------
mistedissetanti
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"

~~~
slajax
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!

------
jasonpeacock
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.

~~~
ruxandrafediuc
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](https://cto.ai/docs/start-building-
ops)).

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

------
schoolornot
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.

~~~
slajax
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!

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

~~~
slajax
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.

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

~~~
stevehiehn
(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
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?

~~~
mistedissetanti
That's an interesting question and I was wondering the same thing.

Sounds like if we set Slack aside, all that CTO.ai is really offering is buy-
in into their platform w/ no clear value beyond the initial slackbot-like
integration

~~~
slajax
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!

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

~~~
slajax
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!

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

~~~
slajax
Well first of all, as a public company Slack is held to extremely well
regulated security protocols to ensure this never happens, so we get the
benefit of that out of the box.

Additionally, we require the user to associate their Slack user to their
CTO.ai account using a secure authentication layer that has dependencies
outside of Slack.

Theoretically, if a Slack employee were to try to execute a workflow, we would
be able to see that they don't have this privilege and flag / reject that
request because they wouldn't have the CTO.ai associated membership.

At this point, it's just as secure as any web application or even CLI, which
have better understood virtual and physical attack vectors. We take it a step
further by ensuring that tokens MUST be vaulted, avoiding the chance that you
leak them through a lost laptop or public commit.

We're also looking at 2fa for some of our enterprise use cases and have been
working on a deeper integration with Slack enterprise grid which makes this
even more secure.

Are there additional approaches you'd recommend we take here?

------
dvohro
How does this compare to GitHub Actions for Slack?

~~~
stevehiehn
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.

~~~
dvohro
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!

~~~
stevehiehn
The platform essentially allows devolopers to create small portable
containerize operations that can be interfaced via slack simply by using the
Ops SDK. For example if your user code in the container prompts `sdk prompt
'Whats your favorite color?'` It will prompt in your teams slack channel with
zero effort on the developers part.

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

~~~
slajax
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!

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

------
gman2121
What are some of your most common workflows??

