Geo's role in GitLab is to help our users bring their data closer. Geo provides an easily configurable read-only mirror of a GitLab installation that is complete, accurate, verifiable and efficient.
Our future vision for Geo is to become a distributed solution where users have fine-grained control over the data present on each node. We are hoping to accomplish this in a way that is transparent to the end-user.
Alongside our existing priorities (listed below) we will continue to research the longer term vision of Geo based on customer feedback.
At the start of FY-20, we took stock of our current implementation of Geo and looked at how it aligns with the current and future needs of our customers.
We determined that the most important need we must address is improving the administrator experience. This will help existing customers as well as increase Geo's appeal for prospective users.
Once this is completed, we can return to figuring out how to satisfy the more complex needs of our customers. If you would like more information about this, please read the Next Gen Geo.
Where Epic links are not provided below, the content of these projects can be found by looking at our Roadmap Planning Sheet. As projects become more clear they are moved from this sheet into Epics.
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.
Alongside the priorities above, we constantly address housekeeping items to keep the code manageable and of good quality. The contents of these can be found on our Roadmap Planning Sheet.
