Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Strategy - Geo-replication

🌏 Geo-replication

Introduction and how you can help

   
Maturity Viable

The Geo-replication category helps our users bring their data closer. Geo-replication provides an easily configurable, read-only mirror (we call it a Geo node) of a GitLab installation that is complete, accurate, verifiable and efficient.

Please reach out to Fabian Zimmer, Product Manager for the Geo group (Email) if you'd like to provide feedback or ask any questions related to this product category.

This strategy is a work in progress, and everyone can contribute:

🔭 Where we are Headed

At GitLab, we want everyone to contribute. Our goal for Geo-replication is to offer the same experience to users, independent of where they are located. Currently, Geo-replication requires a significant investment to be configured, upgraded and maintained by systems administrators. Not all parts of GitLab are replicated and there is not as much control over what is replicated where. In the future, we want our users to be able to configure Geo within minutes - not hours. We envision Geo-replication to be fully transparent to users. This means that a developer should not need to actively decide to use Geo, or select the right Geo node - GitLab should be able to determine what Geo node should be used to get the best performance. For systems adminstrators, it should be simple to add, configure and remove new nodes. Geo will allow distributed teams to collaborate across the globe sharing the same user experience wherever they are located.

🎭 Target Audience and Experience

Sidney (Systems Administrator) - Persona Description

For more information on how we use personas and roles at GitLab, please click here.

🚀 What's next & why

Automatically choosing the best Geo node

We will provide better instructions to our users on how to configure Geo in such a way that only a single Git URL is needed. This may be achieved. through geo-aware DNS or loadbalancers. We will alos work with the UX department to understand if the user experience of the primary web interfaces is sufficient. Based on this research we may be able to to decide if we still need to provision secondary web-interfaces to users or not.

Making Geo simpler to install

Installating Geo takes many manual steps and could be a lot simpler. We will start investing how we can accomplish bu we identified that a service discovery solution could have a huge benefit in helping administrators set up clusters of Geo nodes. We are currently working to support Geo on Kubernetes to give us a greater understanding of this tool to help inform us as to the right direction to take with this proposal. We will update the service discovery proposal when Kubernetes support is complete.

Multi-mode Geo

Currently, Geo can only officially be operated in one mode - Read-Only - where each Geo secondaries DB is in a read-only mode. Customer feedback has indicated a desire for additional operational / running modes:

Read-Only

The existing mode for a secondary node.

Data-Only

Currently how Geo runs on GitLab.com, but further modifications could be made to remove redundant components for this mode to make it a light-weight DR tool.

Writable

A new mode that we are exploring. We have two proof-of-concepts for the idea:

We are aware that there may be a paradigm shift required to achieve distributed writable nodes, and following our value of iteration, these POC's are a first step in expanding how we think about the domain of writable nodes.

What is Not Planned Right Now

We are currently not planning on moving away from Postgres as a backend database in favour of e.g CockroachDB or Google Spanner. This has implications for multi-mode Geo, but for now we will continue to support Postgres.

Maturity Plan

This category is currently at the viable maturity level, and our next maturity target is complete (see our definitions of maturity levels.

🏅 Competitive landscape

The top competitors for Geo-replication are

Feature overview

Feature GitHub AzureDevOps Bitbucket Smart Mirroring GitLab
Mirror repositories
Active-active replication N/A
Selective sync N/A N/A ⚠️
UI configuration N/A ⚠️
Kubernetes support
Mirror docker registries N/A ⚠️
LFS and file upload support N/A
Automatic DNS
GUI Dashboard N/A
Request proxying N/A N/A ⚠️

✅ Fully available
⚠️ Partially available
❌ Not available
N/A No information available

Based on GitHub's feature set the top two items to work on may be:

Analyst landscape

We do need to engage with analysts more closely to understand the current landscape better.

Top Customer Success/Sales issue(s)

🎢 Top user issues

🦊 Top internal customer issues/epics

Top Strategy Item(s)