Capact – New open-source project to manage applications and infrastructure in a unified way
By - peeriks
If the pronunciation of Capact is important to you then you should know that most English as a first language users are going to pronounce it ka-pact or perhaps cap-act, but cape-act is not going to catch on. Good luck with the project.
Yeah, we are aware of that. The "cap" in "capact" comes from "capability", that's why our "capact" pronunciation is different from the natural one. We may rediscuss that, though :-) Thanks for feedback!
Capact maintainer here. I wanted to share with you the project I've been working on for more than a year now. Hope you like it!
I posted the blog post because (I hope!) it explains well our general idea. If you need a direct link to our repository, here it is: [https://github.com/capactio/capact](https://github.com/capactio/capact)
Good luck, though I immediately thought of [this xkcd.](https://xkcd.com/927/)
Thanks! Actually, I wanted to use this xkcd comic in the blog post, but went with a gif instead :D Well... we are aware of what we're doing :-)
Really cool project you have here! I've been looking for some open source projects that I could contribute documentation to and Capact looks like a really interesting tool to work on -- are there any areas that might require some support?
Hi u/DumShuckles, awesome to hear that! Yes, we would appreciate a contribution to our existing docs. We know that there's so much to do in this area.
Currently, I see at least two options:
* We have [this](https://github.com/capactio/website/issues/40) open for contribution. It's a part of our Hacktoberfest issues, and we think it would improve the user experience a lot!
* Any review of existing documents (all or some part of them) will be much appreciated. It doesn't need to be a pull request, even a GitHub issue aggregating all found issues will help us as well.
If you are interested in the contribution, please join our [Slack channel](https://capact.io/community/slack). I'll be offline the next 2 weeks, but our other team members will be glad to chat with you and answer any of your questions.
Thanks a lot!
I used Cfengine, Puppet, Ansible, Helm, Terraform and various other tools to manage applications and infrastructure and somehow I feel like I can't make an actual comment without completely destroying the very idea of what you are trying to do here.
Could you please elaborate a bit more? I would really like to hear your thoughts.
With Capact you can still use your favorite tools, and you can chain them to build one single workflow to get things done, e.g. provision an environment and install some applications on it.
For example, you can create a Kubernetes cluster (using Terraform) and install some Helm charts on it (using Helm). But, thanks to the interchangeable dependencies (or, in other words, dynamic workflow steps), you can have a single workflow which targets both local (kind/k3d) and production (AWS EKS / GCP GKE) environments. In the workflow, you would have an Interface for creating a Kubernetes cluster. During the workflow run, an Implementation is resolved according to your preferences.
All such Interfaces and Implementations are reusable, so the more people use Capact, the more existing building-blocks (or "puzzle pieces") are available out there to use. So, as we like to name it, it's DRY at a global scale. Yes, I know, it's a bold claim, and it requires a huge amount of work from our side to make it happen.
Ok look, maybe your tool is awesome and does a lot of things that are helpful, I don't know, I haven't looked at it yet in detail, I probably will though, so don't worry :-)
The main "complaint" I have is stuff like "Let the subject-matter experts take care of it, and simply focus on your business logic". I mean it sounds like a great idea to abstract all the complicated system engineering stuff and you can just deploy a whole stack of interconnected application at the press of a button. Except, I just have never seen this actually work well outside of some sample applications that are nice for testing environments.
The problem usually isn't really to deploy an application. This is never the difficult or complex part. The actually time consuming part is to wire those system into the other infrastructure you already have in place, like auth, backup, monitoring, making it work with company specific restrictions and policies, etc.
Maybe in some simple use cases the whole abstraction of the "building-blocks" can make this process faster. This is usually the case if the developer of the abstraction had a similar environment. But if that isn't the case, it usually doesn't take long until the abstraction starts to get into your way.
Because the developer of that abstraction probably doesn't document all the features of the software in the detail that is needed to understand them. So if you have a specific thing you need to configure and it's not completely obvious from the abstraction you have to go to the regular software manual, but then on top of that, you also have to look at the abstraction layer and somehow figure out how you configure that building-block in a way so it results in what the manual told you to do. This can often be quite complicated.
And you just hope that the "building-block" actually let you do that or you have to go fork it and extend it with what you need. So instead of "just pressing the buttan!" or actually configuring the software, you are busy trying to extend the "building-block" and get this change upstream so others can now enjoy the added functionality.
But then your PR will most likely not get merged, because it turns out that there isn't really an incentive structure to make this all work. The original writer may have already moved on to other projects. The "building-block" is still doing what he wrote it for, and works fine for him. Merging your PR means additional work and risk to his own setup no one is paying him for. So he has all the motivation to just ignore it. And that is what usually happens.
Thank you for this - that’s a totally valid point. We are aware of such issue, and we try to minimize it as much as we can.
The first thing we already have is a way to provide additional input, specific to a given Implementation. If you have the generic Interface “create Kubernetes cluster”, the inputs should be universal, vendor-agnostic. But if you’re an advanced user and e.g. you know that it should be provisioned on AWS EKS with some tuning, then you can use the additional input to set some advanced properties for the Terraform module underneath.
Also, in the future, we want to do auto-discovery for the existing capabilities in the system. Based on them, the application itself could be configured as a part of the installation or additional workflow.
There are also many aspects around the “building-blocks”, including:
1. describe the guidelines and best practices + enforce them
2. establish good governance model that scales well
3. prepare good tooling to generate the abstraction with as little as possible input from user
There are some other ideas in our minds, but we want to hear the early feedback from the community.
So, we're constantly thinking about this problem and working on solutions. For example, in last release we prepared some experimental tooling to generate Implementation manifests based on Terraform modules and Helm charts (with auto-generated inputs). But we understand that there's still so much to do in this area. I truly believe, that at some point we'll be able to mitigate this issue for most of the cases.
This seems like nix CI if nix didn't try to take over every part of your workflow.
I'm living in the nix ecosystem, but I'll keep my eye on this. Seems like a better/more sane Jenkins.
Yes, Capact could be used on CI/CD pipelines - it uses Argo Workflows underneath, which is OCI container-based workflow engine. We have some ideas about integrating eventing solution, which could make sense for this use case.