DEV Community: Pablo Romeo

Implementing a DAO in a growing software development company

Pablo Romeo — Tue, 22 Nov 2022 13:26:48 +0000

What if for the activities you do on your day-to-day you were rewarded with tokens that would allow you to participate in company decisions? Sounds great, right? It is possible. We might not all be part of the Roy family from Succession, but we can have access to certain decisions of our company depending on our participation in it.

In this article we will tell you about the idea that led us to build our own Decentralized Autonomous Organization (DAO), and how we are implementing it within CloudX.

The Roy family from Succession series

First things first… What is a DAO?

A DAO is an organization that runs on blockchain and is controlled in its entirety by computational algorithms—aka smart contracts. Once published to the blockchain, smart contracts execute autonomously and determine how the DAO's participants should behave. A DAO is coordinated in a decentralized, horizontal fashion, meaning that each one of its participants has an equal right to make decisions. Additionally, if any modification needs to be made to the DAO, all of its members must reach consensus in order to apply the change.

There are infinite use cases for DAOs, but they are specially being implemented in the financial world. In LatAm there are many projects exploring DAOs application in other fields, for example to provide transparency in nonprofit organizations, or in social verification methods such as Proof of Humanity.

Now, what is our motivation?

Usually, we start most of the initiatives of the Research & Development team in CloudX with a simple question: “I wonder if «some crazy idea» is possible to do?”. This case was not different.

In CloudX, we frequently open the decision making process to the whole team. How? Through polls in Slack. That made us think: would it be possible to implement a similar participation system but based on crypto tokens? This simple question took us down a rabbit-hole to a final outcome: let's create a Decentralized Autonomous Organization (DAO) for internal use within CloudX.

Our main goals are to:

Have active participation of the team in the decision making process.
Have weighted governance while voting for company initiatives.
Add gamification and fun to it, with rewards for employees.

By implementing a DAO in our company, not only we are expecting to meet these goals, but also we get to familiarize our team with the crypto ecosystem, while learning about DAOs, meta-transactions and dApps.

Implementing a DAO in a software company

In our DAO, users are rewarded with governance tokens for different activities they can engage in within CloudX. There is a vast spectrum of activities across the different areas of the company, for example, publishing a tech article in Dev.to, interviewing candidates, giving a tech talk, preparing a course or workshop, assisting other coworkers, reaching milestones, and so on.

This brings Gamification to the table, because when it's time to vote for new proposals, votes are weighted proportionally to the amount of tokens the voter holds.

The proposals we are thinking about voting via our DAO are those that involve different team members of the company in daily activities. They can be very simple things, such as deciding on which date and time we should hold an all-hands meeting, proposing topics for internal workshops, or deciding what our company merch should be.

Nevertheless, we naturally ran into an interesting problem. In the blockchain ecosystem—and DAOs are no different—every transaction has a fee. We absolutely don't want CloudX members having to spend money from their wallets in order to vote for initiatives. This problem led us to think of a solution that allowed CloudX to cover transaction fees in a transparent way.

To solve this problem we came up with the use of meta-transactions, which are transactions that are signed off-chain—outside the blockchain itself—by our DAO's users. These meta-transactions are then embedded into another transaction which, in turn, is submitted and paid by a different account that will ultimately take care of the costs. In consequence, this enables the participants of our DAO to interact with it but not having to worry about the network's fees.

How are we doing it?

We are creating a dApp—decentralized application—, which is a type of application where operations do not depend on centralized control points or servers, but works based on a decentralized network. Our DAO will run on Ethereum blockchain.

For the development we chose Solidity, which is a language with a large community and an extensive tool set. It also gives us the possibility to make our smart contracts compatible with many of the most popular and widely used networks.

For the operation of our DAO we have two smart contracts that articulate it as follows:

GovernorContract: Manages the governance of our DAO, the creation and execution of proposals, the voting and quorum required for approval, and the duration of each proposal.
GovernanceToken: Manages votes and participation. Each participant of the DAO holds governance tokens in their wallets.

Some of the tools we are using for this development are:

OpenZeppelin provides us with a set of smart contracts that are audited and approved by its community, which makes it completely secure for implementation. In our case, the governor contracts and the governance tokens were created with this library.
Foundry is a suite of tools for the development of smart contracts that allows us to manage dependencies, compile our contracts, run tests, deploy them and interact with them through scripts. All of this uses Solidity in its entirety.
We are considering using OpenGSN as the protocol to provide us with the infrastructure to handle our users' meta-transactions. It provides us with different relayers that will receive the meta-transactions from our users, execute the final transaction and pay the network cost.

What's next?

As our DAO starts to gain adoption within CloudX, we will continue to improve it, adding new features in order to make it more robust and empower people to participate in it.

Some of the ideas we have in mind for future iterations are to:

Enable the DAO to be self-managed and able to define the weight (amount of tokens) per activity.
Depending on the level of adoption, analyze the need to apply some adjustment mechanism to balance longstanding holders versus new members of the organization.
Evaluate the possibility to offer buy-back to holders, meaning that somebody who owns tokens can sell them back to CloudX.
Brainstorm additional integrations that enable new activities that can mint tokens.
Host our DAO in a decentralized way via a protocol such as IPFS.

As we do in many projects, this internal initiative from the Research & Development team of CloudX is a sort of “proof of concept”. All the time we are coming up with ideas to use technology to improve our daily tasks.

In CloudX we are passionate about what we do and we think of technology as an end in itself. And, why not, we also like to have fun with it and transform our organization with a gamification process—that has also a lot to do with learning—and that has, as a result, the benefit of making more people participate in our decision making process.

Taming cAdvisor's high CPU usage

Pablo Romeo — Wed, 02 Feb 2022 18:50:58 +0000

When running multiple docker containers, be it on a single server, a Kubernetes cluster or in Docker Swarm, it is very important to be able to monitor their resource usage.

That's where cAdvisor comes in. It provides useful metrics to build Monitoring Dashboards using Grafana and Prometheus:

But there is one big problem: cAdvisor's default settings.

The consequence of running the default configuration is very high CPU usage. Especially noticeable in low-powered devices such as the Raspberry Pi's from the cluster in the graph above.

cAdvisor uses more CPU than the containers it is monitoring! 😭

The fix

Thankfully, it's quite simple. The parameters that make the biggest impact are:

housekeeping_interval
docker_only
disable_metrics

A detailed explanation of each can be found here.

Docker-compose Swarm example

Below I'm defining a housekeeping_interval of 30 seconds, setting docker_only to true, and disabling metrics I'm not interested in, using disable_metrics.

NOTE: Beware that I'm using an ARM version of cAdvisor, change the image/tag accordingly.



version: '3.4'

services:

  cadvisor:

    image: zcube/cadvisor:latest

    ports:

      - published: 9102

        target: 9102

        mode: host

    command:

      - "--port=9102"

      - "--housekeeping_interval=30s"

      - "--docker_only=true"

      - "--disable_metrics=percpu,sched,tcp,udp,disk,diskIO,accelerator,hugetlb,referenced_memory,cpu_topology,resctrl"

    volumes:

      - /var/lib/docker/:/var/lib/docker:ro

      - /dev/disk/:/dev/disk:ro

      - /sys:/sys:ro

      - /var/run:/var/run:ro

      - /:/rootfs:ro

      - /sys/fs/cgroup:/cgroup:ro

      - /etc/machine-id:/etc/machine-id:ro

      - /etc/localtime:/etc/localtime:ro

    deploy:

      mode: global

      update_config:

        order: stop-first

      resources:

        reservations:

          memory: 80M

    healthcheck:

      test: wget --quiet --tries=1 --spider http://localhost:9102/healthz || exit 1

      interval: 15s

      timeout: 15s

      retries: 5

      start_period: 30s

Did it help?

Check this out:

I'm sure you can guess at what time the new settings kicked in 😏. From 0.68 vCPU to 0.08 vCPU!
Not bad at all.

Multi-arch docker images the easy way, with Github Actions

Pablo Romeo — Wed, 12 Jan 2022 13:56:35 +0000

You may have come across Docker images like the one above ☝️. In this example, you can see that the latest tag supports two different architectures. Meaning there are two different images for the same tag, and docker will pull the appropriate one depending on the target architecture. But...how are they built?

The old way

Back in the day, the only option was to manually built each separate image using the ARCH build-arg, push it, and then use the docker manifest command to group the images together under the same manifest.
This manual process is described in depth in this post by the Docker team. But now there's even an easier way.

Buildx to the rescue

Thankfully Buildx automates this process and simplifies it quite a bit. A single command can do all that for you.
But who wants to be building images locally anyway? 😁
Plus, automating it with Github Actions is a great excuse to also implement a proper tagging and versioning strategy as well as exploring multiple Container Registries.
Let's get to it! 💪

Github Actions build

The overall process is as follows:

Checkout the code
Setup QEMU
Setup Buildx
Log into the target container registry
Docker Metadata tag voodoo magic (optional)
Build and push

Let's assume we have a Github repo with a main and a dev branch, PRs, as well as versioned releases.

We'll have a github actions YAML similar to the following:



name: Build

# Controls when the workflow will run
on:
  workflow_dispatch
  push:
    branches:
      - 'main'
      - 'dev'
    tags:
      - 'v*.*.*'
  pull_request:
    branches:
      - 'main'
      - 'dev'

# permissions are needed if pushing to ghcr.io
permissions: 
  packages: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:

Steps 1,2 and 3

These are quite straightforward:



      # Get the repository's code
      - name: Checkout
        uses: actions/checkout@v2
      # https://github.com/docker/setup-qemu-action
      - name: Set up QEMU
        uses: docker/setup-qemu-action@v1
      # https://github.com/docker/setup-buildx-action
      - name: Set up Docker Buildx
        id: buildx
        uses: docker/setup-buildx-action@v1

Step 4

For Github's Container Registry you can use the following:



      - name: Login to GHCR
        if: github.event_name != 'pull_request'
        uses: docker/login-action@v1
        with:
          registry: ghcr.io
          username: ${{ github.repository_owner }}
          password: ${{ secrets.GITHUB_TOKEN }}

And for Dockerhub:



      - name: Login to Docker Hub
        if: github.event_name != 'pull_request'
        uses: docker/login-action@v1
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

Create a dockerhub access token and set the corresponding github secrets.

Step 5

We could skip this step and just use the latest docker tag, but in real world scenarios you'll likely want a more elaborate image tagging strategy. Such as sha, branch, Semantic Versioning, etc.

So we'll use the extremely useful docker/metadata-action@v3 for preparing those tags for us.
Check out https://github.com/docker/metadata-action for more example tagging strategies. The documentation is great!



      - name: Docker meta
        id: <meta_id> # you'll use this in the next step
        uses: docker/metadata-action@v3
        with:
          # list of Docker images to use as base name for tags
          images: |
            <specify the image name>
          # Docker tags based on the following events/attributes
          tags: |
            type=schedule
            type=ref,event=branch
            type=ref,event=pr
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}
            type=semver,pattern={{major}}
            type=sha

This prepares image tags for branch, PR, major, major.minor, version, and sha, which you should adapt according to your own release process.
Replace meta_id with something more appropriate. It will be used in the next step.
Specify the image name under the images: section. For ex: ghcr.io/pabloromeo/foo for GHCR or pabloromeo/foo for dockerhub.

Step 6

And the final step is to actually build for each target platform and push to the registry.



      - name: Build and push
        uses: docker/build-push-action@v2
        with:
          context: .
          platforms: linux/amd64,linux/arm/v7
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ steps.<meta_id>.outputs.tags }}
          labels: ${{ steps.<meta_id>.outputs.labels }}

Change the following:

The target architecture platforms to build, using platforms: (in this example AMD64 and ARMv7)
Replace <meta_id> with the proper id used previously.

Final comments

This turned out to be a lengthy post, but the actual build definition is quite simple when put together, and you'll not only get multi-arch docker images, but nice semver versioning and tagging as well. 😄

To see full working examples of this we can take a look at the builds of two pet projects of mine: Docker-Dogecoin and ClusterPlex.

In Docker-Dogecoin's Dockerfile there's an example of how to write conditional logic as part of the docker build process depending on the target architecture to install different binaries for each.

In Clusterplex's build it actually pushes to BOTH ghcr.io and Dockerhub simultaneously, as well as updating Dockerhub's Description page to the content of the README.md in the repo.