With this and Backstage it looks like there is a real need for a single pane of glass across an organization's infrastructure. From both a GUI perspective and an API perspective.
It looks like it would aid in more self-service and keep users away from cloud console's.
The workflow engine looks the most powerful since it would allow for a way to avoid fat fingering common manual changes.
Sad that it doesn't seem to offer any deployment visibility options. I would love to connect it to our CI/CD system to see what changes are currently being rolled out.
Yeah definitely. A major pain point I've experienced recently is trying to figure out how to stand up various pieces of infrastructure needed to deploy my app at my company.
There's the k8s manifest, Cloudbuild config, various operators for databases, a CloudFormation repo for AWS resources, another one for Datadog config etc. It all feels very disjointed.
> Sad that it doesn't seem to offer any deployment visibility options. I would love to connect it to our CI/CD system to see what changes are currently being rolled out.
Deployment visibility is what my startup - https://sleuth.io - is trying to focus on, with light workflow sprinkled in. Other options I've found are usually tracking as a side feature of a tool like Sentry, Rollbar, or GitHub, or a completely custom app like what Slack built in https://slack.engineering/deploys-at-slack-cd0d28c61701
I disagree. Working in IT infrastructure / DevOps for years theres nothing worse than maintaining aging infrastructure that was too tighly coupled or "too unified".
Looks like it has more "self service" capabilities. But not sure.
But i think most of the problems are better solved by running an IaC tool like terraform in CI with a pull-request workflow.
I previously worked at Stripe, where we had something vaguely similar; a UI for managing deploys, infra changes, etc. All a thin wrapper around a CLI we could also use, plus some niceties like embedded monitoring. I'm going to really miss that tool the next time I build my own web service.
It really helped product engineers make changes to production with speed, confidence, and safety.
Before, doing so was a combination of yaml config changes, a smattering of in-house and third-party CLI's, and sometimes complex combinations thereof. You could do it, and we did all the time, but it was less discoverable, slower, and more prone to error.
I'll be curious to see if Clutch is something that proves easy for other orgs to adopt to their needs.
Trying it out today, and the existing features work. It could use some polish, And a lot more modules. But so far my experience here is similar to my experience with envoy. The maintainers are engaged, helpful and very nice. Questions are answered and easy issues fixed as we speak.
The real promising part is how this is made to be extended. It seems like a self-service ops API built around protobufs which is a good starting point.
> There is a popular continuous delivery platform that addresses many of the same overarching issues as Clutch (e.g., lowering MTTR, user-friendly UI). However, it requires significant investment in running many microservices and migrating applications to a structure different from our own.
Any idea which one?
Edit: I assume Backastage as it’s the first listed on the linked comparison page.
I've been trying to do something similar with a less complex approach using incremental automation scripts and creating an operational meta database, then do some light integrations (a Grafana datasource that can use the ops metabase to use information in templated dashboards)
That... sounds good? Like, good for everybody involved?
This plan won't work if management doesn't agree that you're solving a valuable problem, and also won't work if other companies don't view the problem you're solving as valuable.
In simple terms with no dubious metaphor, infrastructure tooling is the set of tools provided to engineers that allows them to deploy and run their software on the infrastructure that is unique to their company.
Although lots of companies use common tools (let's say, randomly, Kubernetes), companies' infrastructures are usually a pretty unique combination of software and rules. The "infrastructure tooling" abstracts away those software and rules and allows developers to deploy "things" simply using the provided tools.
For example, imagining a company using Kubernetes, an infrastructure tool could be a web UI that allows you to deploy a specific application by simply clicking buttons. That tool would in fact deploy to Kubernetes, yet as the user that detail doesn't matter to you.
You know how you need to setup k8s, logging, DB, and a handful of other services before you can deploy your app. Well this tried to tie together these services and hopefully make it easier.
[+] [-] SomaticPirate|5 years ago|reply
It looks like it would aid in more self-service and keep users away from cloud console's.
The workflow engine looks the most powerful since it would allow for a way to avoid fat fingering common manual changes.
Sad that it doesn't seem to offer any deployment visibility options. I would love to connect it to our CI/CD system to see what changes are currently being rolled out.
[+] [-] disposedtrolley|5 years ago|reply
There's the k8s manifest, Cloudbuild config, various operators for databases, a CloudFormation repo for AWS resources, another one for Datadog config etc. It all feels very disjointed.
[+] [-] mrdonbrown|5 years ago|reply
Deployment visibility is what my startup - https://sleuth.io - is trying to focus on, with light workflow sprinkled in. Other options I've found are usually tracking as a side feature of a tool like Sentry, Rollbar, or GitHub, or a completely custom app like what Slack built in https://slack.engineering/deploys-at-slack-cd0d28c61701
[+] [-] kiney|5 years ago|reply
One job, one tool is still valid today.
[+] [-] sandGorgon|5 years ago|reply
I'm not entirely sure what problem does Clutch solve that is not solvable using Terraform
[+] [-] kiney|5 years ago|reply
[+] [-] rattray|5 years ago|reply
I previously worked at Stripe, where we had something vaguely similar; a UI for managing deploys, infra changes, etc. All a thin wrapper around a CLI we could also use, plus some niceties like embedded monitoring. I'm going to really miss that tool the next time I build my own web service.
It really helped product engineers make changes to production with speed, confidence, and safety.
Before, doing so was a combination of yaml config changes, a smattering of in-house and third-party CLI's, and sometimes complex combinations thereof. You could do it, and we did all the time, but it was less discoverable, slower, and more prone to error.
I'll be curious to see if Clutch is something that proves easy for other orgs to adopt to their needs.
[+] [-] gtirloni|5 years ago|reply
[+] [-] simtel20|5 years ago|reply
The real promising part is how this is made to be extended. It seems like a self-service ops API built around protobufs which is a good starting point.
[+] [-] 0xEFF|5 years ago|reply
Any idea which one?
Edit: I assume Backastage as it’s the first listed on the linked comparison page.
[+] [-] zeisss|5 years ago|reply
[+] [-] SomaticPirate|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] VectorLock|5 years ago|reply
[+] [-] ckdarby|5 years ago|reply
It generally looks like:
- Go to company with major growth
- Tackle a problem they face
- Leverage company resources to build a open source solution
- Sell management on all the benefits of open source
- (Optional) Wait for stock to fully vest
- Create consulting services company for the tool you built
[+] [-] rattray|5 years ago|reply
This plan won't work if management doesn't agree that you're solving a valuable problem, and also won't work if other companies don't view the problem you're solving as valuable.
[+] [-] Shorel|5 years ago|reply
This part requires permission from the company in some jurisdictions
[+] [-] euske|5 years ago|reply
[+] [-] gouggoug|5 years ago|reply
Although lots of companies use common tools (let's say, randomly, Kubernetes), companies' infrastructures are usually a pretty unique combination of software and rules. The "infrastructure tooling" abstracts away those software and rules and allows developers to deploy "things" simply using the provided tools.
For example, imagining a company using Kubernetes, an infrastructure tool could be a web UI that allows you to deploy a specific application by simply clicking buttons. That tool would in fact deploy to Kubernetes, yet as the user that detail doesn't matter to you.
[+] [-] Max_aaa|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] 0xEFF|5 years ago|reply
Comparison isn’t perfect but it’s usually good enough.