AI feature parity for SaaS / SM / Dedicated (#10516) · Epics · GitLab.org

AI feature parity for SaaS / SM / Dedicated

#### Please see [parent epic](https://gitlab.com/groups/gitlab-org/-/epics/308 "GitLab Cloud Connector - SaaS for Self-Managed GitLab instances") for discussion on overarching opportunities for GitLab Cloud Connector Slack channel: `#f_cloud_connector` (internal to GitLab) \ **TL;DR** * **Core problem:** Self-managed customers currently account for a significant portion of GitLab's revenue. Their inability to access AI-related features violates [GitLab's parity principle between SaaS and self-managed](https://about.gitlab.com/handbook/product/product-principles/#parity-between-saas-and-self-managed-deployments). * **Initial use case:** Enable Code Suggestions for self-managed, followed quickly by Dedicated * **MVC Proposal:** * Introduce "Plus" as an abstraction * Introduce the concept of "instance-level authentication" * An authenticated connection between a GitLab instance and Plus * GitLab instances are responsible for user-level authentication * Plus is responsible for instance-level authentication * Plus will proxy AI-requests between a GitLab instance and AI enablement. #### **Context** GitLab’s [AI-features](https://docs.google.com/spreadsheets/d/1rDEQjJ6NYRdXL9GT6xCSgrRdA-VU3gSnIh-JrjxByA8/edit#gid=0) are primarily targeted toward our SaaS customers. However, self-managed instances represent the majority of GitLab’s revenue – we need to develop a green path to serve and eventually monetize our AI efforts for self-managed. Our current focus is accelerating the adoption of GitLab’s AI code suggestions across the GitLab ecosystem. We want users to adopt this feature no matter what their chosen development environment: standalone IDE, web IDE, etc. This will compound our challenges of authentication and (subsequently, monetization) over time. GitLab’s current recommendation for self-managed users is a hacky workaround: We ask self-managed users to create a `.com` personal access token to authenticate and gate access. These users will eventually have to undergo a subsequent migration to our long-term solution. This causes several problems: * The user experience is poor: Users associated with self-managed are suddenly directed to access .com for services * Self-managed administrators are unable to configure access or permissions: There is no way to gate access to a limited number of projects. * GitLab has no easy way to classify access, making it difficult to monetize or rate limit #### Current state <details> <summary>Diagram</summary> ![Untitled_drawing](/uploads/f799ce5869127aed74f69fddfe392ef4/Untitled_drawing.png) </details> All users, regardless of origin authenticate against SaaS. #### **Long-term Vision** <details> <summary>Diagram</summary> ![Long-term_vision](/uploads/58cd94c9a4abb74204e3dfcc613d3492/Long-term_vision.png) </details> GitLab “Plus” is an abstraction layer to resolve the above pain points. In the diagram above, the left and right sides of "Plus" mirror each other, aligning with GitLab's principle of SaaS and self-managed parity. “Plus” will serve as a hub for AI services, by providing: * A single source of truth for consumption metrics to facilitate billing * A GitLab owned connection for self-managed instances, enabling rate limiting and throttling * An abstraction to manage versioning and data residency requirements for external services * GitLab administrators will have instance-level controls to configure which requests can be forwarded to Plus. In the future, this model can also extend to support non-AI use cases such as [managed SaaS runners](https://docs.google.com/document/d/1KxzcHKL-3TKhfPppkp2WQw-EYHExYFFHC1SFc0NfN1A/edit#heading=h.4mt5fmtn0ax4), and other [Plus use cases](https://gitlab.com/groups/gitlab-org/-/epics/308#potential-services "GitLab Cloud Connector - SaaS for Self-Managed GitLab instances"). #### **Proposed MVC** <details> <summary>Diagram</summary> ![MVC_abstraction](/uploads/58f24f026ef9d79ac4a0bdb41f395faa/MVC_abstraction.png) </details> The goal of GitLab's MVC is to introduce an abstraction layer (represented by dotted red box) around self-managed instances. * Everything inside the box is controlled by a self-managed administrator. * Everything outside the box is controlled by GitLab. GitLab should implement an authenticated connection between self-managed/SaaS and Plus for proxying AI-related requests (indicated by bolded blue arrows). The blue arrows are repeated because self-managed, SaaS, and Dedicated are similar. This is a valuable MVC because it provides a clean abstraction for further development. Users will also experience the direct benefit of being on our idealized onboarding flow. It will stop future users from needing to migrate to a different authentication solution. * Self-managed users can be directed to authenticate against their self-managed instance instead of creating a `.com` access token * Existing users will have ample time to migrate and new users will have an onboarding that does not require future migration. * GitLab can develop additional platform features such as rate limiting, throttling, and usage monitoring without impacting our user experience * Self-managed instance administrators are in the "flow of control" and able to govern access permissions for self-managed users **Proposed Iteration Strategy** Our initial use case will be to support Code Suggestions on self-managed instances. Please see https://gitlab.com/groups/gitlab-org/-/epics/11114+ for our iteration plan. #### **Benefits of this approach** A “Plus” abstraction reinforces GitLab’s vision that “SaaS is just a big self-managed instance”. This keeps us on the green path of enabling everything we do for SaaS and self-managed to benefit each other. * Accelerate code suggestions for WebIDE: Plus allows us to build a consistent authentication path for both GitLab SaaS and self-managed * Streamlined user insights: We have one source of truth to track usage regardless of a user’s development environment * Routing all traffic through Plus provides GitLab with a consolidated source of truth for customer billing * Accelerate the maturity of Code Suggestions through decoupling and parallelizing the following problems: * Throttling / rate limiting * GitLab administrative control for add-on usage * User-level authentication and authorization * Versioning control for AI use cases * Data residency requirements * Aligns self-managed adoption to our green path * Users currently authenticating with .com can authenticate with their self-managed instance. * .com and self-managed will simultaneously benefit from improved onboarding efforts * Self-managed Admins are now “in the loop” of information flow, allowing us to create opportunities for management and configuration * Provide an opinionated abstraction framework for user- and instance-level interactions. This will make it easier for GitLab to build consistent information hierarchies. * Extensible green path for GitLab Dedicated #### **Appendix** Link to raw diagram to facilitate future revisions: https://docs.google.com/drawings/d/1wLAM5Ob4p_BlXiVIZbNcHfVmiHJ0RwWCerEu3igMxX4/edit

epic