<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> > Mimicry - The close but superficial resemblance of one organism to another organism or object ~ [Wiki](https://en.wikipedia.org/wiki/Mimicry) A secondary `should` resemble a `primary` - users should be able to interact with a secondary and at least have the same experience compared to the `primary`. We should only let a secondary handle requests if we can significantly improve the user experience. ### Problem to solve Using a Geo node to overcome UX issues (e.g. latency) requires additional configuration for software developers, which is cumbersome. Using the secondary Web interface is a worse user experience than using the primary. A software developer needs to switch between a primary and secondary frequently, which can be highly confusing and frustrating. **Secondary** sites should behave like the primary. Only then can we utilize a single URL. Put another way, any request sent to a secondary must result in the same side effects and the same output. ### User pain As a software developer, using Geo can be challenging - I need to remember different URLs for Git, the web interface is read-only and when trying to make any changes, I need to go to the primary instance anyways. Imagine a EU user wants to upload a video to Youtube. In the EU you can watch high-quality videos on Youtube.eu (another URL) but you can’t comment on the video. In order to do this you need to go to youtube.com and comment there but the video quality is bad because of latency. A user needs to switch between two pages all the time. ### Proposal Proxy all HTTP requests from Geo secondary sites to the Geo primary site by default, which makes the web UI and API usable. Then, we allowlist certain classes of requests to let the secondary handle them locally. Users near the secondary (and far from the primary) will have an "accelerated" experience for locally handled requests. * Git requests are allowlisted. They are already handled properly by secondaries (including proxying pushes to the primary). This will happen in workhorse. POC: https://gitlab.com/gitlab-org/gitlab-workhorse/-/merge_requests/688 ### What does success look like * A regular user can login to a secondary and the WebUI works similar to the primary. All read-requests are served by the primary, all write requests are proxied to the secondary * Proxying is disabled when failing over * This allows for using a single URL, which would need to be documented in a separate issue. * We expect a significant increase of WebUI logins and pull requests from secondaries, which can be measured using usage ping. ### What is the type of buyer? * Ultimate * Premium ### Business impact The current assumption is that a solution to this problem will reach ~75% (the other users only require Geo for DR) of Geo customers and is likely relevant to most prospects who have distributed teams (60-70% Fortune 10000). [Opportunity Canvas (internal)](https://docs.google.com/document/d/1S27A6u134ASCZT_pcKHuxJrUA0aZybxfuHIci1FhYHg/edit#) ### Customer interest * https://gitlab.my.salesforce.com/0016100000W3BBg * https://gitlab.my.salesforce.com/0016100000W44Pc * https://gitlab.my.salesforce.com/00161000004bZPD * https://gitlab.my.salesforce.com/00161000010c3YF