Although, there are many ways to get started with Capact, today we will focus on your perspective as a Capact User.

The recommended way to try out Capact quickly is to set up a local environment.

Detailed instructions are already nicely described in our local installation tutorial. Once you have Capact up and running, we can start!

What you will learn​

In 5 minutes, by running examples from this blog post, you will learn about the following Capact concepts:

• Interface—provides an option to abstract Implementations.
• Implementation—defines the actual workflow that is executed.
• Attribute—provides an option to tag manifests. Today we will use it to select a specific Implementation.
• Type and TypeInstance—provide a combined feature, where Type holds the schema and TypeInstance the instance for the Type.
• Action—triggers Engine to render and run a given Interface.
• Policy—impacts the render process to select desired Implementations.

Creating new workflows is not the concern of this article, and it will be covered in future blog posts.

Here we only briefly describe each part, but I encourage you to take a deeper look at our Terminology section later.

Prerequisites​

• Capact CLI at least v0.6.0
• Capact cluster at least v0.6.0
• (Optional) kubectl
• jq

Scenario​

The key concepts were described in the Introducing Capact blog post. There, we used Mattermost as an example. It was a real life scenario but at the same time more resource and time-consuming.

For the purpose of this blog post, we created an extremely simple Hello World example.

There are two Implementations for the cap.interface.capactio.examples.say Interface. Depending on the Policy, a different Implementation is selected. By default, Engine selects the Implementation which is first on the list (alphabetical order) and doesn't have any requirements regarding executions, such as requiring AWS credentials.

Camera, Lights, Action!​

Action is the entry point for executing any Interface. It allows you to define which Interface should be executed and with which parameters. This is later consumed by Capact Engine and the appropriate workflow is rendered. Later, you can review it and approve it for the execution.

Steps​

1. Make sure that you are logged into local cluster.

2. List available Interfaces:

   capact hub interfaces get
   

   Copy

   We are interested in this part:

                              PATH          LATEST REVISION                  IMPLEMENTATIONS
   ---------------------------------------+-----------------+-----------------------------------------------
   # ... trimmed ...
   ---------------------------------------+-----------------+-----------------------------------------------
   cap.interface.capactio.examples.greet        0.1.0             cap.implementation.capactio.examples.greet
   ---------------------------------------+-----------------+-----------------------------------------------
   cap.interface.capactio.examples.say          0.1.0             cap.implementation.capactio.examples.hello
                                                                  cap.implementation.capactio.examples.ricky
   

   Copy

3. Create a new Action:

capact act create --name hello cap.interface.capactio.examples.greet

cat <<EOF > /tmp/policy.yaml
rules:
  - interface:
      path: cap.interface.capactio.examples.say
    oneOf:
    - implementationConstraints:
        attributes:
          - path: cap.attribute.capactio.examples.be-positive
            revision: 0.1.0
EOF

capact act create --name hello cap.interface.capactio.examples.greet --action-policy-from-file /tmp/policy.yaml

2. Wait for the Action to have the READY_TO_RUN status:

   capact act get hello
   

   Copy

3. When the status is READY_TO_RUN, run the Action:

   capact act run hello
   

   Copy

4. Watch the progress:

   capact act watch hello
   

   Copy

5. (Optional) Once the Action is finished, copy the name of the Pod for the print workflow step (column PODNAME). To read its logs, run:

   kubectl logs {PODNAME} main
   

   Copy

   Example output:

 ____________________________
< message: Hello from Capact >
 ----------------------------
    \
     \
      \
                    ##        .
              ## ## ##       ==
           ## ## ## ##      ===
       /""""""""""""""""___/ ===
  ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
       \______ o          __/
        \    \        __/
          \____\______/

 __________________________________
< message: Never gonna give you up >
 ----------------------------------
    \
     \
      \
                    ##        .
              ## ## ##       ==
           ## ## ## ##      ===
       /""""""""""""""""___/ ===
  ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~
       \______ o          __/
        \    \        __/
          \____\______/

6. Get the Action output (TypeInstance). Copy the id field value:

   capact act get hello -ojson | jq '.Actions[0].output.typeInstances'
   

   Copy

   Example output:

   [
     {
       "id": "08fcaa07-7846-47af-b6a7-7c3818c69656",
       "typeRef": {
         "path": "cap.type.capactio.examples.message",
         "revision": "0.1.0"
       }
     }
   ]
   

   Copy

7. Get the TypeInstance value.message field value:

   capact ti get {ID} -ojson | jq -r '.[0].latestResourceVersion.spec.value.message'
   

   Copy

8. Delete the Action:

   capact act delete hello
   

   Copy

What if you wanted to output a different message, that reminds you about a masterpiece song you can listen to endlessly? With Capact that's really easy ✨

To choose a different Implementation for the say Interface, we need to prepare a dedicated Policy. The power of it is that you don't have to change the main workflow. You treat the step as a building block and just swap it for another existing one.

To test it, execute steps once again, but now select the Policy-Changed Execution tab.

What is so special about it?​

Our example was simplified to a minimum, but you could see that you can:

• chain different steps together,
• and more importantly, write once and swap implementation details with ease.

Capact is also great if you want to chain different tools together and keep the same entry point (UX) but that requires more complex examples. For now, we recommend you to take a look at our other examples described in the How can I get involved and learn more? section.

Behind the CLI​

As you saw, you can use CLI to browse Hub manifests, create a specific Action for a given Interface and retrieve the output. CLI communicates with our Gateway via GraphQL calls, same as the UI (Capact Dashboard). You can read more in the E2E Architecture document.

However, a more important question is, how did it happen?

spec:
  # ... trimmed ...
  imports:
    - interfaceGroupPath: cap.interface.capactio.examples
      alias: examples
      methods:
        - name: say

  # ... trimmed ...
  steps:
    - - name: get-message
        capact-action: examples.say # dynamic step, rendered by Engine based on the Policy.
    - - name: print
        template: print
        arguments:
          artifacts:
            - name: message
            from: "{{steps.get-message.outputs.artifacts.message}}"
    # ... trimmed ...
    - name: print
      inputs:
        artifacts:
          - name: message
          path: /tmp/message.yaml
      container:
        image: docker/whalesay:latest
        command: [ sh, -c ]
        args: [ "cowsay < /tmp/message.yaml" ]

The snippet above shows the most important parts of the Implementation manifest. In lines 4-7, we declare the import, which is later used in steps. In line 12, we use capact-action to make a dynamic step with a given Interface.

As a result, our Engine and, in particular, Argo Renderer has an option to put there an Implementation that fulfills the specified Interface. Thanks to that, this step is swappable based on the defined Policy.

How can I get involved and learn more?​

The Getting Started goes into more detail about how to start with Capact and use its more-advanced features. There are also Rocket.Chat and Mattermost tutorials that we keep up-to-date for you to walk you through using Capact in real cases.

We appreciate any input you have about your experience with Capact!

There are plenty of options to contact us:

• GitHub issues
• Slack
• Email us at contact@capact.io

Thank you for taking the time to learn about Capact 🙌

In a previous blog post, we discussed some of the problems Capact aims to solve. This time, Capact maintainers took some time to answer questions you might have if you're considering contributing to the project.

What's it like to build a cloud-native platform from scratch? What is it like to work in Capact? What are the biggest challenges? How to start with Go? Read on to get the answers!

Tell us why you are here. How did you begin your adventure in IT?​

Mateusz: In the past, I worked on similar projects that aimed to unify our developer tooling. In my opinion, it is something that awaits us in the future. It’s definitely worth being a part of it.

My journey with IT actually started thanks to my brother. He was really into technology, so besides playing games with me, he started to teach me how it all worked and gave me programming challenges. There was a big age difference between us (10 years), so the first program that I wrote was on Commodore 64 when I was about 8 years old. Since then, I have been involved in technology. From the beginning, I felt love for backends, but tolerated frontend 😁 During my studies, I got interested in the cloud. As a result, I started an internship, where from Java I switched to Go. Now it’s been 5.5 years that I’ve been connected with the cloud-native world and I certainly don’t regret that.

Paweł: My adventure with computer science also started pretty early. When I got my first PC, I was 8 years old. Initially, I played games on it, but after a while, I was interested in doing more than that. When I was in primary school, I started to write some basic applications in Delphi and created my first HTML website. Obviously, the websites followed the trends at that time—they were loaded with GIFs and tons of text scrolling in different directions (remember the “MARQUEE” HTML tag?).

When I was 13, I began working as a freelancer in the web development area. Before getting a bachelor’s degree in computer science, I joined my first IT company as a UI developer. More than 4 years ago, I transformed from a front-end guy to a full-stack cloud developer, with JavaScript, Go, and Kubernetes. I was involved in building a project from the CNCF landscape, and over time I developed less and less front-end and more back-end stuff. In the meantime, I was a Scrum Master and was involved in promoting that previous project at conferences, meetups, and different events. Same as Mateusz, I joined Capact over a year ago to build an ambitious, cloud-native project from scratch.

The main technologies used in Capact are Go and Kubernetes. Why such a choice in this case?​

Paweł: Both Go and Kubernetes are becoming more and more popular.

In the cloud-computing world, choosing the proper set of technologies is very crucial to ensure the final application is scalable, performant, and resilient. Kubernetes helps us orchestrate the deployed microservices, and make sure they operate without any issue, on any cloud provider, or even bare metal.

Go, on the other hand, is a great fit for such projects—its simplicity enables us to write such back-end services efficiently. They are fast to compile and consume much fewer resources than alternatives written in Java or JavaScript/TypeScript.

Mateusz: It’s worth highlighting that the Go community already created a lot of powerful libraries. You don’t need to solve cloud-specific problems once again, and can focus on solving your domain/business problems instead.

As mentioned, Go is easy in terms of memory consumption, which is important in cloud environments. Of course, it doesn't come without a downside; the abstraction level in Go is quite low, but the upcoming Go 1.18 will be a significant release, especially with support for generics.

Can you give us more background on what Capact is?​

Paweł: Capact is an open-source framework for running arbitrary workflows. Currently, we are focusing on day-one and day-two workflows for deploying, and managing applications and cloud-native infrastructure.

The main difference between Capact and alternative tools is its interchangeability of dependencies. The workflow may consist of dynamic steps, which are described by the interface. Such steps can resolve different implementations, depending on the user's preferences. It is the same concept taken from programming languages.

Mateusz: As you can see, the idea for the Capact project is pretty bold: Create a platform that is a glue that you can use to chain e.g. Terraform, Helm, and Slack API. At the same time, ensure the DRY principle at the global scale, so that you can reuse as many existing building blocks as you can. This idea is explained very well in our Introductory blog post :)

The best part of this project is that it's not a competitor to any other project. It gives an option to use tools that you like and trust in a unified and easy way.

What are the biggest challenges associated with it?​

Mateusz: As I said, we try to make Capact as easy as possible.

Here is the thing: it's challenging to make it easy for the end-user, as gluing different tools together requires a lot of flexibility from our platform. It's not possible to gather all use-cases and implement them at once. We need to deliver that iteratively. If you have ideas for where we should go next, we'd love to hear them!

Personally, I like that this project is complicated and makes you rack your brain. We want to solve problems that are not trivial. We also try to strike a balance between the productization and the open-source side.

Paweł: Apart from balancing between two scopes, open-source and commercial, these two are also separate challenges. We are about to start building an open-source community around Capact, which will definitely be a challenge to gain adoption—not only from hobbyists but also big tech companies.

There's also a commercial offering planned, which is based on Capact. And that's happening right now, so we need to ensure that the Capact user experience is seamless for every user profile (BTW they are described on our website) and that it works well in a production environment.

What kind of benefits related to career development can a contributor gain in this project?​

Paweł: Capact consists of many technologies, and you can learn a lot. Even if you know some of them, while working on Capact, you will have an opportunity to dive deeply into some stuff you have never tried. Apart from Go and Kubernetes, we use GraphQL, TypeScript, Terraform, and plenty of projects and tools around Kubernetes, such as Argo workflows, and MinIO.

You will help design upcoming Capact features—starting from user experience, ending up on architectural challenges. There's also a lot to learn when it comes to soft skills—while building an open-source community, you will practice collaborating with external contributors, improve giving talks on meetups and conferences, etc.

Once you have made several valuable contributions, you will have an opportunity to become Capact Maintainer.

What type of maintainers are you looking for?​

Mateusz: We're looking for open-minded people who want to be responsible for multiple parts of the platform that we develop. We have a small team, and we deliver features end-to-end. At this stage, we don't want to split into domain experts; all of us are responsible for the whole product. Don't worry, we will help you in onboarding to our technology stack.

On a daily basis, you will implement new functionality, write automated tests, build CI/CD pipelines, and provide documentation for it.

Paweł: You will also have an opportunity to design architecture, create a proofs of concept, teach and evangelize the open-source community, and be involved in project roadmap planning.

We're looking for solid all-rounders, who are not afraid of new technologies and learn quickly. That's why we think about a true DevOps profile—solid programming skills and love for operations. We require Kubernetes experience, and some experience with Go—it doesn't have to be production-grade experience, but it would be good if you know the basic conventions. Any open-source contributions would be nice to have!

Do you have any advice for beginners in Go? How can developers broaden their knowledge in this area and what benefits does this language offer?​

Paweł: Go is great for writing lightweight backend applications and CLI tools. If you want to build modern cloud-native, apps, learn Go, as it is the right tool for the job.

I would recommend starting with some Go interactive tutorials. After learning new syntax (which is really easy), figure out an idea for a new hobby project. Maybe you're missing some tool you would like to use? It doesn't matter whether it is an HTTP service, CLI tool, or something else—start working on that! Open-sourcing, can give you an additional boost to work on it, and improve over time. Promote it on Reddit and other sites, and you'll see that people use it, and love it!

You can also contribute to some existing open-source projects written in Go. On GitHub, look for issues with the “good first issue” label, discuss it with project maintainers, and start coding! If you're interested in the Capact project, perhaps you can even contribute to our repositories? We also have “good first issues” :-)

Mateusz: Personally, I can tell that for me the most efficient way to learn any language is by doing reviews and submitting PRs that will be reviewed by more experienced developers. This way, you learn how to solve real problems. It doesn't need to be directly within your current company. Same as Paweł, I'm a huge open-source enthusiast, so I also encourage you to contribute to various open-source projects, or start your own!

Additionally, I like to “spy” on other projects from the CNCF landscape and check their design. I also follow people connected with Go, e.g. @dmitshur, @ibuildthecloud, @mattn, @rsc, @alexellis, @bep, @peterbourgon, and others, to learn how they solve a given problem, and to get familiar with different approaches.

It’s much harder to recommend a great project, as it depends on what you want to implement. For example, from my perspective, if you are going to write a more future-proof CLI, the github.com/cli/cli repository is definitely worth checking. If you want to see some Go patterns in action, e.g. a more generic approach to functional options, see sigs.k8s.io/controller-runtime.

In our community, there are a lot of materials. It's good to start with the golang/wiki, the 50 Shades of Go: Traps, Gotchas, and Common Mistakes for New Golang Devs, and the Uber Style Guide. The Ardan Labs is also a good knowledge source.

Others:

1. Read and follow: https://golang.org/doc/effective_go.html
2. Try: https://gobyexample.com/
3. Subscribe: https://golangweekly.com/

Get involved!​

Giving feedback, requesting a feature, reporting a bug—all of these are a great way to contribute. Just join our Slack and talk to us!

Are you participating in the 24 Pull Requests event? We've got your back. Check out issues with the good first issue label and get our full support from the beginning to the merge of your pull request :)

Do you want to work with us on a daily basis? Contact us at contact@capact.io!

We are ultimately all alone. We are siloed within the context of team, department, or company, locked-in in a particular ecosystem of tooling. To deliver end-to-end capabilities, we build them from scratch in a vacuum. We consume API calls, transform data, build and manage infrastructure and applications. Don't we spend too much time solving the same problems as others have?

Sharing expertise is something that already happens—we have plenty of libraries and frameworks out there. But what if we went a step further and have a way to create, use and share building blocks that are language-agnostic abstracted capabilities?

For example, if you're not a cloud expert, all you need to know is that you want a managed PostgreSQL database on AWS. Let the subject-matter experts take care of it, and simply focus on your business logic. Likewise, if you need any Kubernetes cluster—by saying "I want any Kubernetes cluster" and letting the magic happen, you could cover both local development and production scenarios…

What if I told you… now this is all possible?

Introducing Capact, crowdsourced expertise. Learn once, use everywhere.

What is Capact?​

Capact is a new way to manage applications and infrastructure and run arbitrary workflows.

Yes, we get it. You already know plenty of different tools for that. But Capact is different. How is it different?

Capact comes with a truly unique feature—interchangeability of dependencies. If you know the concept of interfaces from a variety of programming languages, you get the idea. Think about Capact as a way of executing workflows with steps, which are described with interfaces. An implementation for a given interface is resolved dynamically at runtime, according to your preferences. Also, these dynamic workflow steps are building blocks, which can be reused by others (or even nested within other workflows).

Initially, we focused on day-one and day-two operations for managing applications and infrastructure. However, Capact is built with universal concepts in mind, so you can run any arbitrary workflow you want. For example, you can do data processing, machine learning workloads, system configuration, cluster benchmarking, auditing, running serverless workloads—the possibilities are virtually endless.

The best thing is that Capact is fully open-source under the Apache 2.0 license. How cool is that? 😎

Capact concept in one minute​

The whole concept sounds confusing? Let's see that in action.

Let's take Mattermost installation as an example. Mattermost is an open-source alternative for Slack.

Mattermost is a Go server application, which uses a PostgreSQL database. If we want to install Mattermost, this how the workflow would look like:

We need a PostgreSQL database first to run a Mattermost server. It's pretty simple.

Now, what if we make the PostgreSQL database installation abstract? Think about that as an empty slot, where you can put a puzzle with a specific shape.

Assuming there are many puzzles pieces out there, you see that only a few of them fit in the slot:

In the case of PostgreSQL installation, four puzzle pieces fit:

1. Install PostgreSQL Helm chart on a Kubernetes cluster
2. Provision GCP CloudSQL for PostgreSQL database
3. Provision AWS RDS for PostgreSQL database
4. Reuse existing PostgreSQL database

By default, for a workflow run, Capact picks the first puzzle piece that fits. However, by applying Policy, you are in complete control of which puzzle piece will be chosen. Moreover, you can select a different one for a specific scenario, such as local setup, CI/CD, stage, and production cluster.

What's great is that Mattermost installation itself is also a larger puzzle piece, which others can use! Maybe as a part of productivity stack installation, which could consist of Mattermost, GitLab and Jitsi Meet? 🤔

And that's Capact. You can build your own workflows with existing puzzles, which are available inside Capact Hub. You can also create your own puzzles. Share them with the community and enable DRY at a global scale, together!

How does Capact differ from other tools?​

Capact doesn't compete with tools you might already be familiar with, but it integrates them instead. Whether you are a Helm or Terraform user, you can still use your favorite tools. Mix and match your tooling or API of choice. For example, chain Terraform, Helm, and Slack API.

If you are familiar with Kubevela, Crossplane, and Open Application Model, you can see many similarities between the solution and Capact. Here are the main differences:

• Capact has unique built-in feature—interchangeable dependencies, which reduces the amount of duplicated code.
• Capact is a process / workflow-based solution, which gives you more flexibility. Unlike Kubevela and Crossplane, Capact is not limited to just infrastructure and application deployment. You can use it for virtually everything.

To read a detailed comparison between Capact and other tools, see our FAQ.

Get started with Capact​

Interested in trying out Capact? Awesome! The easiest way to do so is by installing it locally and trying out one of our examples to understand Capact basic concepts.

1. Install Capact CLI,
2. Install Capact locally with Capact CLI,
3. Run different scenarios of Mattermost installation example.

Here are other things to do:

⭐ Star our GitHub repository: If you like the idea, show your interest in the project and give us a GitHub star! You can also subscribe for new Capact releases. Thank you for your support!

👉 Follow us: Interesting in Capact updates? Follow us on Twitter! Also, check out our LinkedIn page and YouTube channel.

📖 Read our documentation: If you want to get familiar with other installation options, examples, content development, or contribution guides, check out the Capact documentation.

🤔 Get support: If you need any help, or you have a question for us, join our Slack channel on the CNCF workspace and post a message—we'll do our best to get you sorted!

Currently, Capact is at an experimental stage. We open-sourced Capact as early as possible to get early feedback and build Capact together with the community.

Wait, there's more!​

In a series of future blog posts, we will highlight Capact features and cover various topics for all!

Also, as of September 20th 2021, a brand-new release, Capact 0.5.0, is here. We were working really hard to bring many UX improvements, both for Capact users and content developers. The list includes:

• Complete Action input validation and more advanced, concurrent Capact manifests validation with optional server-side checks,
• Experimental content development tools for Helm and Terraform-based (AWS and GCP) manifest generation,
• Policy syntax and behavior changes for improving consistency and usability,
• Verbose output for Capact CLI,
• Dependency updates, including migration to Argo 3,
• Air-gapped Capact installation,
• k3d support,
• and much, much, more!

To see the full list of features, read the release notes.

Are you ready to start playing around with Capact?

This post was updated on 20.09.2021 to highlight that the Capact 0.5.0 release is publicly available.