B How GitLab scaled Git access with Go and what we gained from it – Oswaldo Ferreira

B How GitLab scaled Git access with Go and what we gained from it - Oswaldo Ferreira

Back in the early days of GitLab.com, we’ve used to run Rails worker processes, Sidekiq background processes, and Git storage on a single server, a typical monolith. As expected, it’s easy to deploy and maintain, though really hard to scale. Having a single server means we’re only able to scale vertically, which becomes increasingly expensive and limiting.

At a given time, we had to run multiple servers, which meant Git repositories had to be available to all server nodes. For that, we first went for the “quick-win”, NFS. It rapidly showed its limitations regarding observability, single point of failure and high latency.

Beside alternative solutions, we decided to slightly redesign the system and create a Go service called Gitaly, which now acts as a “git database” service for GitLab.com.

This talk will go through the history of how we’ve gradually separated it from the monolith using Feature flags, Protocol Buffers, gRPC and Go.

Oswaldo Ferreira – Backend Engineer working at GitLab’s Create team, which is ultimately responsible for interacting with git and git services within GitLab (Gitaly).

Loves Ruby, making things fast, a-ha moments and shipping features that makes developer’s life a breeze.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *