| 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:
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.
For more information on how we use personas and roles at GitLab, please click here.
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.
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.
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:
The existing mode for a secondary node.
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.
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.
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.
This category is currently at the viable maturity level, and our next maturity target is complete (see our definitions of maturity levels.
The top competitors for Geo-replication are
| 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:
We do need to engage with analysts more closely to understand the current landscape better.
