The Geo-replication category helps distributed developer teams be more productive. With a single GitLab instance working with large repositories can take a long time for developers located in different geographies. 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. This is valuable because using Geo reduces the time it needs to fetch and clone repositires, which increases developer productivity.
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:
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.
Our goal for Geo-replication is to offer the same experience to users, regardless of their location. 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 provide the best user experience. For systems adminstrators, it should be simple to add, configure and remove new nodes.
For more information on how we use personas and roles at GitLab, please click here.
As of October 2019 only ~50% of data types (we need a better name) are replicated and of those only ~41% are fully verified. We have made some efforts to change this situation by trying to replicate the remaining data types and by trying to verify those data types. As part of those efforts we learned that replicating data types is hard and so is verifying the data.
In order to change this situation and allow for adding data types to Geo more quickly, we are investigating how to build a scalable, self-service geo-replication and verification framework. This should make it easier for other teams within GitLab to add new datatypes and allow us to manage GitLab's growth. Additionally, this will make it easier for the community to contribute to Geo. The goal here is to allow new features to ship with Geo support by default without impacting velocity.
Installing Geo is highly manual and cumbersome, especially in high-availability configurations. The Distribution team is working to make deploying and configuring Geo nodes easier. The Geo team will support this effort and in the beginning of 2020, we are going to start investigating how we can simplify Geo's installation.
We also 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 that will 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.
We have identified many small usability issues with the Geo Administrator UI and will start a comprehensive review of Geo's adminstrator panel. This includes generating UX scorecards and also discovery work to evaluate which specific tasks systems administrators need or want to perform using the UI. We will then iterate on the UI and add additional functionalities as needed. Additionally, we will work on refactoring the frontend code to be in line with our latest design guidelines.
Currently, Geo can only officially be operated in one mode - Read-Only - where each the database on a Geo secondary is in a read-only mode. Customer feedback has indicated a desire for additional operational / running modes, namely making Geo read and writable. We have explored two POCs (1, 2) and will revisit this in an effort to move Geo from Complete to Lovable. This is not expected to start before the middle of 2020.
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 PostgreSQL.
This category is currently at the viable maturity level, and our next maturity
target is complete (see our definitions of maturity
levels.
You can track the work that will move the category to complete in
this epic.
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
We do need to engage with analysts more closely to understand the current landscape better.
